This project has moved and is read-only. For the latest updates, please go here.

Extending the ApplicationService

Nov 18, 2010 at 11:50 AM

Hi Jeremy,

What would be the preferred pattern for extending the ApplicationService. I want to read extra values from ApplicationServiceContext.ApplicationInitParams and depending on them I want to do some extra actions or for example decide if I want to diplay a login dialog immediately or not.


Nov 19, 2010 at 12:22 AM

The great thing about IApplicationService is you can have as many as you like - you can implement your own. If you look at Jounce, you'll see that the main heavy lifting is done in the "Starting" so the Started method would already have things like the logger wired for you - does that make sense? If not, let me know and I can elaborate further.

Dec 5, 2010 at 3:50 PM

Hello Jeremy,

Our application uses Windows authentication.  On Application_StartUp, I make an asynchronous call to Authentication.LoadUser.  This call must complete (successfully) before any of the views which are initially loaded ( navigation and home page) can make WCF RIA services calls to populate various fields.  Typically (but not always) the shell will load the nav and home page before LoadUser completes, hence I need a synchronization method.  Can you provide some guidance with respect using the Jounce Application.Start method to call LoadUser and process the asynchronous UserLoaded callback,

Thank you.


Dec 5, 2010 at 4:00 PM

I've had similar scenarios and it's fairly straightforward. There is no issue with the shell loading if there is nothing bound yet. You just don't want your loaders for the navigation/etc to fire before the user context is ready. I'd still have a separate IApplicationService to handle that, and when it's done it can fire an event. The view model on the main page simply registers a sink for the event and makes it's calls once the event is fired.