Navigation (yet again), deep linking, browser history

Topics: Framework Services
Jun 6, 2011 at 8:07 PM

So how are all of you handling deep linking and browser history (e.g. back button) integration in Silverlight (not WP7)?

I get the preference for viewmodel first, but I'm not seeing the obvious solution for browser integration.  Having the browser back button throw you out of the app instead of back a "page" in your app when working in Silverlight in the browser isn't an acceptable situation for us.

I've seen a couple of stabs at projects implementing Silverlight 4 navigation with Caliburn Micro including and but neither option seems clean and complete.  (No offense intended)  It appears to me these options approach the problem differently than the WP7 navigation support in CM.  They take view model location away from CM and have new code for it.  I would rather see as much delegated to CM as possible and avoids alternate implementations.

I am surprised that the navigation support in CM required for WP7 isn't also available in CM for Silverlight 4 navigation.

So what am I missing?  Is there a different approach for this browser integration instead of using Silverlight navigation?  Is Silverlight navigation support in CM and I just missed it?  Do I need to write it myself?  Do the rest of you just write your Silverlight CM apps without deep linking and browser history and back button integration?

Rob, any plans to port FrameAdapter, et. al. to the Silverlight implementation?  Or some reason it shouldn't be done at all (besides the fact that you don't like view-first?)  I'd hate to stumble through doing it myself only to eventually figure out why it isn't feasible or have you provide us a clean and throrough implementation that made my mine useless.

Jun 7, 2011 at 1:35 PM
Edited Jun 7, 2011 at 1:37 PM

I've only built deep linking for one application....and the client ended up not using it or caring that it was there. As a result, I haven't invested too much into this. There's nothing wrong with porting the WP7 pieces over to Silverlight, if you like that approach. I'm not planning to do it. If I were going to add deep linking, I would take more of a front controller approach combined with a ShellVM (a basic Conductor<T>). The Front Controller would detect uri changes and translate those into a ViewModel. It would then push the query string parameters into the view model, finally it would tell the ShellVM to activate it. The tricky part of this can be in memory management and state. If you want the back button to work a little nicer, you will want to keep the VMs around after they are navigated away from. However, this gets tricky as you can run out of memory if you have lots of screens. This is the exact problem that the WP7 nav system has. So, you probably want the Front Controller to contact a back stack. The back stack should probably be implemented where the bottom node is replaced by a special factory after a certain number of items are added. The factory would allow you to take the screen out of memory but provide a way to recreate it with the appropriate state if the user backs up that far. Does that all make sense? The point is that you shouldn't have to alter any of CM at all or use any special controls. This can all be layered on top of a basic Conductor. In fact if this were built correctly, you should be able to take any app with a Conductor<T> as its root VM and just drop navigation in. This would make a nice contrib project...:) If you are interested in building this, I'd be happy to provide guidance, code reviews, etc.....I just can't support or maintain it. I'm already at capacity. But, I do think this would be valuable, especially as a NuGet package that someone could just drop in.

Jun 7, 2011 at 9:55 PM

Thanks for your thoughts Rob.  I'll consider this recommendation and opportunity.  If we are going to use CM, I have to do something to handle browser navigation.  Your willingness to offer guidance, code reviews, etc. is appreciated and I just might step up for this contrib project.  We'll see.

Feb 3, 2013 at 9:34 PM
I was wondering if anyone had implemented the above suggestions, as I'm going to need to implement something similar in WPF (desktop application, not phone).