Even a chimp can write code

Wednesday, March 18, 2009

Introducing Offline and Out of Browser support in Silverlight

Today we are making a radical upgrade to your web experience with Silverlight 3’s support for offline and out of browser apps. App authors can now build one app that works in the browser and out; at home, at work or on the go.

Among the new set of features enabling this experience are:

  • Sticky presence on the desktop: Upon user consent, a Silverlight app can be detached and pinned on the user’s desktop using familiar OS metaphors for this action. On Windows this can be through Start menu and/or Desktop shortcuts. On the Mac the user can drag and drop the application bundle to a location of their choice.
  • Run outside of browser: activating the app locally launches it outside of the web browser. Our data suggests consumers find this more intuitive as a result of clicking on a desktop shortcut. 
  • Safe by default: Silverlight still retains a rigid security sandbox within which the app operates. Apps cannot elevate beyond the privileges granted by this sandbox. Our philosophy is to stretch this sandbox by providing features within it on a case by case basis. More on this in future.
  • Non-administrative install: Along with the sandbox, Silverlight furthers the consumer’s security by never requiring administrative privileges either for install or for run. An exception may be if optionally a user on the Mac wants to drop the app bundle into a dir that requires sign-on. In that case Silverlight honors the framework set out by the OS and user intuition.
  • Higher default persistence space: the default quota for Isolated Storage for Out of Browser apps is a higher value than for browser based apps. It is currently 25MB.
  • Network awareness: One of the key ingredients of this feature set is the ability for Silverlight apps to be aware of network connectivity and to be notified when that changes. Apps can cache data (or outbound calls) into Isolated Storage and post-back (or playback) when connectivity is regained. This works in Silverlight apps in the browser and out.
  • Built-in auto update: Silverlight will check for new versions of the app asynchronously upon app requesting such a check, guaranteeing users an instant-on experience. Updates are applied at next launch, providing apps complete control over when and how frequently updates are applied with Silverlight doing all the heavy lifting.
  • Execution state notifications to the app: Silverlight notifies the app on momentous events throughout its lifetime and transition from in-browser to out-of-browser, allowing the app to model its UI accordingly.

A short note on our philosophy before I end: When my team and I originally started thinking about delivering this feature set, we were absolutely certain about some things. Namely that this would be inherently a part of Silverlight, requiring no new runtimes/frameworks, no additional downloads, no new learning curve for app authors, no security elevations for consumer installs. That is the Carmot, if you will, in our offline and out of browser support. We’re also introducing a user experience that – in my biased opinion – fits well with the rest of the web; a model that allows consumers to try before they install; a model that takes an app familiar to them on the Web and makes it a companion on their desktop. Contrast that a model that requires consumers to have “install intent” and click on a hyperlink or a badge in good faith to experience an app they haven’t hitherto seen. There’s certainly a place for that install model and we’ve supported that in other products in the past for non-Web scenarios. And finally, I’m closely watching where support for offline applications in HTML5 goes and how mainstream browsers adopt it. At some point I do want our model to co-exist with the experiences they introduce.

Developers can evaluate and play with the Silverlight 3 Beta build these apps using Silverlight 3 right now. There's great runtime and tools support.

In future posts, I will be introducing this feature set from a technical perspective.

Post script: You can now understand why there’s been radio silence on this blog for months. This feature took a lot of Mountain Dew, sweat and tiers from a couple handful of the best darned engineers in the world. And a lot of questions, comments, critiques and feedback from the best darned customers a product can have. Here’s to takeoff and the EAP!



[Update 10-Jul-09] Auto-update section modified based on changes post beta; now reflective of Silverlight 3 RTW behavior
[Update 25-Jul-09] Links updated to Silverlight 3 RTW

Labels: , ,

Email this | Bookmark this

14 Comments:

  • ya'll are kicking some serious a**.

    By Anonymous Anonymous, at March 18, 2009 at 5:12 PM  

  • Great post, and the growing SL featureset is truely impressive. Keep up the hard work - in my humble opinion this is groundbreaking progress.

    By Blogger Aaron Steers, at March 18, 2009 at 7:21 PM  

  • log awaited feature :)
    rock on.
    but what about [enter desired] feature...
    just kidding ,
    keep up the good work.

    By Blogger daniel cohen, at March 19, 2009 at 12:23 AM  

  • Hi Ashish,

    congrats with the beta release.

    The way you concepted the oob-feature is very impressive. I think it can play a major role to rapidly broadening the Silverlight installation base in the Internet.

    I'm looking forward for a technical in-depth article.

    One of our apps is a web shop, and during the checkout process we have to transfer the user to the credit card payment page hosted by a payment provider. So I need to know in what kind of environment a oob-app is running and what is possible.

    By Anonymous Anonymous, at March 21, 2009 at 9:16 AM  

  • Everything being equal, what's so exciting about silverlight vs. xbap applications? Admittedly, you get cross plateform support with silverlight (not confined to Windows only) but you have much richer control/library support for the xbap case.

    I fail to see the point of this work.

    By Blogger Tanveer Badar, at March 21, 2009 at 1:14 PM  

  • Actually, I meant to say what advantage does silverlight's out of browser app mode offers over WPF application deployed through clickonce?

    By Blogger Tanveer Badar, at March 21, 2009 at 11:13 PM  

  • Ashish,
    Thanks for delivering this excellent feature in the beta!

    By Anonymous Anonymous, at March 23, 2009 at 9:27 AM  

  • What is a work around to resizing the window size when running in Detached mode?

    By Anonymous Anonymous, at March 23, 2009 at 10:43 AM  

  • There isn't a workaround to resizing the window. It's one of the things on our backlog of things to do.

    By Blogger Ashish Shetty, at April 13, 2009 at 5:18 PM  

  • Great post

    By Anonymous The Fuzz, at April 19, 2009 at 12:00 PM  

  • nice post

    By Anonymous web design company, at May 7, 2009 at 11:35 PM  

  • Hi,
    I used information from your articles in my post ( geekswithblogs.net/.../silverlight-3.0--plus-out-of-browser-equal-rda.aspx ) but I placed link to this site. Thanks and I hope you don't mind. :)

    Regards,
    Jacek Ciereszko

    By Blogger Jacek, at May 31, 2009 at 2:48 PM  

  • To allow for a rich cross platform application the developer should be able to set two properties for the SL app.

    1)App requires oob install.
    2)App requires full trust.

    When the silverlight page loads in the browser the SL CLR can prompt the user that the app needs to be downloaded/istalled to run.
    Then when the application installs the the SL CLR can prompt the user: This app needs full trust to run properly, do you trust this app...

    That way the app is no longer sanboxed by being in a browser and given a higher trust by the user thereby allowing for a more functional app.

    One use eg. Been able to freely use httpwebrequest to access webpages without network security restrictions.

    By Anonymous Bruce, at August 21, 2009 at 1:45 PM  

  • OK. Now I get it. I was confusing Silverlight with smart client dev so that to me made the SL client app winforms.

    After the different courses my understanding is much better. Its a RIA, its a web app on the desktop. Being a web app makes it cross platform so a MAC user won't need to use a VM to run it since it runs in the browser. Way smart. And when you have a web app that should be offline also you only have to do your code once and the PC and web side can share that. This is too smart for words. Perfect for what I've been wanting to do.

    Now OOB confused me because I was wondering and trying to find why the OOB need? What advantage does it offer more power to the machine? If you must be a desktop app why not WPF/winforms but, then the cross platform part is lost and a VM would be needed. The underlying technical work for multiplatform targeting is done by Silverlight so you won't have to concern yourself with that messiness as before with smart clients that closely matched web/client sides to be the same.

    So my app can be for Mac and Linux users since its Silverlight. I really am not doing any thing native, the IO shields me from worrying bout native code for IO routines making my app more accessible and faster to right for Mac and Win users to use This is so powerful. Its amazing. Oh the headaches from 2005 trying to do this on my own and having to give up on things that would take too long to implement.

    I was wondering if I should bother learning another dev tech but, Silverlight is the best thing for today's apps. So, I'm going Silverlight all the way. When SL1 came out and you offered that free web hosting it was nothing like SL3 and plus it was so geared to streaming video companies. I had an app that needed to have the same functionality on and offline for a bulk of the app features and was duplicating things just using different namespaces for winforms and webforms.

    Why does anyone bother with php and all that overhead to get on a win machine and communicate with the web server is beyond me. MS haters are missing out on this one.

    Sorry, my epiphany had me post this very long posts.

    Thanks,

    Monique

    By Anonymous Anonymous, at February 7, 2010 at 9:12 PM  

Post a Comment | Home | Inference: my personal blog