windows store application page refresh

Question 1

How about:

private string parameter;

protected override void LoadState(Object navigationParameter, Dictionary<String, Object> pageState)
{
   parameter = (string)navigationParameter;
   reloadData();
}

private void reloadData() 
{
   var sampleDataGroups = SampleDataSource.GetGroups(parameter);
   this.DefaultViewModel["Groups"] = sampleDataGroups;
}

private void refresh(object sender, RoutedEventArgs e)
{
   reloadData() 
}

Question 2

There is no excellent answer to this question. But let me talk you through some concepts. Of course, there is no refresh, and the reason for this is many fold. Refresh might be added to the Frame someday, but it's problematic right now.

Consider a navigation service

A good way to navigate in your app is to offload this work to a NavigationService class. This is a simple class that has (something like) custom GotoAppHub() and GotoItemDetail(Item) methods.

The purpose of these methods is not because navigation is difficult, it is because navigation can be centralized. It can check & create the Frame; rather than leaving this erroneously in App.xaml.cs.

If your view model wants to navigate to a page, it simply calls NavigationService.GotoItemDetail(item); to do it, passing the item. This is smart for a few reasons, let me talk you through them.

The first reason this is smart is because you may not want to navigate at all. In some cases navigation relies on data being loaded or the user having permissions. Using the navigation service lets you centralize both the navigation logic and the tests necessary to validate the action.

The second reason this is smart is it allows you to retain the parameter passed to the navigation request. Remember that the Frame does NOT serialize custom, complex types. As a result, passing item in this case is a bad practice. The navigation service can persist this parameter somewhere so the target view model can come pick it up. Moreover, it can persist it for your Refresh().

Consider a static repository class

When a view model is loaded, it should be unnecessary for it to know what previous view model caused it to load. Instead the view model should know what it is supposed to do. And to do its work, it needs data. Every view model can use the repository class to ask for the "current" record. That current record will be set by the navigation service when navigation occurs. In addition, the repository class knows what to do when there is no current record, fetching it should it need.

In addition to holding a reference to the current record, the repository class also understands persistence. What I mean is, when the app is loaded, it knows how to fill the lists. When the app is suspended, it knows how to save the data to a file or web service, or whatever you use. The view model, as a result, does not know this and is, as a result, simpler and easier to maintain.

Consider the Reload() method

It is in the navigation service where you need the reload method. Even more than that, it is only in the navigation service where the reload method can be most effective since the navigation service knows the current type and the current parameter value. The navigation service can store these values in local fields and the reload method can simple repeat the navigation.

Remember the back stack, however. This is like a browser's navigation and repeating the navigation will mean that the same page will exist twice and the GoBack() method you also have in your navigation service will not go back until you go back twice. The solution is simple, just remember to remove with Services.NavigationService.Instance.Frame.BackStack.Remove().

Remember the cost of loading

Sometimes when a page loads there is a considerable cost in loading the UI. This is because whatever you are doing isn't trivial. Calling the Reload() will cause the load of the page to repeat. This is a cost you simply cannot overcome. But, there might be dependencies on the loading of the page that should be bypassed. For example, you might initiate a web service operation when the page is loaded - and that operation should not be repeated. This is up to you to retain a static Boolean that indicates the page has already loaded. But it's important you do not forget it.

One more benefit of the repository

A few paragraphs above I mentioned that your navigation service is the one that can remember the last passed parameter for the reload method to work. If you have an internal rule that only the navigation service can write to the concurrency class then your navigation service doesn't really have to remember. It just has to remember the last navigated-to type. That's because the concurrency class will already have the reference to the item passed in. This is, however, not always useful. Sometimes reload is called to throw away the current changes, which means the current item needs to be reloaded or current changes must be flushed. This will all have to be custom, but I would feel bad if I didn't at least mention it.

Conclusion

This should only be taken as a recommendation. Having said that, I have described here the bulk of large, successful WPF and Windows apps in the marketplace. Using the MVVP pattern, the service pattern for navigation, the repository pattern for concurrency - it's all pretty well proven. But you are the developer. In the end, you should choose what is best.

If you don't like any of that, you can do this:

public bool Reload()
{
    if (!this.Frame.BackStack.Any())
        return false;
    var current = this.Frame.BackStack.First();
    this.Frame.BackStack.Remove(current);
    return this.Frame.Navigate(current.SourcePageType, current.Parameter);
}

Best of luck!