3. Agenda
What is that Electron thing anyway?
Why would I want to build a desktop applications in the
first place ?
Why would I want to build a desktop applications in
Electron ?
How do I build a desktop application in Electron ?
Hello World
Menu bar
File system access
Notifications
Package an application
Display data from IBM Domino
4. Prerequsites
Editor of your choice
Visual Studio Code, Atom, Sublime Text …
Node.js
Electron
Will be installed during development
Git ( optional )
6. A framework for …
Electron: A framework for building cross-platform desktop
applications, using
Javascript, HTML & CSS
7. Build on three core components …
Google’s open
source JS engine
open source
browser project
JavaScript runtime
built on Chrome's V8
JavaScript engine
19. Why would I want to
build a desktop
application in Electron ?
20. Why Electron? – What does Electron bring to the tabel?
You only need to learn ONE framework
Learn Electron API
No need to learn Cocoa ( MAC ) , Windows API and whatever Linux
is using these days for the desktop
21. Why Electron? – What does Electron bring to the tabel?
Electron gives you some amazing tight integration
Notifications
Access to task switcher
Access to menus
Access to global shortcuts
Access to system level events
22. Why Electron? – What does Electron bring to the tabel?
Code reuse
If your application is a companion to a web application, there is a
really good chance that you can take some of the assets that you
are using in the frontend and with a little bit of work, transport
them over to your electron application.
As a bonus, if your backend is running node.js there is also a really
good chance that you can take some of the backend code that is
running node.js and transplant it into your Electron application.
„Your code is not reusable
until you reuse it!“
23. Why Electron? – What does Electron bring to the tabel?
If you write an application in Electron, there is actually a
lot of problems that traditional web developers have
already solved over the years and you do not have the
need to think about it anymore.
24. Why Electron? – What does Electron bring to the tabel?
Only ONE browser to support.
25. Why Electron? – What does Electron bring to the tabel?
You get Chrome dev tools, for free, when you are start
developing an Electron application.
One of Electrons core components is the Chromium engine. Your
application windows are actually Chromium windows. And this
gives you Chrome dev tools within your application and you can
debug your code right inside your application.
Chrome dev tools is pretty much state-of-the-arte when it comes
to debug web applications.
26. Why Electron? – What does Electron bring to the tabel?
A new frontier for ( web ) developers
54. Main Process & Renderer Process
Main Process
package.json main script. Creates
BrowserWindow instance to run
web pages.
Renderer Process
each webpage runs its own
isolated process called the
renderer process
https://codeburst.io/deep-dive-into-electrons-main-and-renderer-processes-
7a9599d5c9e2
57. app.js ( add ipcMain )
const electron = require('electron');
const path = require('path');
const url = require('url');
/*
The ipcMain module is an instance of the EventEmitter class.
When used in the main process, it handles asynchronous and
synchronous messages sent from a renderer process (web page).
Messages sent from a renderer will be emitted to this module.
*/
const {app, BrowserWindow, ipcMain} = electron;
...
59. app.js – add EventListeners
ipcMain.on('show-prefs', function () {
winPrefs.show()
// hide the menu on the prefs page
// thanks to Theo Heselmans for this
winPrefs.setMenu(null)
})
ipcMain.on('hide-prefs', function () {
winPrefs.hide()
})
63. Add to createWindow()
function createWindow() {
...
// Emitted when the window is closed.
// Dereference the window object, usually you would store windows
// in an array if your app supports multi windows, this is
// the time when you should delete the corresponding element.
win.on('closed', function () {
win = null
})
winPrefs.on('closed', function () {
winPrefs = null
})
}
64. app.js – add functions
app.on('ready', createWindow);
// Quit when all windows are closed.
// On OS X it is common for applications and their menu bar
// to stay active until the user quits explicitly with Cmd + Q
app.on('window-all-closed', function () {
if (process.platform !== 'darwin') {
app.quit();
}
})
// On OS X it's common to re-create a window in the app when the
// dock icon is clicked and there are no other windows open.
app.on('activate', function () {
if (mainWindow === null) {
createWindow()
}
})
70. Notifications
Windows, Linux and macOS operating systems provide
means for applications to send notifications to the user.
Electron conveniently allows developers to send
notifications with the HTML5 Notification API, using the
currently running operating system's native notification
APIs to display it.
On Windows 10, notifications "just work“, NOT *
* it works when you install the application ( well, sometimes )
Have not tried Linux
https://electronjs.org/docs/tutorial/notifications
71. main.html & main.js
function doNotify() {
const notification = {
title: 'Basic Notification',
body: 'This is an Electron notification'
}
const myNotification =
new window.Notification(notification.title, notification)
}
<body>
<h1>Desktop Notification</h1>
<button type="button"
name="button" onclick="doNotify()">Notify me</button>
<script src="./main.js"></script>
</body>
74. Electron Packager
Electron Packager is a command line tool and Node.js
library that bundles Electron-based application source
code with a renamed Electron executable and supporting
files into folders ready for distribution.
Note that packaged Electron applications can be relatively
large (40-60 MB).
75. Electron Packager
Electron Packager is known to run on the following host
platforms:
Windows (32/64 bit)
OS X
Linux (x86/x86_64)
Generates executables/bundles for the following target
platforms:
Windows (also known as win32, for both 32/64 bit)
OS X (also known as darwin) / Mac App Store (also known as mas)
Note for OS X / MAS target bundles: the .app bundle can only be
signed when building on a host OS X platform.
Linux (for x86, x86_64, and armv7l architectures)
76. Electron-Packager
In order to build and package your app, you need to install
electron-packager first.
You can install it globally or as a dev dependency.
npm install electron-packager -g
https://docs.npmjs.com/cli/install
77. Electron-Packager
To build an application for a platform you’ll need to
execute the following command in terminal / command
prompt.
electron-packager
<sourcedir> <appname>
--platform=<platform> --arch=<arch> [optional flags...]
electron-packager .
electron-packager . --all
78. Electron-Builder
A complete solution to package and build a ready for
distribution Electron app for macOS, Windows and Linux
with “auto update” support out of the box.
https://github.com/electron-userland/electron-builder
Support for code-signing
Electron is an open source application 'framework' created by GitHub, designed to make building desktop applications easy. This presentation will introduce you to its many features, and how you how to quickly get started.
So, Electron. How many people have heard of Electron ? Good
How many people have used Electron. All right , awesome. Hopefully, I won’t you put to sleep, the rest of you hopefully will enjoy the session.
Hello. My name is Ulrich Krause. I am a Notes / Domino administrator and developer since 1993.
I am an IBM champion since 2010 ( initial 50 !) re-elected in 2018.
I have contributed some stuff to OpenNTF; also I am the lead developer od LE4D
I am working with midpoints, a IBM business partner located in Germany. Our focus is mobile device management.
In this session, I want to show you, how you can create platform independent desktop applications.
Here is, what I want to cover within the next 60 minutes.
https://v8docs.nodesource.com
The web has come so far. It seems weird, right ?
But it turns out, that actually there are a few reasons, why you want to build desktop applications in 2018.
Here is a couple of the reasons:
The first one is perhaps your application requirements has a need to run in the background. And you don‘t want to rely on your browser being up because your browser might crash, and if your browser crashes, that background ap dies.
The other thing is you might require file system access. The things that make browsers so powerful with web applications and so usable is because of the security model in browsers. You‘re downloading arbitrary code from the internet and you are executing it on your machine. Browsers have to be extremely sandboxed in order to people will trust them. And as a result of that, things like file system access are things that you are completely locked out.
Perhaps your application requirements also require direct API access to something. If you download a web application, you cannot tell this application to initiate a connection from my browser to some API over there. You can‘t do that. So, if you need to do this kind of connection, you have to do it from your local machine. This is why we have i.e a POSTMAN app.
Maybe, your application requires access to your hardware. For example, you have a bluetooth card or want to play with sphero, or you have a smart-card reader. That kind of stuff, you cna‘t do from a browser. You need access to local API that speak to your local hardware in order that you can make those connections.
But why else would you want to write an application that works on the desktop today?
Perhaps you have a requirement for on premises access. It might not make sense to install a web application with a webserver and stuff if a firewall would stop access.
The other reason is you might require binary protocol access. If you need to make a connection to a MySQL database, you need to make those connections using mysql drivers that compile down to C that you can use as a client library.
And the other thing is that some applications just feel right on the desktop. That is why we (all) have installed SLACk app on our machines instead of using the web application.
Another this is GAMES. The desktop is still the predominant place to download and run games.
That is why I think that there is still a place for desktop applications; even in the year 2018.
One of the things, electron gives you, is that you only have to learn one framework, and what I mean by that is, you just have to learn electrons API. It is relatively small. And you can reuse all your JS, HTML and CSS that you‘ve been using for all theses years.
If you are on a MAC, you do not have to learn Cocoa, you do not have to learn the Windows APIs and whatever Linux is using these days for the desktop. You do not have to worry about any of that.
You just use Electron, write your code once and run it on Windows, MAC and Linux.
The other thing is , Electron gives you some amazing tight integration. You can do stuff like activating notifications. You have access to the task switcher. You have access to menues, You have access to global shortcuts. You have access to system level events, so you can detect when your computer is going to sleep, when your computer wakes up or your CPU is going nuts and do something about it.
And finally you get a lot of code reuse with electron.
If your application is a companion to a web application, there is a really good chance that you can take some of the assets that you are using in the frontend and with a little bit of work, transport them over to your electron application.
As a bonus, if your backend is running node.js there is also a really good chance that you can take some of the backend code that is running node.js and transplant it into your Electron application.
You can save a lot of time if you already have that companion web application.
If you write an application in Electron, there is actually a lot of problems that traditional web developers have already solved over the years and you do not have the need to think about it anymore.
You get Chrome dev tools, for free, when you are start developing an Electron application.
The reason for that is that one of Electrons core components is the Chromium engine. Your application windows are actually Chromium windows. And this gives you Chrome dev tools within your application and you can debug your code right inside your application.
And Chrome dev tools is pretty much state-of-the-arte when it comes to debug web applications.
And this one, I think, is also important. The desktop is a new frontier for developers. Especially web developers. Web developers have traditionally been locked out from the entire part of the development culture.
We now have the tools to take our skills that we have learned all these years and bring them to a completely new place where we have never been before
Node.js core does its best to treat every platform equally. Even if most Node developers use OS X day to day, some use Windows, and most everyone deploys to Linux or Solaris. So it's important to keep your code portable between platforms, whether you're writing a library or an application.
Predictably, most cross-platform issues come from Windows. Things just work differently there! But if you're careful, and follow some simple best practices, your code can run just as well on Windows systems.
Paths and URLs
On Windows, paths are constructed with backslashes instead of forward slashes. So if you do your directory manipulation by splitting on "/" and playing with the resulting array, your code will fail dramatically on Windows.
Instead, you should be using the path module. So instead of resolving paths with string contatenation, e.g. x + "/" + y, you should instead do path.resolve(x, y). Similarly, instead of relativizing paths with string replacement, e.g. x.replace(/^parent\/dirs\//, ""), you should do path.relative("/parent/dirs", y).
Another area of concern is that, when writing portable code, you cannot count on URLs and module IDs having the same separators as paths. If you use something like path.join on a URL, Windows users will get URLs containing backslashes! Similarly for path.normalize, or in general any path methods. All this applies if you're working with module IDs, too: they are forward-slash delimited, so you shouldn't use path functions with them either.
Non-portable APIs
Windows is completely missing the process.(get|set)(gid|uid) methods, so calling them will instantly crash your program on Windows. Always guard such calls with a conditional.
The fs.watchFile API is not sufficiently cross-platform, and is recommended against in the docs because of it. You should use fs.watch instead.
The child_process module requires care cross-platform. In particular, spawn and execFile do not execute in a shell, which means that on Windows only .exe files will run. This is rather problematic, as many cross-platform binaries are included on Windows as .cmd or .bat files, among them Git, CouchDB, and many others. So if you're using these APIs, things will likely work great on OS X, Linux, etc. But when you tell your users “just install the Git build for Windows, and make sure it's in your path!” that ends up not being sufficient. There is talk of fixing this behavior in libuv, but that's still tentative. In the meantime, if you don't need to stream your output, exec works well. Otherwise you'll need branching logic to take care of Windows.
A final edge-case comes when using named sockets, e.g. with net.connect. On Unix, simple filenames suffice, but on Windows, they must conform to a bizarre syntax. There's not really a better solution for this than branching per-platform.
Being Windows-Developer Friendly
One of the most egregious problems with many projects is their unnecessary use of Unix Makefiles. Windows does not have a make command, so the tasks stored in these files are entirely inaccessible to Windows users who might try to contribute to your project. This is especially egregious if you put your test command in there!
Fortunately, we have a solution: npm comes with a scripts feature where you can include commands to be run for testing (test), installation (install), building (prepublish), and starting your app (start), among many others. You can also create custom scripts, which are then run with npm run <script-name>; I often use this for lint steps. Also of note, you can reference any commands your app depends on by their short names here: for example, "mocha" instead of "./node_modules/.bin/mocha". So, please use these! If you must have a Makefile for whatever reason, just have it delegate to an npm script.
Another crucially important step is not using Unix shell scripts as part of your development process. Windows doesn't have bash, or ls, or mv, or any of those other commands you might use. Instead, write your shell scripts in JavaScript, using a tool like Grunt if you'd like.
Bonus: Something that Breaks on Linux and Solaris!
Both Windows and, by default, OS X, use case-insensitive file systems. That means if you install a package named foo, any of require("foo") or require("FOO") or require("fOo") will work—on Windows and OS X. But then when you go to deploy your code, out of your development environment and into your Linux or Solaris production system, the latter two will not work! So it's a little thing, but make sure you always get your module and package name casing right.
Conclusion
As you can see, writing cross-platform code is sometimes painful. Usually, it's just a matter of best practices, like using the path module or remembering that URLs are different from filesystem paths. But sometimes there are APIs that just don't work cross-platform, or have annoying quirks that necessitate branching code.
Nevertheless, it's worth it. Node.js is the most exciting software development platform in recent memory, and one of its greatest strengths is its portable nature. Try your best to uphold that!
Most Windows command prompts will choke when you set environment variables with NODE_ENV=production like that. (The exception is Bash on Windows, which uses native Bash.) Similarly, there's a difference in how windows and POSIX commands utilize environment variables. With POSIX, you use: $ENV_VAR and on windows you use %ENV_VAR%.
This solution
cross-env makes it so you can have a single command without worrying about setting or using the environment variable properly for the platform. Just set it like you would if it's running on a POSIX system, and cross-env will take care of setting it properly.
electron-packager will do the following:
Use the current directory for the sourcedir
Infer the appname from the productName in package.json
Infer the appVersion from the version in package.json
Infer the platform and arch from the host, in this example, darwin platform and x64 arch.
Download the Windows x64 build of Electron (and cache the downloads in ~/.electron)
Build the Windows part6.app
Place part6.app in part6/part6-win32-x64/ (since an out directory was not specified, it used the current working directory)
Please keep in mind that’s recommendable to build every platform on it’s respective platform i.e build the Windows version of your app in a Desktop with Windows as operative system.
Although for some platforms is possible to build for other platforms i.e you can build the Linux and Windows versions in a Windows computer, you’ll be unable to create a Mac application in a Windows platform, therefore you need to build it in a Mac environment.
SmartNSF: Turn your Notes/Domino Application into a microservice and expose a REST API within minutes? This
is the core goal of SmartNSF! With this in mind, SmartNSF is integrated in the IBM Domino Designer
and the configuration is smart and simple.