Silverlight out-of-browser apps: The Install

There are three main pillars to the new offline and out-of-browser feature set in Silverlight. These pillars are also tied to user experience; namely Install, Launch and Manage. In additions there are framework-level APIs and behind the scenes support from the runtime for a plethora of things that cross-cut these 3 pillars. 

In this post we will look specifically at the Install operation.

A Silverlight app needs to be specially crafted for that out-of-browser function. There’s not much to it really: the application manifest (AppManifest.xaml) should be adorned with the OutOfBrowserSettings element which declares such metadata on the app as short name, window title, blurb and icons. No worries, tools make this easy for you via the Silverlight application project properties pane. Silverlight treats the presence of this element as an indication from the app author for opt-in to the out-of-browser feature set. Only this class of apps can be “installed”.

The install operation itself can be achieved in one of two ways:

• via platform UI on the context menu that says “Install {app short name} onto this computer…”
• via app driven UI which calls the Install() method on the Application type

Implicit in either case is the fact that install is required to be a user-initiated operation. And that too user-initiated within the Silverlight display surface on a web page. This allows us (building the runtime and platform) to better control the user experience and guarantee predictability, security etc.

Further, Silverlight apps cannot be installed without the consumer end user specifically consenting to this action. This removes the element of surprise. We’ve tried to maintain consistency with the experience one intuits on a particular operating system, while also balancing the needs of Silverlight app authors and our own user experience goals. As a result, you will see different UX on Windows and Mac – each appealing to its demographic.

On Windows, Silverlight shows an application modal dialog like this, seeking the user’s permission to proceed:

The dialog is modeled as a confirmation dialog, and the user is asked to allow or deny permission in context, with the assertion “You are installing {app short name} from {domain of origin}”. 

The astute reader will notice that the dialogs are similar across Windows and Mac OS X – at least in principle – but each adheres to the native OS theme. The Mac dialog does not seek shortcut preferences, given that Mac users are expected in the very next step to drag the out-of-browser app bundle into a location of their choice, much like they would when installing another application.

A dialog of the form above is shown when the app declares no icons of its own. You see the “fallback” icon shown by the runtime.  When the app declares its own brand icon, Silverlight will gladly display it at install time, as the following screenshot of the dialog on Windows attests: If the install were initiated via the Install() method call on the UI thread, the method would synchronously block until the consumer end user made their decision. If they declined, the method returns false; otherwise true. The other install related activities happen asynchronously. The platform signals this to the app via the InstallStateChanged event and the InstallState.Installing state; it inducts the XAP, along with some metadata and housekeeping information into the offline application cache within the user’s profile dir. When this is successfully completed, the platform raises the InstallStateChanged event with the InstallState.Installed state. This is the official notification to the hitherto in-browser app that its out-of-browser copy has been installed. The out-of-browser app gets a higher default quota (25MB to the previous 1MB) within Isolated Storage for its local data persistence needs. The in-browser and out-of-browser apps share this Isolated Storage with each other. We’re not yet sure if the magic number of 25MB is the right one (or if there is in fact any right value); it is however orders of magnitude higher than the default for in-browser apps and we hope it will open up new scenarios and result in the proverbial 80% of our apps not having to ask the consumer user for a quota increase yet again.

Upon successful install, Silverlight auto-launches the newly installed app – all sandboxed, out of the browser, and ready to go! The salient points of this Install operation are:

• keep it lightweight
• showcase the app brand, not the technology powering it
• keep the decision simple for the consumer, and in context
• get the consumer to their desired goal in the shortest time possible i.e. launch the app upon install

More about the story behind the Launch experience in the next post. Until then, cheerio, toodle-ooh and all that.

Related posts:

• Introducing Offline and Out of Browser support in Silverlight
• Silverlight out-of-browser support: What kind of apps can you build?

[Update 10-Jul-09] API names updated to reflect Silverlight 3 RTW

Email this | Bookmark this