WP7Dev Tip 1– Optimizing the app by reusing already created visuals

Developing a good application in the phone need not be accompanied with so much of hacking around or doing lot of non-conventional tricks. Most of the time those tricks make us deviate from the regular ways of development, make the code ugly and unmaintainable.  If we can get a sense of the pain-points and limitations of the platform early, then find a way around it and separate those concerns out of your business logic so as to proceed with a smooth development. I am explaining a pretty basic yet useful idea of how to reuse the complex visuals you have already created in previous pages of the application at runtime. Please note that this may not be applicable to small applications involving two or three pages of total navigation.
Problem : Imagine you have an application which needs to navigate to the same view over and over again. For example the Movie details page of IMDb or Netflix app, or profile page of Facebook or Twitter, those pages get called many times in the life span of an application instance. If we approach it in a standard way of putting a Panorama/Pivot inside a PhoneApplicationPage say MovieDetails.xaml, then each time we go to that page, creates a new instance of the page. Also it creates totally new Pano/Pivot in the visual tree under that page and when you navigate away, that gets pushed to the navigation stack. Suppose this pano when it gets rendered takes up 20MB( IMDb app got more good resolution images in a pano and one MovieDetails took around 20MB to render), so when we navigate to 5 different movies the app holds up a 100MB memory footprint. Since Garbage collection is a lazy operation, that memory wont get easily released. And as you know the platform will kill the app because it reached an unacceptable memory level.
Solution : So now we are clear on one thing, we don’t need to recreate that pano over and over. Because when the first movie details showed up the system did a hard job of creating all those visuals in memory. So it is a matter or showing that pano visual again with a totally different Movie as its new DataContext.
Technical Solution : It is pretty easy to solve this by treating the PhoneApplicationPage as merely a Content placeholder. We can do it in many ways, in my design I have kept only one xaml phonepage and put a special Layout panel (say Grid) in it. And depending on the ViewModel type to be displayed we can always instantiate a DataTemplate(the Pano will be a MovieDetailsDataTemplate in this case) and add that UIElement in to the layout. This operation can be at the PhoneApplicationPage.NavigatedTo() override. Now when this page is navigated away (NavigatedFrom()) we can easily remove that particular UIElement from the layout/page and keep it in the memory. So the next time when it demands a similar view, it will just get loaded back from the memory on to another page instance. This way, all the page instances going to the navigation stack would be pretty much a ‘dummy’ container and wouldn’t hold up any memory at all.
Result : With out this approach we could go only 5 or 6 ‘Movie –> Actor –> Movie’ loops, now we can do 100s of page navigations on that movie-actor loop ( Check out the IMDb app)
And there are many other advantages of keeping a single PhoneapplicationPage class for the entire app, I will be explaining it in my next blog