In the following blog post the author describes the need to store page state, e.g. the text within a TextBox control, in the Page State dictionary so that it is restored when navigating between pages:
http://www.wintellect.com/CS/blogs/jgarland/archive/2011/01/26/a-matter-of-state-part-1.aspx
However, I have created a very simple application that has one page with a Button and a TextBlock and a ListBox of items. The button navigates to a dummy page, via NavigationService.Navigate. Now, if I scroll the list and input some text into my TextBox, navigate to the dummy page, then hit the back-button, I can see that my text is still present in the TextBox and the scroll position was preserved.
My question is, (tombstoning aside) do I ever need to persist the state of UI controls when simply navigating between them? It would appear that the frameowkr does this for me (despite the blog post above!).
You should persist state if it makes sense in the context of your application and will be helpful to the user.
This almost certainly means when tombstoning but probably not when the application is closed via the back button and then restarted.
In your scenario, the scroll position and text will be lost on tombstoning so you probably want to save these details.
Saving state is only relevant in the context of tombstoning and launching new instances of an application so (a tiny number of exceptional cases aside—and it doesn't sound like you are one of them) it doesn't make sense to talk about saving state outside of this.
Related
I have a Cocoa app that presents a folder structure to the user and allows basic file system operations such as move/copy/rename.
I perform all file system access on a background queue and use file coordination via NSFileCoordinator.
Let's imagine the user drags the file "Notes.txt" into the folder "Project B". Here is what I do:
I schedule the file operation of moving the file on the background queue.
Once that's done, it calls a block on the main queue where I update the outline view
Let's assume the background operation moving the file takes some time. I need to prevent that the user continues to move files around or performs other actions until the first operation completes.
Hence I would like to:
Disable all user interaction with the window
Disable most menu items and keyboard shortcuts
Keep certain menus such as [Quit Cmd-Q] working
Don't block the main thread
One solution that comes to mind: use a modal sheet?.
I don't want to do this, because most of the time, the operation will finish quickly and the sheet would only be shown for a fraction of a second, which is distracting.
I keep track of how long the operation takes would switch from "interaction blocked mode" to "modal sheet" if it takes more than 500 ms.
The question is: how can I implement such a "user interaction blocked mode" without actually presenting a modal sheet?
Alternative idea: disabling all controls
I considered setting isEnabled = false for all controls, but that's not an option, because the UI can be arbitrarily complex and it won't prevent actions via the menu or keyboard shortcuts.
You may find helpful The Responder Chain article in Apple's Documentation. Proper solution depends on what you exactly need. Overriding NSMenu's - (BOOL)validateMenuItem:(NSMenuItem *)menuItem; let you control over enable menu items and its shortcuts. You may also put transparent NSView over the area you want to prevent from user's interactions.
I have an outline which contains some outline entries.
Every entry contains a view and in the outline entry properties at Content there is the name of the frame. Also, every view in its properties at Auto Frame (web only), there is the name of the frame.
Even so, when I click another view to open it, it will b open in a new tab of the browser.
I appreciate your time and help!
PS: I observed this problem after I put the suggestion code ( which it works ): Lotus Domino: View pagination on web .
If I remove the code from OnLoad it works quite well, with no openings in new tab. Is there any chance to have the code on OnLoad event and the views to be open in same frame?
By changing the value of window.name, the pagination code is affecting the name of the frame in which the content appears. So when you click a link in the outline, the browser goes to look for the window/frame with the name specified by the outline, and it can't find such a one -- so it opens a new window with the specified name.
For the pagination code to not interfere with your navigation, you would have to change it to not rename the window -- it would have to store its window-identifier elsewhere. For instance, if you know the view will appear in a frameset, you could set a property of top instead of window. Since the top window of the frameset doesn't change when you load new pages within a frame, you can even just keep track of the last Start= parameter there, and not bother with cookies.
I encourage you to look into using XPages for your web design -- this is usually simpler.
I need to change the Background Image of my Application if user changes theme from "Light" to "Dark" or vice-vesa in code behind. I hope these should be done in Page Loded event
#TimDams pointed you to one of the nice ways to detect what-theme-is-now-set, but I didn't notice there any information how to detect a change to the theme during the application runtime. The user could start your app, then bump forward to the menu, change the theme, and get back to your app. While you may think that your app will be tombstoned and then restarted and renavigated to your page with full cycle with all pageloads -- it is not 100% true.
Firstly, the PageLoaded is NOT a good place to do the initial check-and-set-styles, because, if you get that event called, then the page, probably, has already rendered once. If I remember well, the PageLoaded is invoked just after the first render. If this is true, then you will have to detect the colors earlier, for example in the LayoutUpdated (warning: this event is a great spammer. I mean, it gets called gazillions times. Attach a single-shot handler, you know, such that will instantly unattach-self on first invocation). Maybe you will be able to do it in the Page's .ctor, just after InitializeComponent. Or in the OnApplyTemplate or MeasureOverride, or at least ArrangeOverride -- the visuals should be mostly/fully available there.
Buuuut. I've intentionally 'bolded-out' the word "initial". With Mango, there's some multitasking getting more and more common, but even the pre-Mango 7.0 version does not guarantee that your app will be tombstoned. From my observations in early 7.0, for example, starting the MediaPlayer from WebBrowser component does not tombstone your app:) If you have some time to read, check WP7 recover from Tombstone and return to page for details on the "pause" vs "tombstone".
Anyways, if your app gets "paused" and the user switches themes in the meantime, I think (I've NOT checked) that your page will (in most of the cases) be just temporarily hidden and upon returning to the screen, it will probably not be re-created and will not be re-(Page)Loaded. If it is true, then you will have not so easy problem to solve, because your app may be paused, the OS rethemed, and your app unpased virtually in any moment of time and the only events you will get in the mean time are .... global events of App.Deactivated and App.Activated. It is possible that completely none of per-page events will fire [but I've not checked - before you do anything I suggest below, CHECK IT].
If this pessimistic view is really true, than in those events, you will have to detect the current theme (->Tim's post), then somehow inform your current Page that themes changed - or not. If you have your ViewModel at least a bit separated from the rest of the app (as it should be:) ) you have an easy option to do it: create in that ViewModel a set of properties (dp or inotif) like Brush Background, Brush Foreground, Brush Hightlight, and other that you need, and instead of harcoding colours in your XAML - bind to those properties. You may event want to create a separate class for all those many Brushes and other Styles, let's say "pub class MyCurrentAppTheme" and keep that props there, and expose such object from ViewModel - whatever. Just Bind your colors to whatever -- but whatever that will be "logically global" and that will be easily accessible from the App.Acticated event handler. Having that done, in the App.Activated, detect the current theme and if changed, so through all the colors kept in VM and set them appropriatelly. Voil'a, whole your App gets recoloured properly.
But mind that still - there might be some transient blinks and flashes between the rendering of cached old theme, refreshing databound objects, and redrawing fresh theme. I hope not, but I sense it may occur, especially when returning from fast-switch tool (long back press): I think that the device captures the 'last screenshot' of your app in the backbuffer and uses that throughout all the time the app is 'minimalized' to do transitions animations, to show the fast-app-switch overview and so on.. again, I've not checked, but I doubt that during such animations the pagecontents are 'live', it could be very demaning on CPU/GPU resources. Any one knows anything on that? It could be a nice test to have some looping animation on the page and then to switch out and check in the fast-switch overview, whether the animation moves or is halted!:)
If your application is tombstoned, all your controls will be recreated and the new theme will be applied. If you'd like to manage your light/dark specific styles in a similar vein to normal themes, you might want to take a look at a custom ResourceDictionary I blogged about a while back.
Unfortunately, as of Mango there, is a bug (?) related to fast application switching that causes the theme to remain unchanged in your application. The bug is outlined in this question and its linked posts:
Is there a bug when changing themes when app is deactivated and reactivated in Windows Phone Mango
My ResourceDictionary is still useful for the initial startup but it appears, unfortunately, that nothing can be done to workaround the Mango bug.
For this no event exists. You need to figure this out manually by comparing the PhoneBackgroundBrush color to see if the user has the dark or light theme and compare it with your last stored value.
Were you able to do some test on the App.Activate - Deactivate?
I decided to use a different path to solve the issue of dynamic theme change.
I've assigned to all text and buttons only system resource colors.
For the icons inside the buttons in the window instead of using PNG images-icons I used the in XAML and assing it a Foreground color from system resource.
For the buttons in the SystemMenuBar there is no issue as they are always on a dark gray background so the black PNG images work just fine.
Hoping this helps.
You can check if the dark theme is in use with this simple check:
public static bool CurrentThemeIsDark
{
get
{
return (Visibility)Application.Current.Resources["PhoneDarkThemeVisibility"] == Visibility.Visible;
}
}
What is UI state? Can you give me an example of something like that might be? Does it refer to things like keeping track of what tab is open for example?
I think the idea is that the application has state, and the UI reflects that state.
So when you app starts it goes like the following
1) Initial state (app is started up)
2) Loads initial data ("loading state")
3) Is ready for interaction ("ready state")
Now lets say the user starts an interaction by opening a form.
4) User opens form and goes to ('editing form state')
The user can cancel or save so now the states diverge. If cancel
5) The 'editing form state' receives the cancel event, discards the changes, and goes back to "Ready"
If save
5) The app goes to "Saving" state, then when done goes back to "Ready" or "Error"
The great thing about this conceptualization is that it allows your 'state chart' to update the application elements depending on the state. For example, in 'loading' or 'saving' states you can mask the UI or disable the buttons. The key point is that the views don't need to know about the state, all it does is sit around and be manipulated. Its the state code that manages what views are doing what at any given time.
Note that is also correct for views in your UI to have state. For example, a button can have states like, 'mouseenter', 'mouseexit', 'clickdown', 'clickup', 'inactive', etc. A custom view in your UI can be considered to have states when it renders itself differently depending on the data it represents.
You might want to take a look at
http://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.pdf
UI state simply means the state of the UI. Keeping track of what is in the controls, and which are visible is indeed a part of the UI state.
When using icon images without text captions, should the icon represent the current state or the next state? For example I have a block of text that I want to minimize / maximize or I want to toggle showing All User Records or just My Records. I'm sure there are compelling arguments for either side and know that consistency is key, but what are the arguments related to good intuitive user design?
There is neither standardization nor general human tendency on this. For example, MS Windows UX Interaction Guidelines specifies four basic kinds of toggling progressive disclosure control. Three out of four show the state-when-activated, while one shows the current state.
I believe if you test a particular approach on your users, you'll get different results depending on what you ask. If you show them a control and ask them what state the app is in, they'll tend to read the icon as if it were indicating the state. If you show them a control and ask them to change the state (where in some cases the state is already changed), they'll read the icon as if it were the state to achieve. It's precisely because of this they invented toggling buttons.
If you're lucky, users use the icon primarily for either reading the state or setting the state, and not both. Then let the icon indicate whatever the users use it for.
If they indeed use it for both reading the state and setting the state, you're basically hosed, but there are a few things you can try to minimize hosehood:
Use text in addition to or instead of an icon. When labeled with a verb (e.g., "Connect"), the control indicates the state the user gets. When labeled with an adjective or noun (e.g., "On Line"), it implies the current state.
If your lib doesn't support toggling icons, then consider using a checkbox control, if that's allowed.
If your lib doesn't support checkboxes, then consider two controls, one to set each state, where the current state is disabled. Not too good for reading the current state, but there's some precedence for this in pulldown menus.
Fiddle with graphic design or placement to make it consistent with the meaning you've chosen. For example:
Command buttons are always labeled with the action they commit, so if your icon indicates the state the user gets, then give the icon a raised appearance like a command button. If the icon indicates the current state, then give it a flat appearance.
Toolbar controls usually show the state they bring about, so put the icon at the top of the window if indicates the state the user gets. In contrast, icons in the "work area" of the window indicate objects or attributes, so icons there should show the current state. Icons at the bottom of the window (in the status bar) should also show the current state.
This has not been truly standardized. Folder icons, for example, show open folders when they are open and closed folders when they are closed. Same for disclosure triangles, etc.
However, in other contexts, this is not always true. In a movie player, the "Play" arrow shows when the movie is not playing, and it shows the pause icon when it is playing. Probably the thing to do is use your best judgment, then poll your users. If a preponderance of the people you test are confused by your icon choices, switch them around. Then test them again and see if your initial test holds up. :)
If you are just going to have one button to toggle between two states, then the button should represent the next state, because that is the action that the button will take when clicked.
You gave the example of text that is minimized/maximized. Think of any expandable tree interface you ever see in Windows. A minimized tree has a [+] next to it, because clicking the button will expand the tree. And a maximized tree has a [-] next to it for the same reason.
You could also try to make a toggle that is highlighted or "pressed down" like mihi says, but that might be more confusing.
I prefer the "next state" approach (click plus to expand, click minus to collapse).
One reason is that this is the most widely used approach, so doing anything else would confuse users (and me as well).
Another reason is that the "next state" approach looks more inviting for the user to click.
May I present Zoom's mute button:
It shows the current state, as an icon, and the action that will occur when you push the button, as text. In other words, the icon on the button is the current state and the label on the button is the new state. The current state and the new state are opposites, so the button appears to contradict itself unless you read it very carefully.
(I hate that button.)