Passing data from page to page

Question

I'm looking for the best practice on how to pass data from page to page.

In Page A I have a button that fires off Page B.
On Page B I have 6 textboxes that allow the user to enter information. When the user is done, the click on a button that brings them back to Page A.

I want to pass that data back to Page A.

I've seen suggestions to:

• build XML documents and save to Isolated Storage
• use the App class to store information in properties
• pass it like a query string

I'm looking for the Best practice. Is there one that Microsoft recommends or one that is generally accepted as the best way?

Thanks

Answer 1

You can also keep it simple and use PhoneApplicationService.Current.State which is basically a hashtable. You will need to implement your own marshalling to and from isolated storage if you want anything to outlive the app.

Omar's suggestion to use the Windows Phone Databound Template is probably the best idea on this page. It amounts to the same as my suggestion but you will get a better result (more maintainable code) at the cost of a longer steeper learning curve.

I suggest you do it my way and then do it again Omar's way.

Answer 2

One option is to use Application.Resources:

Store data:

Application.Current.Resources.Add("NavigationParam", customers);

NavigationService.Navigate(new Uri("/Page2.xaml", UriKind.Relative));

Retrieve data:

var customers = (List<Customer>) Application.Current.Resources["NavigationParam"];

Here's a blog post with describes this in more detail: http://mikaelkoskinen.net/windows-phone-pass-data-between-pages-application-resources/ (author: me)

Answer 3

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"];

Answer 4

If you create a new Windows Phone project and use the Windows Phone Databound Template you will have most of the work done for you.

What you will want to do is set up the ViewModel to contain all the data for your app. You can serialize and deserialize this data using IsolatedStorage so that it's saved across application sessions and when Tombstoning.

In the template you will notice MailViewModel and ItemViewModel. MainViewModel stores all the data your application needs including an ObservableCollection of ItemViewModel, and ItemViewModel represents the individual data type for your application.

On the DetailsPage.xaml page you'll want to DataBind each textbox to the App.MainViewModel Items. Set the binding to TwoWay if you want the ViewModel to get updated as soon as the user manipulates the data on DetailsPage.xaml. You can optionally set the Binding to OneWay and then have an OK button that writes the changes back to the ViewModel and saves to IsolatedStorage.

Here is an example of what a Binding looks like:

<TextBlock x:Name="ListTitle" Text="{Binding LineOne}" Margin="9,-7,0,0" Style="{StaticResource PhoneTextTitle1Style}"/>

In this case LineOne is a property in ItemViewModel and the page gets this data from the query string when the user selects an item from the MainPage.xaml. The DataContext for the page determs where the databound information comes from.

Here is the snippet where the MainPage passes the selected item from the ViewModel to the DetailsPage.

// Handle selection changed on ListBox
private void MainListBox_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
    // If selected index is -1 (no selection) do nothing
    if (MainListBox.SelectedIndex == -1)
        return;

    // Navigate to the new page
    NavigationService.Navigate(new Uri("/DetailsPage.xaml?selectedItem=" + MainListBox.SelectedIndex, UriKind.Relative));

    // Reset selected index to -1 (no selection)
    MainListBox.SelectedIndex = -1;
}

Here is how the DetailsPage gets the selected item.

protected override void OnNavigatedTo(NavigationEventArgs e)
{
    string selectedIndex = "";
    if (NavigationContext.QueryString.TryGetValue("selectedItem", out selectedIndex))
    {
        int index = int.Parse(selectedIndex);
        DataContext = App.ViewModel.Items[index];
    }
}

Play around with the default template above and ask any additional questions.

The beauty of databinding and the ObservableCollection is that you can just update the data and the UX will reflect those changes immediatley. This is because any changes to the data fires off an event:

public string LineOne
{
    get
    {
        return _lineOne;
    }
    set
    {
        if (value != _lineOne)
        {
            _lineOne = value;
            NotifyPropertyChanged("LineOne");
        }
    }
}

NotifyPropertyChanged() that broadcasts this information to the View.

Answer 5

There's a couple of things at play here. First of all, if/when the user uses the Back button to return to page A instead of your button, is the information in the text boxes exchanged or not (is Back = Cancel, or is Back = OK?)

That said, if you're using NavigationService.GoBack (which you should be instead of NavigationService.Navigate, because if you use the Navigate call, repeated hits of the back key will cause all kinds of bad UX for your users), then QueryStrings are not an option. Because pages really have no way to reference each other in the WP7 Silverlight nav system, you need to use a 3rd party to hold your data. For that, you can turn to (a) Isolated Storage (slow & heavy, but fail-safe), (b) Use the PhoneApplicationService.State dictionary, or (c) use Global properties of some kind, either hung off of the application object, or using Statics/Singletons...

Remember to watch for Tombstoning behavior when you do this - your page will process the OnNavigatedTo method when (a) you navigate into it in your application (b) you navigate back to it when you complete your work on Page B, or (c) you tombstone your app from that page and return to your application using the Back key.

Sorry I didn't give a more direct answer there - a lot depends on your specific circumstances. In the most general case, I'd strongly consider using the App State Dictionary on the PhoneApplicationService...it is lightweight, easy to use, and survives tombstoning. Just be sure that your keys are as unique as they need to be.

Answer 6

One thing you can consider is to use MVC: let your App be the controller, store all data in the model, and the pages are just views that contains pure UI logic. In this case your pages are painters and you pass your model object around. This gives nice isolation of business logic and the UI so that you can rev them easily.

BTW, Silverlight and XAML are great tools for MVC so it's a natural match.