I have a really strange issue relating to how I handle navigation in an application, and that application now being rejected from AppHub (after being successfully approved a number of times on the same code base... grr)
currently I am capturing the first navigation of the application and routing it an "add item" page in the App.cs using the example found here
the user then adds an "item"
the user is taken to the "main" page again, but stay there are there is now 1 "item" to show in a list
the user then can view a "detail" page of this item where they can select to delete the current item. when they do that I redirect them to the "main" page again.
this navigation then fires the same thing that happened in step 1
and they are routed to an "add" page
the problem with the above process, is that if the user hits "back" on the routed page in step 5 they don't go anywhere as they are routed back to the current page (because there are no items on the page previous and this fires the app.cs routing event to take them to the add page). if I did allow for them to go back, the actual first page they would be able to go back to is 3 nav steps back, when they first added the item - as they are on the "add item" page already, this would be pointless.
The apphub store testers say that in this instance, the application should close. I really don't know how the f&*k I am meant to make this happen, as there is no "go back until close" action I can call...
thoughts?
When the user decides to "delete" the current item, you shouldn't navigate forward to the main page, leaving the deleted item in the navigation stack. You should navigate back to the main page. That way the navigation stack will be empty, and if they navigate back again, the app will close.
(The same is true at step 3, of course - when the item is added, navigate back to the main page. You don't want the "add" page as part of the navigation stack; that action has been completed.)
The single best advice I read on WP7 navigation was "if you don't have to, don't use it." I've almost stopped using it all together and just use "MainPage.xaml" for loading/unloading user controls that do this kind of stuff. I completely control the Back button as needed. It has saved me so much headache. The important thing to realize is that the Navigation pages are really just mimicking a website and it's pages - many apps do not fit that paradigm (as they are apps, not websites). So, if you don't have to use Navigation, don't use it.
So in your case, if you just managed everything on MainPage.xaml, you would use a number of If/Then statements in OnBackKeyPress and if one meets your criteria, do an e.Cancel = true; and show/load/etc. your thing. If not, let the app navigate out of itself - i.e. exit.
For tombstoning, just let the OnNavigatedTo in MainPage.xaml handle loading the right user control received from tombstoned information retrieved from Application_Activated.
Related
I'm using ui-router.
A similar question has been asked on this a Number of times... But the solutions seem to be all over the place and either the question doesn't address a simple idea or the answer doesn't, either.
Here's my simple ui-view setup:
A master view has the navbar and footer
Children of the master view/route that can be activated include the Homepage, About Us page and Learn More page
Pretty simple...
By default, if the homepage is activated, and scrolled down 500px, and I click on a route to the "About Us" page, that page will be scrolled down 500px. Obviously this is not desired.
So... Everyone's solution is some variation of setting document.scrollTop(0) on every state change success. This is atrocious.
While it fixes the issue at hand, it clobbers the browser back button behavior. Here are some problems:
When a refresh is called, the standard browser behavior of refreshing to the current location is ruined
When the back button is clicked, the homepage would then scroll all the way to the top
If the back and forward button were clicked, I wouldn't retain the correct spot on the next page, either
This whole document.scrollTop(0) or any variation of it, really doesn't seem to be viable and I've yet to see a clear solution to this.
I'm developing a windows phone app, one of my pages use a panorama that loads a bunch of UIElements, taking a good share of memory.
Since every time I navigate to that view the page is created all over again, is there any way to reuse the page instance? Or there is any other way to ensure that the UIElements aren't created more than once?
EDIT:
The navigation process is the follows:
HomePage -> Secundary Page
Back
HomePage -> Secundary Page
Back
HomePage -> Secundary Page
etc.
What I want is that the secundary page instance to be reused after the first navigation.
Thanks
PhoneApplicationPage's lifecycle is completely managed by the runtime, you cannot influence it in any way. If user goes back from the page, it will be re-created next time. See this document, "The OnNavigatedFrom Method" section.
In fact, if you absolutely want to keep secondary page in memory, you could override normal back button behavior on the secondary page, and instead of going back to main page, you'd go forward to the main page. Of course, you'll have to keep the backstack in order, to avoid side-effects mentioned in KooKiz's answer.
Note that it's still not guaranteed that secondary page will stay in memory, since it's up to garbage collector to decide. The more memory page consumes, the better candidate it is for GC.
The problem is how you get page to the main page after navigating to a secondary page.
My guess is that, from the secondary page, you're calling:
NavigationService.Navigate(new Uri("/MainPage.xaml", UriKind.Absolute));
This is wrong, for two reasons:
As you noticed, you'll create a new instance of the page each time, and therefore use large amounts of memory
To exit the application, the user will have to press back as many times as they navigated to the main page
Instead, since the main page is still is the navigation stack, just call GoBack from the secondary page to re-use the previous instance of the main page:
NavigationService.GoBack();
I am trying to build an app using Extjs 4.1. In general: it is a viewport with a tree panel on the west and a center panel that it is actually a tab-holder panel. When a user clicks on a tree node a tab is populating the center view. I had set an attribute in the tree panel that after selecting a node it gets deselected (deselectAll). The reason for this is that the user can open many tabs from different places (e.g. within each tab). But, when I set the above attribute it is producing an error (the “data” is undefined). The data that is undefined is the data related to the tree node. So, the question concerning selection model:
How can I address this problem (a solution may be to select the fist node, but I don’t want it)?
As for the history utility, I need to implement browser back button. Especially I want to disable browser’s refresh button. If user opens let’s say 15 tabs and accidentally click on browser refresh or “F5” he/she will lose everything. I had tried many things but with no luck. I am unable to understand “Ext history util”. So,
Is there any good example out there?
Could anybody guide me on how to do it?
Notice that the application is built respecting the new “MVC” architecture.
Stopping the refresh event is pretty easy - providing that your page has the focus. E.g.:
Ext.getDoc().on('keypress', function(event) {
if (event.getCharCode() == event.F5) {
event.stopEvent();
console.log('you stopped the refresh event');
}
});
If your page doesn't have the focus then there is nothing that can be done -- but most of the time your page loses the focus when a different browser tab is opened so F5 would be refreshing that one instead anyway.
I'm still trying to wrap my wits around the first part of your question, but I thought I would share that.
EDIT
Instead of trying to stop the default browser behavior (something which you can only do on a very limited basis), you should look into state management. ExtJS supports it on many components. Here is the ExtJS example.
Also here is the example of controlling browser history.
I should create ExtJs4 app, which should have main menu, and each menu item should open a new page with different url, so if the user copies the url and pastes on other browser tab, the app should open that menu item.
I want to use ExtJs's recommended MVC architecture, but I don't know how I can use it with multiple pages/urls. All their examples are using single page.
One option is to reload the page each time when the user clicks on particular menu Item, so every url/menu item/page will be separate ExtJS app with it's MVC. But I think this approach has drawbacks, since the page will be reloaded every time and it's not good for performance. Also it's causes difficulties in reusing of components (common models, stores and views for different pages ).
So I would like to have one single app for all pages, but I don't know is there any solution to have different urls for different views (in my case: for different menu items).
Or is there another approach for such applications?
You would probably want to use a Viewport, and make the Center Region a Container.
The Center Region Container would usually have a Card or Tab layout.
When the user navigates to a new view (Component), you add that view to the Container, and make it active.
The big mistake is to change the URL first. You don't want to do that.
You want to navigate, and then set the URL if the navigation was successful. You should probably not use ExtJS's History component, as it is incorrectly implemented. I would recommend using HTML5 pushState.
You should make sure your navigation system works without changing the URL bar too.
I would recommend reading up on Navigation in Microsoft Prism, WPF, and Silverlight, as there is more documentation there, and then apply that to ExtJS.
http://msdn.microsoft.com/en-us/library/gg430881(v=pandp.40).aspx
Here is an example Navigation process:
call app.requestNavigate('contacts/5'); you would add this yourself.
you parse this fragment to:
navigationContext = {
fragment: 'contacts/5',
xtype: 'contacts-form',
parameters:{
id: 5
}
}
OPTIONAL: If using forms:
get active item from the navigation region (your center region). if exists, call confirmNavigationRequest(callback) . you will need to add this method or event.
if callback(true), proceed with the navigation. this allows the user to cancel a navigation, if say the form is "dirty"
END OPTIONAL
the easy way is to then create a new widget of navigationContext.xtype, add it to the navigation region, then call setActiveItem(widget). destroy the previous active item if it existed.
then call history.pushState(null, null, navigationContext.fragment)
then raise a 'navigatedto' event on the view, passing the context, and you can load the data from there.
More advanced scenarios include:
keep the previous component alive if you expect to return to it. add a keepAlive property and if true, don't destroy when add new components to container.
search the container and ask each component if it wants to handle the current navigation request (for example if a form loaded with contact-5 was already hidden in your navigation region, or if you want to re-use a form)
I'm working on a WP7 appliation with Silverlight. When a user clicks the back button, I want to determine where they will go to. Is there a way to determine where a user will go without managing my own nav stack?
thanks!
To respond to the question that has actually been asked "Is there a way to determine where a user will go without managing my own nav stack?"
You could use the OnNavigatingFrom override the eventargs of which carries the Uri of the page being navigated to. I suspect this is only useful when the navigation is back to page within your app.
You cannot override what the back button does - the rule Derek mentioned is enforced by the system and the previous page/app will always be called.
You can, however, add an action to be executed on back key press:
this.BackKeyPress += new EventHandler<System.ComponentModel.CancelEventArgs>(MainPage_BackKeyPress);
Then just use the handler:
void MainPage_BackKeyPress(object sender, System.ComponentModel.CancelEventArgs e)
{
// Your activity goes here
}
The application will go back to the previous page when the user presses the Back button. If the user is at the last page in the application, then the application will exit and the user will be navigated to the previous application. To perform anything else would be inconsistent, confusing to the user, and almost certainly would fail certification.
In general you'll want to build your app composed of pages (similar to a website). For example a HyperlinkButton might be used like this:
<HyperlinkButton NavigateUri="/Page2.xaml" Content="Click here to enter page 2"/>
After clicking that then pressing the back button will automatically return to the previous page. There's no extra programming involved to make this happen... it just works.
But there are some circumstances where you'll want to override the back button. The one I ran into was the dialog box. If your app creates a dialog box, then the back button should close it instead of returning to the previous page. I wrote a brief article about how to accomplish this.
And here's a complete list of rules from Microsoft's certification requirements concerning the back button:
To maintain a consistent user
experience, the Back button must only
be used for backwards navigation in
the application.
a. Pressing the Back button from the
first screen of an application must
exit the application.
b. Pressing the Back button must
return the application to the previous
page.
c. If the current page displays a
context menu or a dialog, the pressing
of the Back button must close the menu
or dialog and cancel the backward
navigation to the previous page.
d. For games, when the Back button is
pressed during gameplay, the game can
choose to present a pause context menu
or dialog or navigate the user to the
prior menu screen. Pressing the Back
button again while in a paused context
menu or dialog closes the menu or
dialog.
As I found out, if you don't follow those rules they won't approve your app.