With this in mind we decided to create a complete sample app for Windows Phone that will be free to download and study in order to help you with your Windows Phone development. It is a Picture Gallery app that demonstrates how to create a native Windows Phone client for Flickr or another image service. The Picture Gallery is built with the Telerik Windows Phone UI controls and design templates.The app is designed so that it can be easily extended to support more web services which will be described later. In this blog series we will look at the overall app architecture, how to pass information between pages as well as how to persist information so that it is available the next time the app is launched. At the end we will also discuss how to handle error conditions and how RadControls for Windows Phone and the design templates were used while developing the app.
The Picture Gallery for Windows Phone is built around the MVVM pattern that is so popular with XAML based applications.The app is, as the pattern dictates, separated into models, view models and views. The views are everything XAML (pages, user controls etc.), the models are the objects, with which the specific web service works, and the view models are abstractions that separate the views from the models.
Now before we actually do anything, we will have to make a few assumptions. Since we are dealing with images we assume that each image has an author, may have comments associated with it, that the image service provides means to search its database for authors and photos and that authors may have galleries associated with them. In short we assume that the following functionality is supported by the image service: image, author, gallery, people/images search.
With these assumptions in mind let’s start with the view models. They are supposed to represent the information for any model that a particular web service works with. All view models in the picture gallery App are created by an implementation of the IImageServiceProvider interface. This interface contains methods like GetPhoto(), GetAuthorOfPhoto(), GetCommentsForPhoto() etc. All these methods return view models. This encapsulates all knowledge of the models inside the image service provider. So when we decide to support Picasa for example we just have to create a new image service provider that implements the IImageServiceProvider interface and the rest of the application will/should just work :).
Every view model has one or more corresponding views that visualize it in different ways. For example the PhotoListViewModel (a sophisticated collection of PhotoViewModel objects) has a PhotoCollectionView that displays the photo list. Also, there is a CommentsView that is capable of visualizing the comments for a specific photo view model. There are of course other views for the AuthorViewModel, GalleryViewModel etc. The views themselves are really just xaml elements that bind to certain properties of their DataContext (which is a view model). That’s all there is to it and if MVVM is successfully implemented, you should be able to completely rewrite your UI without any code changes (view models). The only link between the views and the view models should be the binding mechanism of the Silverlight framework.
Finally the models are the specific types that a particular image service API works with. For example the models for the Flickr service provider are the types of the Flickr.NET API. We will only need to be concerned with writing models if we are forced to work with a raw web API that has to be encapsulated.
The source code of the Telerik Picture Gallery app for Windows Phone is available for download here. To run the picture gallery a Flickr API key is required. That key has to be passed to the constructor of the flickr object insde the FlickrServiceProvider.cs file.
Coming up next is a blog post on how favorites and passing state between pages are handled inside the app.
Copyright © 2016, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.