locked
how important is it to call setPromise from the activated event?

    Question

  • Hello guys.

    I've noticed that the new templates do make a point of calling the setPromise method from within the activated event. is this really important for startup? I mean, it might end up complicating the code a lot...


    Luis Abreu

    Tuesday, June 12, 2012 10:54 AM

Answers

  • It's always 15 seconds. If your app doesn't bring up its first window in that time, it will be terminated. This doesn't change with the deferral--the deferral is just to delay taking down the system splash screen until that complete method is called, but if you don't call that within the 15 seconds, the app will still be terminated.

    If you need more than 15 seconds, you make the first window of your app look like the system splash screen, to minimize the visual shift, and then you can do whatever you want with it such as display progress indicators or other loading UI. This is what an "extended splash screen" really is, and there are quickstarts and samples for it.

    In short, nothing has changed in this release. The deferral mechanism and setPromise were there before, just not as obvious since the templates didn't use them.

    Tuesday, June 12, 2012 8:05 PM

All replies

  • The templates do this so that the splash screen isn't taken down until the page is fully loaded, that is, that WinJS.UI.processAll has completed.

    As I explain in Chapter 3 of my preview book, setPromise hooks into the activation deferral mechanism that WinRT provides. Typically, the system-provided splash screen will be taken down when your activation event handler returns. However, if you want to delay that takedown until an async operation completes, then you can ask Windows for a deferral object in your activation handler, then call that object's complete method when your async operation finishes.

    setPromise within WinJS.Application.onactivated is a wrapper for that deferral mechanism. That is, WinJS automatically asks for a deferral so you don't have to. You can then instead just provide a promise to setPromise and it will call the deferral's complete when that promise is fulfilled. The templates take advantage of this, like I said, to defer removal of the splash screen until WinJS.UI.processAll is complete. You can so the same with other async operations if you have them (combining them, for instance, with the WinJS.UI.processAll promise with WinJS.Promise.join).

    Tuesday, June 12, 2012 5:44 PM
  • Hello again Kraig.

    thanks for pointing out the free ebook (already donwloading it).

    now, back to the question: if I'm not mistaken, there was a some sort of maximum time  for the splash screen to be shown. in fact, I remember seeing some sort of extended splash screen quickstart in the online docs.

    has that changed in this release? Or do we still need to have  extended splash screens?

    thanks.


    Luis Abreu

    Tuesday, June 12, 2012 7:45 PM
  • It's always 15 seconds. If your app doesn't bring up its first window in that time, it will be terminated. This doesn't change with the deferral--the deferral is just to delay taking down the system splash screen until that complete method is called, but if you don't call that within the 15 seconds, the app will still be terminated.

    If you need more than 15 seconds, you make the first window of your app look like the system splash screen, to minimize the visual shift, and then you can do whatever you want with it such as display progress indicators or other loading UI. This is what an "extended splash screen" really is, and there are quickstarts and samples for it.

    In short, nothing has changed in this release. The deferral mechanism and setPromise were there before, just not as obvious since the templates didn't use them.

    Tuesday, June 12, 2012 8:05 PM
  • Hello again Kraig.

    yep, it was there before, but I didn't know that it was used to control the splash screen.

    thanks for confirming that the behavior of the splash screen is still there.


    Luis Abreu

    Tuesday, June 12, 2012 8:44 PM