0

Right now, I'm working on my first WP7 app and have run into some questions, which I haven't been able to answer despite reading what I could find online. Please consider an app that has a main page, a parameters page and a results page. In the parameters page, the user can enter or update numbers in various textboxes. Hitting the back button takes the user back to the main page, where there is a button called "Calculate". Hitting that button should take the data, perform a calculation with it and take the user to the results page presenting a grid with the results.

In a file called Calculator.cs I have a class called Calculator inside a folder called Models. I also have my MainViewModel.cs, ParametersViewModel.cs, and ResultsViewModel.cs files inside the ViewModels folder and the corresponding MainPage.xaml, along with Parameters.xaml and Results.xaml inside a folder called Views. I'm assuming that all the data will be manipulated within the instance of the Calculator class and then a results set will be returned and directed to Results.xaml. I'm just at a loss as to where to instantiate the Calculator class, pass it data, then retrieve the results. I'm also somewhat puzzled how I will trigger the automatic navigation to the Results page when the calculation is done.

Any help with this would be greatly appreciated.

UPDATE: Passing a complex object to a page while navigating in a WP7 Silverlight application has some more info on the same subject. I can go into App.xaml.cs and add something like this: 

public class Foobar
{
    public string barfoo = "hah!";
}

public static Foobar myfoob = new Foobar();

Then access it from a ViewModel page, e.g. AboutViewModel.cs, like this:

public AboutViewModel()
{
    string goo = App.myfoob.barfoo;
}

But at this point I'm still uncertain what unforseen effects that might have. I'm going to tackle serialization/tombstoning at this point to see what happens with either this approach or by using the same DataContext across pages. Otherwise, one of the posters in the link above mentioned serializing the params and passing them between pages. My concern there would be whether or not there is a character limit as with HTTP GET. Seems there is: URI Limits in Silverlight

Community
  • 1
  • 1
Stonetip
  • 1,150
  • 10
  • 20

1 Answers1

1

There are of course lots of possible designs - and lots of them are correct in different ways!

Here's one I might use:

  • The Calculate button press should trigger the Navigate to the Results page
  • On navigate to, the Results page should show some animation (maybe just a progress bar)
  • On navigate to, the Results page should create a new ResultsViewModel, passing in the MainViewModel as parameters
  • the constructor (or some init method) of the ResultsViewModel should spark up a thread to do the calculation
  • when this calculation is complete, then the relevant properties of the ResultsViewModel will get set
  • at which point the databinding on the Results page will clear the animation and show the results

Other solutions are definitely available - will be interested to read what other people suggest and prefer.

As an aside, one thing to watch out for on your Results page is tombstoning - could be an interesting challenge!

Stuart
  • 66,722
  • 7
  • 114
  • 165
  • Thanks for the thoughts on this. That gives me something to go on. By "passing in the MainViewModel as parameters" do you mean to include them in the URL? Or is there some way to pass the object itself? – Stonetip Jan 31 '11 at 21:06
  • Also, I realize that I'll want to make sure the calculation is complete before setting anything. – Stonetip Jan 31 '11 at 21:07
  • Re: tombstoning. Unless the user has changed any inputs I'll attempt to deserialize just the data that will go into the Grid template on the Results page. I'd hate to run the calculation again. A competing app I use on the iPhone does that each and every time...takes 10-15 seconds. – Stonetip Jan 31 '11 at 21:10
  • I was assuming that your Singleton App object (App.Current) would just own a single MainViewModel - and you could pass this in to the constructor of the ResultsViewModel*. Alternatively (I'm not an MVVMLight guru!) there might be some way of asking some ViewModelResolver object for the current MainViewModel. *If you want more testability then maybe just pass in interface pointers rather than the whole object. – Stuart Jan 31 '11 at 22:06
  • Don't be afraid of coding something and then refactoring it afterwards - it's a good way to learn :) – Stuart Jan 31 '11 at 22:06
  • What I'm doing for now is setting the DataContext for the pages that need it all to Main (for the MainViewModel). It works - in the sense that I those pages have access but I'm unsure if that's a proper way to go about it. – Stonetip Jan 31 '11 at 23:20