I have an app where you could go through in views like;
play -> normal or custom -> select map -> summary -> start
I would like to make a shortcut option from play to summary, but I also want navigation back to select map page with the back button functionality.
So the normal workflow p->noc->sm->summary but I want to implement p->sm with the noc<-sm<-summary back functionality too (with the windows phone back button).
I saw how can I delete items from the backstack, but google not helped me how can I navigate through a couple of windows without showing that to the user.
Am I need to override the back button or there is a "better" way to do that?
It's a WP8 project.
Edit:
I didnt need the exact codesnippet for this just a design concept in this patform. (just for the is it duplicated guy)
My normal or custom and select map page should be randomized when I do the shortcut, both of these pages has a "button" which can randomize those settings, I just want a swipe->press->swipe->press->swipe actions shortened to a button press without loosing the 'post modification after randomized' feature.
After I read your comments I think I will handle the back button all of the mentioned views so the backstack will not be getting inconsistent at any state. If I understand well I can tell it in every page what is the "backed" page.
You can't inject pages into the backstack. You can override the back button and do a forward navigation with the animations you would normally do when going backward (and then remove the page you just came from off the stack), but honestly, this all gets complicated and for good reason. One of the few hard truths of Windows Phone design is that you shouldn't mess with the backstack.
Instead, I would rethink your flow. It seems like your second page is a setting of some sort (Normal or Custom). If that is changeable, maybe make a button that can float a modal popup on top of the page and move things around according to the new decision.
Looking again at your flow, it seems like several of the pages may be settings. Can you combine those into one page, maybe on a pivot or panorama? That way making changes is just a swipe away.
Regardless, while it is possible to do what you are looking to achieve, I would look long and hard at whether it is actually the best experience for your users.
Related
How would one go about to have a page / layout designer on run time, and save the layout(that then later on would be rendered with retrieved data).
The scenario :
I have a host application/website, where a user can upload his dll and view as a plugin/widget.
now i want the user to have a graphical designer where he can see all existing plugins or widgets. This is where he can drag and drop the plugins on the page where he would like them, allowing him to also re-size the plugin as he requires it as well.
one of the closest I could find to the type of behavior that i find closest would be. Dock Spawn (Mabey this would still work ?)
what would the best way be to implement such a solution, allowing an admin portal where the user can edit his page. as well as saving this page and allow it to load on another portal.
using existing CMS would not be an option, and any third party tools would be considered
Thank you!
EDIT
I have decided to go with Jason's answer. Implementing JQueryUI's Drag-able, re-sizing. then saving the X and Y co-ordinates for reloading at the same position.
Will still find a solution for the re-sizing(maybe some math...)
Ultimately what you need to do is wrapper the widgets in <div> elements and save the position e.g. left, top, width, height. That way, you can move the position of the <div> containing a widget to the specific left, top based on what is stored in any config for that widget.
I don't believeyou need a thrid party library for this, as long as you're happy understanding about positioning in CSS, you should be able to do this yourself.
EDIT:
In resposne to your comments:
You can save the data however you like - serialize it to a file, store in the cloud, save to a local database. It's totally up to you based on your needs.
Regards how the widgets will be positioned based on the device you are looking at, that's where things get tricky. ou will simply have to test that yourself, by trying out a simple widget, positioning it using top, left, etc and see what it looks like on, say, desktop mobile and tablet.
You will likely have to change the position CSS style in order to correctly position the <div>. My CSS is a bit hazy to be honest, so I can't say with authority which position value you will need. Hopefully this will be enough to get you up and running though.
I want to create a kiosk mode application using WPF. I want to use a single window because the user should not be able to exit this fullscreen application.
The application should guide the user trough a process. When the user proceeds trough the process, the screen should constantly change and show him the next step.
Usually I just create a single window and use a "state machine" to switch UserControls containing the information for the current step. Is there a better way to achieve this functionality? Maybe I would get a better result using multiple windows or Pages (never used them).
The reason why I am asking is that in future I want to have a simple, clean way of switching the content inside a single window. i.e. I am planning to implement some sort of animation when switching content (like sliding to the next / previous step). I don't want to put more effort into my current approach if it isn't the most flexible and clean one.
Any ideas?
PS: This is about desktop applications. Today I come from the Winforms environment and am experimenting with WPF.
There's a few ways you can achieve this.
First would be to use a Page based application, this will allow you to use a single window. Here is a pretty interesting tutorial
A bonus of using this approach is that navigation between pages is built in.
Your requirements are that you need to use animation for transitioning between pages, as far as I'm aware, using a Page based application cannot achieve this (I may be wrong). So your other option would be to use a UserControl MVVM approach.
This probably won't make a lot of sense now, but here goes:
You can use a single master view model which will hold multiple child view models, each of these could have a visibility property which dictates the visibility of the associated view. The master view model would simply be responsible for displaying the appropriate view model depending on where the user currently is in the application.
Using some clever XAML, you can create storyboards (animations) when the view becomes visible, which will allow you to achieve the crazy awesome animations that you require.
Anyway, that probably didn't make any sense, so here's a tutorial to get you started with MVVM.
Hi StackOverflow Community,
I am working on a universal app for Windows in C# and XAML. So far, progress has been smooth (the whole framework is very easy to use) however I have run into an issue related to page navigation and state caching that I was hoping to get some help with.
In a standard template, navigation through an app would look like this:
Home -> Profile (ID 1) -> Game (ID 120) -> (Back) Profile (ID 1) -> (Back) Home -> Profile (ID 2) -> Game (ID 210)
However, I'd like to do something like this:
Home -> Profile (ID 1) -> Profile (ID 2) -> Profile (ID 3) -> Game (ID 120)
The reasoning behind this requirement is simple: the profile page contains a list of friends, groups, games, etc for that profile. Clicking on a friend should bring you to their profile page and from there you should be able to view their details, their friends, etc and continue to drill down friends lists or groups (which can link back to profiles).
This is important, since most of the questions I've come across on SO have been related to this... but I am already able to navigate back and forth through the list properly like I listed in the second example. The issue that I'm having comes from some funny caching and state issues during navigation.
For simplicity sake, lets just talk about the Windows Phone view; the Profile Page contains a Pivot Table with four sections (Details, Games, Friends, Groups). If I'm on the profile for user 1, swipe over to the friends section, and tap on the profile for user 2 then the navigation occurs and I have 3 pages in my back stack (home, profile for user 1, profile for user 2). This is not the part I'm having trouble with; the issue I'm having is related to navigating backwards - when I hit the back button and navigate backwards on the frame I am returned to the profile for user 1 (which is good), however the state of the view is reset and instead of being on the 'Friends' section I am returned to the first section (in this case the 'Details' section - which is annoying from a UX perspective).
I have played around with the NavigationHelper and the SuspensionManager as well as experimented with setting the page caching to enabled, however I got some unexpected results. As explained above if I don't set the NavigationCacheMode to Enabled then I am always returned to the first pivot section when I navigate backwards, however if I DO set the cache mode to Enabled then when I navigate to new instances of the profile page then the state seems to be recycled and instead of appearing on the 'Details' section for the NEW profile, I am loaded into the same section I was in when the navigation occured (i.e. if I was on the 'Friends' section for User 1, then when I tap User 2 I will be on the 'Friends' section for User 2. Also annoying from a UX Standpoint). The same will occur when I'm navigating backwards as well, if I'm 4 profile deep and looking at the 'Groups' section for profile 4, when I hit back then I will be looking at the Groups' section for profile 3 (even if I navigated from profile 3 -> profile 4 from the 'Friends' section)
Is this something that any of you have experienced? I'm not looking for code snippets specifically (though I definitely am not in the habit of turning them down!), but more just the thought process on how I should handle this. I know that some apps do something similar to this, and I'm sure I'm missing something small but any advice would be greatly appreciated.
An example of this same type of navigation I'm trying to achieve would be on the Hulu App. If you select a series and swipe over to the 'Recommended' Section you will see other shows. Tapping on one of these shows will open up the details for that show (and you can go multiple layers deep), however tapping the back button will bring you back to the last series you viewed (and most importantly, will also put you back on the 'Recommended' Section)
Normally I would absolutely provide code-snippets, but since this is more of a broad question rather than a "Why doesn't my code work?" question I decided hold off and will wait to provide snippets only if they are requested.
Thanks in advance!
Page Caching has gotten a lot more flexible but also a lot more complex in Windows Store Apps. You now have the flexibility to implement navigation patterns like yours, but you also have to do a lot of stuff by hand.
First there is NavigationCache: You can enable it on pages (but ONLY in the constructor).
For the Cache to work correctly you also have to set the CacheSize (it is in the default App.xaml.cs and set to 1. You will have to increase it to work properly.
Still, it only keeps one instance of the page in the cache. In your case, you navigate to that page multiple times with different IDs. With navigation cache enabled, it will just make sure the all land on the same instance of the page.
I usually only cache the root page of my app and only if it contains a lot of data (like your hub).
NavigationCache if used to often fills up a lot of memory and therefore your app gets shut down earlier when put in background. Use it with care.
Usually it is best to just reconstruct pages every time you navigate to them and just cache the data (if obtained over the wire).
The NavigationHelper offers a simple standard implementation for saving a state dictionary for a page. When your page gets recreated on a back navigation, you still have to handle it your state by hand.
It just provides you with a dictionary where you can save values in: What HubSection you are in, how far you scrolled, etc.
It utilizes the BackStackDepth to get you the right dictionary for the page you are on.
Once you get your dictionary back, you have to set the HubSection, scroll down, etc.
So in the end: Yes, you have to do all that by hand...
Im currently trying to create an application that will require 10+ different "pages" with different content and controls, and i need to switch back and forth between them on particular events.
What ive been doing, is just creating all the different sections in grids, and setting their visibility to collapsed, and then when i need to show them, just switch out the visible grid to the new one.
This has several drawbacks, im assuming its very poor from a coding standpoint, and this pretty much dis-allows me from using the designer at all. (i have no idea what performance implications it has, either)
on top of that, every time i switch to the new page, i need to reset all the components (textbox's etc) to their default states, as they dont get reset by becoming invisible :P
on to my question: i need a way to map out all the different pages, provide visually attractive transitions between them, and be able to use a designer to create them (and i dont mean designing it somewhere and then just copying the xaml)
I had looked around, and ran into SketchFlow and it seemed like the perfect solution, i could fade between pages and map everything on a flow chart easily, and then i realized it was only for app prototypes and i couldnt actually compile it as a normal application... and i needed to inherit from a custom Window class aswell.
is there something out there that allows me to do this? or how can i code this to work properly?
note: this ABSOLUTELY needs to stay within one window. i cant venture out into having 10+ different windows that pop up every time i need to change to something. as this happens very frequently
Split the separate sections in individual user controls. This would allow you to design each of them easily. Then on your form use code to create and load a new instance of particular user control that represents the section you need to show, and when transitioning, load the new section and unload the current. this would allow your form to stay relatively lightweight.
An alternative is to create a navigation application and split your sections into separate XAML view and use the standard navigation service to switch between them.
WPF Navigation Overview
Creating Navigation Applications video tutorial
You might wanna convert your "Pages" to usercontrols and use some transitions like mentioned in the below link to switch between controls
http://www.tanguay.info/web/index.php?pg=codeExamples&id=280
for more on using transitions look here
http://www.japf.fr/2009/04/adding-transitions-to-a-mvvm-based-dialog/
or
http://www.japf.fr/2008/07/8/comment-page-1/
Is there any pattern or kind of "least requirements list" to follow for ensuring an asp.NET application to support BACK button of the browser for each aspx page?
thanks
In general, the back button on the browser will take you to the previous HTML GET or POST that occurred. It navigates by page-wide transactions, so anything done dynamically cannot be navigated that way. Also, the back button doesn't rewind code execution, so if you are determining something based off of a Session variable or something similar, that won't be rewound either. Obviously, it won't rewind database transactions either.
In general, if you want to support the back button, you'll need to make sure to divide everything you need to navigate between with said button is divided by an HTML transaction of some sort.
Again, you're going to run into issues if your page display is dependent on server-side control that changes from one post to the next. This is one reason you see some forms feed a 'Page has expired' error when you try to navigate back to them.
Not really... It depends on your application flow.
There are things that make supporting the back button more awkward.
for example using pure ajax to change the majority of the content on the page,
will look like a 'new' page but wont be compatible with the back button (though you can fudge it)
another example is posting back to the same page more than once, as this can make it appear like the back button is not working, and at the same time re-doing your request (and therefore database transactions)
Fundamentally it depends on your application requirements.