I'm writing an Android program using Webview that can use the hard back key on the device, no problem with this.
But when the program goes "outside" and navigates through HTML / Javascript pages inside the Webview "wrapper" it cannot handle properly an href="javascript:window.history.back();" button, because it does not go up one level, just goes back and forward the previous page.
What am I doing wrong?
The javascript.window.history.back() function is designed to move back one step in the browser history. It does not (even on android platforms) emulate a click of the device's back button.
I believe the WebView component intercepts a press of the device's back button to allow a user to navigate back though the history until the point that the WebView was created (i.e. the first page viewed).
These two functions are completely separate, defined in different languages and one cannot be used for the other. If you want to implement the functionality of the device's back button you will need to do this within the application code, not a web page (a call to onKeyPress() should do the trick).
Related
Is it possible to use the soft button to go back to previous web page?
I know that when we use the android's normal internet App, the button is functioning properly.
However when I implement a simple app arranged WebView for the web surfing purpose, the soft button only works as a app shutting down operation not going to previous web page.
Oh, there kindly is a function named goBack();
I have developed a Worklight application Using Dojo 1.9. In my application for returning to previous view i am using a back button in my app's header.
Back Button Code
<div data-dojo-type="dojox.mobile.Heading"
data-dojo-props="label:'View2 Details',back:'View1', moveTo:'view1'" style="background-color: maroon">
</div>
Is it possible to use the device's back button to navigate to previous view? so that I can use both approaches in my app?
I am not familiar with the concept of "pages" in Dojo, however:
Yes, there is WL.App.overrideBackButton, that you can use to override the default Android Back button functionality (quitting the app) and instead call a callback that will load a different view.
Note that in order to restore the "quit" functionality when the app is in the index page, you will need to use WL.App.resetBackButton so that the user will be able to quit the app like how s/he is used to in Android.
As for how to handle a multi-page navigation with history, please see the relevant topic in this training module. You will have to adjust the code to that you use in Dojo.
Two alternate solutions:
The simplest would be to rely on Dojo Mobile's "bookmarkable"
feature. For details, see
https://dojotoolkit.org/reference-guide/dojox/mobile/bookmarkable.html.
Live example:
http://download.dojotoolkit.org/release-1.9.0/dojo-release-1.9.0/dojox/mobile/tests/test_bk_force-list.html. After transitioning from the home page, pressing browser's back
button on desktop browsers, or the back button of Android devices,
triggers a transition back to the initial view.
The saner solution for a relatively complex app requiring navigation
history management would be to build your app using dojox/app. See the documentation at http://dojotoolkit.org/reference-guide/1.9/dojox/app.html and the tutorials at https://dojotoolkit.org/documentation/tutorials/1.9/dojox_app/.
I am using Phonegap and JQuery mobile to make an app that has a lot of dynamic content. There are a lot of pages that are created dynamically. I need to get the back button working in Android. From this post, back button problems with PhoneGap and Jquery-mobile in android, I set $.mobile.phonegapNavigationEnabled = true and now the button at least acts like I expect it to. It goes back in history, skipping over the dynamically created pages. Before I added that, it was jumping all over the place.
My question is, how do I get those dynamically created pages into the history so that when the Android back button is pushed, it will go back the right way?
what is the best practice regarding the back button currently?
A lot of apps save and restore an entire activity stack when you open them (after they've been onStop and onDestroyed), take Facebook for example, when you open it and your last place was in a photo, then pressing back doesn't close the Facebook app, it takes you back infinitely till the very first thing you did when you opened the app days ago.
This design convention is a little different than what the back button would be expected to do, I think. Where it typically is used to kill the app or stop the main view taking you back to your device's launcher screen.
Facebook was just one example of an app doing this.
Are there developer articles or an authoritative source like Google I/O discussing the utility of this feature (restoring activity stack and having back button traverse through them) vs other functionality (killing the view taking user back out of the app)? If so, please discuss and link them here. I hope this isn't considered too subjective because there is a proper use of the back button as well as an incorrect use
What the Facebook app does actually is the basic default behavior of Android. Those apps don't do anything special regarding that behavior. The Activity stack is saved by default.
One of the more cited blogs regarding it is CommonsWare's BACK means Back. Basically, the functionality of the "BACK" button means it should to take you to the previous page that you just were at. In Android, this is very often the last Activity you just pushed. If the user wants to leave the app, then he or she can press the "HOME" button and that will always push the Activity stack and take the user to the homescreen.
What this means is, the functionality of the BACK button is entirely dependent on the app in question, but the concept is to reverse the action that the user just did. If you are in a game, you go to a sub menu, the BACK button should take you to the top menu. If you are in a browser, the BACK button may take you to the last webpage you were viewing. If you are in a browser and you are in the top page, the user may expect the BACK button to close the app since the last action the user did prior to opening the browser is open the app. If the user starts a download, the BACK button may be to cancel it.
One functionality improvement that Facebook and others like is may consider is to wipe the stack after x number of days since the user may not remember exactly what they did since being interrupted from the last use. The use case for this is very small though.
Overall, this is why people always stress usability testing. You have to figure out what 99% of the people of the app expected when they press the back button.
You can find on the Android Developer site that you should not change the expected behavior of the back button. Let the OS handle the back button.
App does not redefine the expected function of a system icon (such as
the Back button).
That quote is pulled from their Core App Quality page.
You should consider using Up Navigation. You can read more about designing for it here:
Lastly, here is a tutorial on how to implement various types of navigation (lateral, ancestral [up], temporal, descendant).
check here
From my personal experience you can close most, which are using back pressing to go to a previous screen, with a long click on the back button. The best example is the browser app, whether its the native one or a third-party browser
I think that behavior depends on application logic.
By default it is desired to move on previous screen (activity in back stack, or fragment if it was saved to the fragment's back stack).
Actually there is no any silver bullet for this case. Just use "back-pressed implementation" what ever you want. My point is that on back pressed, application must be shown in previous logical state.
I'm working on a Phonegap/jQuery Mobile Android app.
A particular piece of content involves displaying a page which is on our server. We have used an IFrame to display this, all works fine apart from the back button. If you click through a couple of pages within the IFrame and press the phone's back button the app goes back a page rather than the content within the iframe, which is an issue.
I'm guessing it would be really tricky to get around this, but does anyone have ideas or alternate methods of displaying a external site with back button use?
Probably you need to override the default onBack method, and provide your own.
You need to figure out how to simulate going back within the iFrame programmatically