3

All, I am new to Windows 7 Phone. My situation is that I have a main page which contains a ScrollViewer which in turn houses a StackPanel. I want to populate this StackPanel with multiple sub-StackPanels (at runtime) which are to hold an Image Thumb nail a hyperlink and some basic information about the image.

This is all good when I do this from the main page, but I want to know how to update this control (which is on the main page), but from any page other than the main page. I would like to know what is considered best practice for updating a page's control (like that outlined above) from another page.

Obviously there are a number of ways to pass data between pages

PhoneApplicationService.Current.State["yourparam"] = param
NavigationService.Navigate(new Uri("/view/Page.xaml", UriKind.Relative));

then in other page simply

var k = PhoneApplicationService.Current.State["yourparam"];

and many others. But what is best practice for updating a generic control from a different page?

Note: There are many question about data access and passing between pages.

  1. Passing data from page to page
  2. How to pass the image value in one xaml page to another xaml page in windows phone 7?
  3. Passing image from one page to another windows phone 7

and more. This is not what I am asking.

Community
  • 1
  • 1
MoonKnight
  • 23,214
  • 40
  • 145
  • 277

2 Answers2

3

If I understand your question correctly, you are trying to update a control which is on for example MainPage.xaml from another page for example Page2.xaml.

As far as I know there is no way to reach a pages controls from another page, and that seems unnecessary for the cases that I can think of.

The method used to achieve what you are trying is usually done by triggering an action (like the press of a button ) and passing a parameter to the page you are trying to update the control. And on that page's onnavigatedto event (or viewmodel constructor if you are using the MVVM pattern), update your control based on the passed parameter.

If your update is based on data then the best practice is to bind an observable collection or an object that extends the INotifyPropertyChanged (basically any object that can signal that one of their property changed to the ui) and change the data based on the parameter that is passed.

If these two pages somehow are visible at the same time and there is no navigation needed between them( like a popup or sliding menu kind of ui) then you can make the page that you are showing in the popup a usercontrol, and reach to the parent's controls by this.Parent.

I can be more helpful if you give more specifics about your app's flow.

omerkirk
  • 2,527
  • 1
  • 17
  • 9
  • That is already massively helpful. You have it correct in your first paragraph. I have a basic windows phone application which will have at most 3/4 pages. The main page is to contain photos and info that will be created on/from other pages in the application. I suppose I could store what I want to display in IsolatedStorage and get the infomation and populate the main page from there when it get restored. I will be sure to check out the MVVM pattern, I have heard of it but I am very new to windows phone development, thanks for your time... – MoonKnight Apr 06 '12 at 11:33
  • 1
    You can keep your data that is to be accessed by your main page in a global static class and when you navigate back to your main page take the photos and other necessary data from that class and update your UI, which is not a very elegant solution but it will get the job done. MVVM is a good pattern to learn however for small apps, or very small teams like 1 or 2 people it can be unnecessarily complicated. Definitely learn it but if you are not working seperately with a designer for ui and a developer for codebehind you probably do not need to use MVVM. – omerkirk Apr 06 '12 at 12:08
2

The MVVM pattern would be a good way to go. Saying MVVM is too complicated for small teams isn't exactly accurate - the purpose of MVVM is to decouple Silverlight or WPF code. Using the codebehind of a Silverlight page to directly access data creates coupling in your code and accrues technical debt. Whether you're one developer or 100, if your UI is coupled with your data classes, if you have to change your data classes, you will have to make changes to every UI element that uses those classes. This takes longer and makes your application more difficult to change.

MVVM makes it so your UI (the View) doesn't know anything about the data (your Model). The ViewModel is the code in between that the UI can bind to, and which manages events in the UI that need to be persisted to the Model, and also changes in the Model that need to be represented in the View. For this reason, it handles events, and that's what it sounds like you need in your code - an event that can exist off of the codebehind, that can update the Views bound to it when the data changes. If you have two pages, then an event on one of the pages will be sent to the ViewModel, which will make a change to the Model (data) if necessary, and pass it back to the ViewModel. The ViewModel would then update any of the UI elements (Views) bound to that piece of data.

There's a REALLY good demonstration of how to implement the MVVM design pattern here . The guy goes through and takes a typical WPF application (just like Silverlight), where the UI codebehind implements event handlers that directly access data, and refactors it using the MVVM pattern.

Andrew B Schultz
  • 1,512
  • 1
  • 23
  • 41