I know how to implement the back button. My question is about the desired behaviour (as I experienced there is a hype around it that the good implementation of back button is required to sell the app in the store).
There is the official source:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff402536(v=vs.105).aspx#BKMK_BackButton
But I have never used a WP8 for more than 5 minutes. I understood that the "Windows" button/key is the same as android home and ios home buttons. Is it true, that the WP8 back should be the same as the android back? (Briefly navigate back through pages (screens/activities), dismiss alerts or cancel confirm popups, or if it is the first/only/final page/activity, the app should exit.)
As I experienced, there is a long-press on the back button, which brings up the app switcher (~ios double home). Is it true that I should not take care about of this button? Is the default behavoiur the same for the remaining buttons (windows, power off, camera (half and full), search)? Should I override them? Can I override them (I think I can use camera, but can I use volume controls for other purposes)?
The certification requirements lay out what the back button should do pretty well. In short, it sounds like how you described the Android back button - here are the relevant requirements:
(5.2.4.1) Pressing the Back button must return the app to the previous page or return to any previous page within the back stack.
(5.2.4.2) Pressing the Back button from the first screen of an app must close the app.
(5.2.4.3) If the current page displays a context menu or a dialog, the pressing of the Back button must close the menu or dialog and return the user to the screen where the context menu or dialog box was opened.
You don't have to handle triggering the long-press, nor do you need to handle navigation specifically (assuming you're using the NavigationService for page navigation.)
You can definitely override the camera button, but search, power, and volume are off limits.
Related
We are doing User acceptance testing on a Xamarin Forms UWP app targeting windows 10 tablet. We are finding that when the user clicks on a textbox to enter data the soft keyboard appears as expected. However, when the user then clicks into the next textbox to enter a second required piece of data, the soft keyboard hides/closes. This results in the user having to double hit the second textbox (and any more than might need to be filled). The first click hides the keyboard, the second then causes the keyboard to reappear. To say the least this is not a good user experience. I'm guessing maybe the focus of the second is firing before the lost focus of the first? Has anyone else observed this behavior and is there any easy fix? As may want to target both Android and Windows I'm hoping for a simple solution but maybe UWP just does has some problems?
I've seen a Windows Phone 7 app with a window/popup which shows, after a use choice, half covering the current window, sliding in from the left while it closes when the users taps outside that window. For Windows 8x Store apps, this is a PopUp Control in a Flyout. But this is not available for Windows Phone.The regular pop-up control doesn't slide in with
<toolkit:TransitionService.NavigationInTransition>
which does work in a page-to-page transition. I have not succeeded either in closing it when I tap outside the pop-up. I tried adding LostFocus="MyEndPopUp" but that method is never called and also tried to end it on a OnNavigateFrom. What do I miss here?
If anyone could e.g. point me to some sample code doing more or less what I want would be great.
Is it allowed by Windows Phone application certification rules, to only have users be able to return to a previous screen with the use of a hardware back button?
In my scenario, a user clicks on a setting button and lands at a settings page. He changes settings if he decides to, and all the changes get saved automatically, like in iOS.
But currently, the only way for the user to get out of the settings screen, is to press a hardware Back button on the phone.
Will such implementation of navigation functionality pass the Windows Phone certification?
Yes - leave the back button as the navigation method to get back to your main page after visiting the settings page. Not only is this allowed, but it is the desired method of back navigation, and it is what Windows Phone users expect. Here is a great article on the subject: http://blogs.msdn.com/b/ptorr/archive/2011/10/06/back-means-back-not-forwards-not-sideways-but-back.aspx
As far as I understand the terms of the navigation guideline is your usage the right way to go.
Back button
Pressing the back button from the first screen of an application must exit the application.
Pressing the back button must return the application to the previous page.
If the current page displays a context menu or a dialog, the pressing the Back button must close the menu or dialog and cancel the
backward navigation to the previous page.
You should only implement back button behaviors that navigate back or dismiss context menus or modal dialog boxes. All other
implementations are prohibited.
See this cheat sheet for more informations on the design guidelines.
I'm reading the following sumission requirement:
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.
My application require LogIn the first time, before entering its MainPage.
The login data will not be asked again (the user can change account from the settings).
I would like to avoid user entering again in the login page by using the backstack.
Pressing back from MainPage will exit the application.
In particular I'm worried about:
a. I show as a first screen the login page which will navigate to the mainpage, but I'm exiting the app with a back from the mainpage
b. I'm skipping a page, so pressing back is not strictly going to the previouspage
Do you think it will satisfy the certification requirements ?
Thanks
This scenario is allowed, what you should do is:
upon entering the MainPage (OnNavigatedTo) - remove one page from the back stack:
NavigationService.RemoveBackEntry();
Read this thread on the Windows Phone forum
The most important part appears to be that you should never disable the back button but I do think that according to this thread that it is allowed to skip the login screen.
On the other hand you might want to rethink the flow of the application when you consider thombstoning and re-activating; should the user login again and what would a natural flow be?
Simple question:
How do I detect that the onscreen keyboard has been displayed on windows mobile 7? Is there an event I can add a listener to?
It takes up about half the screen and I want to scroll the view up when it gets displayed...
EDIT:
A comment below indicates more clearly what I'm trying to do: I have a textbox input, and as the user types into it an autocomplete dropdown appears below it (like google suggest). By default, the active control (the textbox) scrolls into view when focussed, and the onscreen keyboard is directly below it. The onscreen keyboard appears in front of my autocomplete dropdown - what I want to do is make the screen scroll a little further up, so there's some room for my dropdown to be shown.
The windows phone UI design guidelines say: "When the keyboard is deployed, the application should scroll to ensure the active edit control and the caret are in view". This happens fine, it's just the non-active dropdown gets hidden behind the onscreen keyboard.
The guidelines also say that an application can choose to show the onscreen keyboard, and can also choose to close it.
At the moment i'm stuck, and I don't think (based on my research and the replies to this question) that it's possible to detect that the onscreen keyboard has been displayed. I'm moving my investigation to see if it's possible to determine the "visible area" of the page (width & height in pixels for example), and combine this with an onfocus for the textbox... not sure if this will prove fruitful though.
Detecting when the virtual keyboard is displayed won't be possible in 7.0, as confirmed by Microsoft's Peter Torr in the WP7 forum on MSDN.
Maybe, as a dirty workaround, you could detect when the position of your text box (or its parent scroll viewer's offset) has changed, as this would indicate that the virtual keyboard has appeared or disappeared.
You can listen to the TextBox.GotFocus and TextBox.LostFocus events to detect when a text box in your application acquires and looses focus.
If an editable element gets focus then the framework will automatically scroll the element into view. So you really shouldn't have to do anything.