What’s New In Sencha Desktop Packager 1.2

Sencha Desktop Packager enables you to take an existing web application and deploy it as a native desktop application. It allows you to extend your application by providing additional Javascript APIs which facilitate deeper integration with the native environment your application finds itself in, and provides an encrypted means of deployment to protect your code and any associated assets.

We continue to extend the scope of our integration APIs, and in this post cover the new Windowing API introduced in the Desktop Packager 1.2 release. This content logically follows on from “Using Native APIs in Sencha Desktop Packager” in which Ariya introduced the core set of APIs we provide to enable you to tailor your application to the desktop environment.

Newcomers to Sencha Desktop Packager should be sure to watch the 3-minute walkthrough, download the 30-day trial edition for Linux, Windows, or OS X, and check out our online documentation.

Creating Windows

One distinction between web apps and native apps is that web apps tend to be hostage to the browsing frame in which they run. With Sencha Desktop Packager, this limitation does not exist and you can create as many top level native windows as your application requires. These windows are decorated top level windows which can contain any independent web content you wish to attribute to them and are capable of sharing data with one another.

This facilitates the creation of MDI style applications, with a prime candidate for such extension being the text editor introduced in the aforementioned post. This hitherto unattainable functionality allows each top level window to reuse the same business logic throughout while encapsulating entirely distinct content.

We can achieve this via a minor adjustment to our original editor application; namely, moving the editor into its own document and having the initial document simply create the application menu entries. Editor windows can now be created on demand. In extending our editor example, we simply add another action to create a window to the existing menu items.

	  var windowMenu = Ion.ui.mainWindow.menuBar.addMenu('&Window');
	  windowMenu.addMenuItem('New', handleNewWindow, 'Ctrl+N');

and then implement the handleNewWindow function:

	function handleNewWindow() {
	  var winID = uniqueID();
	  var win = new Ion.ui.Window({ visible: true,
	                                title:"Editor Window " + winID,
	                                url: "editor.html"});
	  win.setDimensions(400, 400);
	  win.setPosition(200 + 50*winID, 200 + 50*winID);

The net result of this action is the creation of a cascading set of top level windows all intuitively bound to their own respective documents.

Sharing Data Between Windows

It is fairly common to want to share information between the various specialized windows you create. In such circumstances, the data member is provided as a channel allowing for all individuals in possession of a reference to the data to listen for changes and respond accordingly, or push data changes as required.

In the context of our text editor, this could be used to implement a top level document dashboard where you could track the open documents and get a preview of their contents and their last modification date.

On the creation of each new editor window, I register the onDataChanged event of each window with a callback in the dashboard

	win.onDataChanged = function() {
	  cell1.innerHTML = win.data.preview;
	  cell2.innerHTML = win.data.timeStamp;

It is trivial to further extend this to listen to any document-relevant functionality that the toplevel window is interested in, such as the most recently saved filename.

Dictating Window Sizing Constraints

Now that we’ve given you multiple window, you probably want to define discrete sizing behavior. This is achieved in Sencha Desktop Packager through sizing policies which define both resizing behavior and any resizing limits that you may wish to impose.

Windows are normally permitted to resize at will; imposing constraints is simple:

	var win = new Ion.ui.Window({ url: 'hello.html',
	                              title: 'A Capable Window',
	                              visible: true});
	var policy = win.sizingPolicy;
	policy.vertical = 'fixed';
	policy.maximumWidth = policy.maximumHeight = 400; 
	policy.minimumWidth = policy.minimumHeight = 100; 
	win.setDimensions(500, 500);

The window above now is fixed at a vertical size, and can resize horizontally between the designated maximum/minimum values. Since the final call to set the dimensions exceeds the constraints imposed by the size policy the value is clamped as you would anticipate, and the window is consequently initially sized to 400 by 400.

This kind of functionality allows us to, for instance, clamp the size of the document dashboard to the size of the table containing all the document metadata, and is actually in effect in the screenshot above.

Responding to Close Events

Any attempt to close a Sencha Desktop Packager window on any of the supported platforms generates a closing event which allows you to respond to, and even intercept, this intent to close based on your own criteria. Again citing the example of the text editor which we have extended, this would allow you to detect whether there was the potential for any data loss and warn the end user accordingly.

Achieving this is as simple as connecting the closing event to the following onClose function

	function onClose() {
	  return confirm('You may have unsaved data, do you wish to proceed?');

Since multiple parties can connect to the same closing event, you could also conveniently track and reflect the closing of the document window in question in the top level document dashboard.


So ends a non-exhaustive look at some of the functionality introduced in Sencha Desktop Packager 1.2. In this blog I have focused on the new Windowing APIs, but there have been a slew of improvements introduced over the same period which warrant mentioning. In maintaining parity with the Chromium stable branch, we advanced to the Chromium 25 release, which brought with it a host of functional and performance improvements. In addition to this, as part of the Window API work we allow the setting of a zoom factor on web content on a per window basis. For those who are interested, the Sencha Desktop Packager 1.2 release notes are available for your perusal and give a far more comprehensive of the changes we have introduced.

If you want to play directly with the windowing functionality discussed in this blog, I would encourage you to play with the Windowing example we ship as part of Sencha Desktop Packager, as it takes the API through its paces and gives you a broader view of the intended usage of the APIs.

We believe this functionality to be both extremely useful and of broad appeal, and look forward to your feedback and seeing how you use this technology. Talk to us on the Sencha Desktop Packager forum.

Until next time, happy packaging!