Is there a best practice for handling tombstoning and back key properly?
As it is stated in the MSDN docu you should save transient data in the OnNavigatedFrom method. Ok, so the code for saving states when tombstoning is clear.
But now if you press the back key the OnNavigatedFrom method is also called and if you don't add extra checks, you will first save states into the dictionary and shortly after that the page will be destroyed. And so will the PhoneApplicationPage.State dictionary. So the saving code is completely wasted CPU, disk and battery time.
This is what I've done to prevent it:
protected override void OnNavigatingFrom(System.Windows.Navigation.NavigatingCancelEventArgs e)
{
// when navigating back
if (e.NavigationMode == System.Windows.Navigation.NavigationMode.Back)
{
backKeyPressed = true;
}
}
protected override void OnNavigatedFrom(System.Windows.Navigation.NavigationEventArgs e)
{
if (backKeyPressed)
{
// Don't save states on back key!
backKeyPressed = false; // set it anyway
return;
}
// Tombstoning
// save objects
this.SaveState("text", someText);
...
}
As a reminder: OnNavigatingFrom will only be called when navigating away/back from the page but not when app gets tombstoned.
Side note: Shown code covers only pages that can only navigate back. Thats why I added backKeypressed to OnNavigatingFrom. You need extra checks if the page can navigate to another page.
Is there a better way to do this for every page you create?
Now do I really have to add the backKeyPressed variable and check on every page I create?
Shouldn't the framework provide something for us developer so we don't have to worry much about this?
What are your thoughts about this?
EDIT:
Updated question the make it clearer.
your approach of checking the direcetion of navigation in OnNavigatingFrom is indeed the recommended practice in order to avoid the unneccessary performance hit of saving state just before the page gets removed from the backstack.
There is one clarification I want to add to your sample code: You should check the 'NavigationMode' property in the 'NavigationCancelEventArgs' to determine whether it's a forward or backward navigation.
Then only save the state in OnNavigatedFrom if it was a forward navigation, as your sample shows. This will help improve your performance when the user navigates backwards.
Everything you ever needed to know about tombstoning is covered in Jeff Prorise's 4-part Real-World Tombstoning in Silverlight for Windows Phone 7 blog post series. You may want to pay particular attention to part 2 where Jeff talks about clearing up state when the application quits.
Related
I wanted to add a lazy loading list box(load content when swipe) in a panorama page in one of my windows phone 7 applications. I could however do it using a pivot page. I referred this link
But this is not working with panorama page. Can anyone please help me?
Okay, you're going to need to do one of two things: use the BCL Async package (basically adds async Tasks and such to WP7) or use a background worker. I highly suggest the BCL Async package, it's easy to get on Nuget.
Now, in your ViewModel (you are using MVVM, yes?) the property that it's bound to, let's call it Items should return an ObservableCollection of the item type you need. Now, here's where the magic happens. In the Getter of that property, return a new collection and use a task to fill it. Something like this:
public ObservableCollection<object> Items
{
get
{
ObservableCollection<object> retCollection = new ObservableCollection<object>();
FillCollection(retCollection);
return retCollection;
}
}
public async void FillCollection(ObservableCollection<object> collectionToFill)
{
Task.Factory.StartNew(() =>
{
foreach(object objectToAdd in collectionImGettingThisDataFrom)
{
// We do this using the Dispatcher to
// be sure to pop back into the UI thread.
Deployment.Current.Dispatcher.BeginInvoke(
() => collectionToFill.Add(objectToAdd));
}
}
}
Because FillCollection is async, the Get method will continue and return the current collection. On another thread, the Task that's created will find the data to add, then push it to the UI thread to add it into the collection. This way, you'll be able to lazy load the data only when you ask for it, without completely blocking your UI thread. If it turns out that it's still making your UI slow, you can add the line:
await TaskEx.Delay(25); // Some time in milliseconds. Too much and it will
// take a long time to load the list,
// too little and it will still bog down your UI.
At the end of the foreach block, but not in the Dispatcher invokation.
Happy coding!
Have you looked at the Telerik Rad Controls yet? They have all types of pull to refresh controls. I used them in a recent app I released called "Rad Libs". You can see the controls here http://www.telerik.com/products/windows-phone.aspx and you can also download an app that demos all of their controls. (Disclaimer: I have no affiliation with telerik. I stand to gain nothing from promoting them here)
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
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"];
Personally I'd store the values entered on Page B in a model(object) that is also accessible to Page A.
Depending on how you're navigating to Page A the second time, one or more of the following may be usful to help understand passing values between pages:
How to pass the image value in one xaml page to another xaml page in windows phone 7?
Passing a complex object to a page while navigating in a WP7 Silverlight application
How to pass an object from a xaml page to another?
How to pass a value between Silverlight pages for WP7?
How do I navigate from one xaml page to another, and pass values?
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.
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.
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.
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.
as i implemented like this.. Whether its correct or not i dont know..
When u click news list page it should open the news detail page.
I want to pass the selected news item contents from news List-Page to news-details Page.
the News list page contains following method.
protected override void OnNavigatedFrom(System.Windows.Navigation.NavigationEventArgs e)
{
NewsDetailsPage newsDetailPage = (e.Content as NewsDetailsPage);
if (newsDetailPage != null)
newsDetailPage.SelectedNewsItem = SelectedNewsItem; //Contains the news details
base.OnNavigatedFrom(e);
}
In the News details Page. U can access that(SelectedNewsItem) object.
This may or may not be correct.
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)
I see two basic ways to implement "loading" feedback (e.g. swirly loading icon):
In the presenter:
void displayData()
{
display.startShowingLoadingIcon();
startLoadingData();
}
void onDataLoaded()
{
display.stopShowingLoadingIconAndDisplayData(data);
}
In the display:
void showData()
{
startShowingLoadingIcon();
presenter.getData(callback);
}
Callback callback(data)
{
stopShowingLoadingIconAndDisplayData(data);
}
I like the second solution because it seems like loading feedback is clearly a user interface decision. I don't want my presenter to have to know about any kind of user interaction. Also, the first solution allows the display some flexibility for the case that the user cancels a request, something else comes up, etc. On the other hand, the first solution is simpler to implement, and doesn't require the display to know about the presenter.
What do you do?
I think it belongs in the view because:
1: The reason you'd take things out of the view is so you can more easily test it. A simple start/ stop showing loading doesn't seem like a lot of logic worth writing tests for.
2: This feature is so specific to the view, that it feels the presenter shouldn't even have to know about it.
3: Since the view is responsible for knowing how to render itself, it makes sense that it should know how to display a loading icon when needed.
My question was little diff.
From MainPage.xaml, I am using 'NavigationService.Navigate(new Uri("/Page1.xaml", UriKind.Relative));'. It does not goes to Page1.xaml immediately. It just creates an Now the control does not completely goes to Page1.xaml. It again starts execution what is written on the next line to NavigationService.Navigate(new Uri("/Page1.xaml", UriKind.Relative)).
I have to transfer full control towards Page1.xaml, when I return from Page1 then it must resume the remaining execution of MainPage.xaml.
Plz Help.
Navigating to another page is not a synchronous process where you call the page and wait for a return result.
When you pass control to another page, it is effectively something that you fire off and forget.
Any subsequent processing you want to do when you get control back in the original page should be handled in one of the corresponding events/overrides for that page - Loaded, OnNavigatedTo for example.
So when the user navigates back from Page1, you want to do something on MainPage? Override OnNavigatedTo in MainPage and handle the navigation that way. I don't think there's a really elegant way to determining that the navigation was due to a "backward" navigation - you may need to use PhoneApplicationService.Current.State to work that out.
Note that this due to tombstoning etc, this could be a different instance of MainPage from the original one.
Either way, you won't be able to just continue from where you left off within a method. You need to think in a more event-based way.
I've been working on Chrome Extension for a website for the past couple of days. It's coming along really nicely but I've encountered a problem that you might be able to help with.
Here's an outline of what the extension does (this functionality is complete):
A user can enter their username and password into the extensions popup - and verify their user account for the particular website
When a user browses http://twitter.com a content script is dynamically included that manipulates the DOM to include an extra button next to each tweet displayed.
When a user clicks this button they are presented with a dialog box
I've made a lot of progress but here is my problem:
When a user visits Twitter the content script is activated and all tweets on the page get my new button - but if the user then clicks 'More...' and dynamically loads the next 20 tweets... these new additions to the page DOM do not get affected by the content script (because it is already loaded).
I could add an event listener to the 'More...' button so it then triggers the original content script again (and adds the new button) but i would have to predict the length of twitter's ajax request response.
I can't tap into their Ajax request that pulls in more tweets and call my addCurateButton() function once the request is complete.
What do you think is the best solution? (if there is one)
What you want to do is to re-execute your content-script every time the DOM is changed. Luckily there is an event for that. Have a look at the mutation event called DOMNodeInserted.
Rewrite your content script so that it attaches an event listener to the body of the DOM for the DOMNodeInserted event. See the example below:
var isActive = false;
/* Your function that injects your buttons */
var inject = function() {
if (isActive) {
console.log('INFO: Injection already active');
return;
}
try {
isActive = true;
//inject your buttons here
//for the sake of the example I just put an alert here.
alert("Hello. The DOM just changed.");
} catch(e) {
console.error("ERROR: " + e.toString());
} finally {
isActive = false;
}
};
document.body.addEventListener("DOMNodeInserted", inject, false);
The last line will add the event listener. When a page loads the event is triggered quite often so you should define a boolean (e.g. var isActive), that you initialize to false. Whenever the inject function is run check whether isActive == true and then abort the injection to not execute it too often at the same time.
Interacting with Ajax is probably the hardest thing to coax a content script to do, but I think you’re on the right track. There are a couple different approaches I’ve taken to solving this problem. In your case, though, I think a combination of the two approaches (which I’ll explain last) would be best.
Attach event listeners to the DOM to detect relevant changes. This solution is what you’ve suggested and introduces the race condition.
Continuously inspect the DOM for changes from inside a loop (preferably one executed with setInterval). This solution would be effective, but relatively inefficient.
The best-of-both-worlds approach would be to initiate the inspection loop only after the more button is pressed. This solution would both avoid the timing issue and be efficient.
You can attach an event-handler on the button, or link that is used for fetching more results. Then attach a function to it such that whenever the button is clicked, your extension removes all the buttons from DOM and starts over inserting them, or check weather your button exists in that particular class of DOM element or not and attach a button if it doesn't.