noWindow: true or false?

Recently a number of questions have arisen concerning the optional noWindow field in appinfo.json as it pertains to Enyo applications.

The implementation of noWindow is on the native side, and is unchanged from Mojo.

The default value of noWindow is false; if you set the value to true in your appinfo.json file, when your application is first launched, the initial window will be permanently hidden instead of being a card. One curious implication of this is that if you want your "noWindow" app to display a card when it is launched, you need to manually create the card as a second window when your app starts up. For this reason, "noWindow" apps generally have more issues with slow launch time than other apps (except for those that are launched at boot and left running all the time, of course). This is all the same in Enyo as it was in Mojo.

The key difference between Enyo and Mojo as it pertains to "noWindow" is that the two frameworks have very different ways of handling multiple windows. In Mojo, the majority of the framework is only ever loaded once, in the "main window" of the app, and all the application's JavaScript code runs there, sharing the same global window object. By contrast, in Enyo the framework is loaded anew in each window, and the only global shared between windows is the enyo.application object. Applications usually set noWindow:true because they need some kind of global execution context that's independent of their more transient visible windows (which the user can close at any time). Since Enyo loads app code into each window, there's no point in loading any of your UI controls into your hidden window. You should load only the code needed to support the global context.

Let's look at the Email app as an example.

The index.html file at the top level is the entry point of the app, and this becomes the hidden window. This hidden window is responsible for a number of things, including:

• General app initialization

• Monitoring changes to email messages and folders to make sure the data is maintained in a displayable state

• Showing notification dashboards for new messages and account errors

• Monitoring changes to the accounts themselves.

• Handling relaunch arguments (relaunches always go to the hidden window), which usually means creating or activating some other window

• Providing a bottleneck for preference updates and change notifications

• Providing global tracking for attachment downloads (since they must continue with no cards open)

Note that the hidden window doesn't do anything directly related to UI except create other windows (dashboards, cards, etc.). Thus the depends file for our top-level index doesn't include UI controls at all. The UI controls are kept together with their corresponding visible windows in other directories, each of which has its own index file.