|Windows Phone 7 - using the Panorama control|
|Written by Mike James|
|Monday, 20 September 2010|
Page 4 of 5
The generated code
After sorting out the details of the XAML generated it is time to look at the way the code uses the generated objects.
First thing to realise is that all of the data displayed by the Panorama control is stored in the ViewModel. It is transferred to the. Panorama control automatically by databinding. The actual moment of binding occurs in the MainPage contructor:
Notice that the binding is two way and the ViewModel implements the INotifyPropertyChanged Interface.
The page load event handler is set to actually start the data loading, assuming it hasn't already loaded.
private void MainPage_Loaded(
This is all that has to be done in code to get the Panorama control displaying the data in the ViewModel.
If you examine the code in the ViewModel you should be able to follow what it is doing. Its constructor simply creates an ObservableCollecion object which stores objects of type ItemViewModel - i.e. this is the actual collection that the Panorama control is bound to.
ItemViewModel objects are used to store the content of each Item in the Panorama control. There is also some example code showing how to implement a runtime property. The main work however is done in the LoadData method were the ObservableCollection object i.e. Items has a number of new ItemViewModel objects added to it using instructions like:
This only makes sense because back in the XAML there is ListBox containing objects, TextBlocks in this case, with bindings to specific properties called LineOne, LineTwo and so on. In other words each of the ItemViewModel objects supplies its properties to the TextBlock contained by the Panorama object.
If you want to extend this mechanism to work with your own data then you need to first customise the Parorama object with whatever display controls you need and bind them to new properties on the ItemViewModel object that will hold the data.
You then have to go to the ItemViewModel class and create these properties so that the binding can work. The generated class has examples of how to implement the properties complete with the NotifyPropertyChanged event.
Finally you then have to customise the MainViewModel to store create the right number of ItemView objedts intialised to using the data that you presumably get from a web service or a data source. The manual initialisations in the sample are there just to avoid having to actually get some real data. If you are going to continue with the MVC style of approach you should also write a Model object which acquires the data from the web service or what ever, creates a data object with the raw data, passes it to the View object which then places it in the Panorama control by data binding.
How do you bind different data to each page?
There are many ways of doing this but the simplest is to keep a collection object for each PanoramaItem in the control. For example call the first collection PageOneItems and the second PageTwoItems and so on and bind each ListBox to its appropriate collection. Of course there is no need for each of the collections to store the same type of object so you can completely customise each page. Generating a given number of pages at runtime is more complex but follows the same general outline but generating the objects dynamically in code.
Of course if you don't want to follow this design you don't have to. You might not have data that is as regular and a more ad-hoc approach might work for you. However in don't simply abandon a good design simply because it takes longer to setup in the first place. Such approaches tend to pay back over the life time of a project much more than the initial extra cost of using then.
|Last Updated ( Monday, 11 October 2010 )|