We are adding a feature to our Cordova app to catch unhandled exceptions and restart the app. We would like the browser history to be cleared in this case so the user can't hit back on an Android device to go back to the screen that crashed.
It isn't possible to clear the browser history programmatically, but I expected there to be a Cordova plugin that reinstantiates the whole app (i.e. deletes the current webview and creates a new one). I wasn't able to find anything like this though.
Is there a good way to do this that will work on both iOS and Android?
In Android for every WebView instance you can do:
webView.clearCache(true);
webView.clearHistory();
webView.clearFormData();
For IOS please read here: Clearing UIWebview cache
I'd rather suggest cordova-plugin-cache-clear, in order to handle more than just Chrome on Android. but having an Activity restart itself cannot be accomplished by some Cordova plugin (and in case of an Exception, not even by Activity.recreate()), but it would require a helper Service, which gets notified (of course these have to be handled exceptions, un-handled exceptions would nevertheless just crash) and then handles the situation accordingly. It might make more sense, to iron out possible reasons for crashes - instead of wasting time to creating questionable workarounds for code which was not properly forged, in the first place. besides, if this is JavaScript which bugs out, there might be no way to work around these issues at all, but to fix them.
Related
I'm developing a very simple Android application.
The application is just a webview linked to this OpenLayers3 docs.
There is really nothing special in the application. It is just a WebView,
but I get this rendering error when I open a popup:
This happen on a Honor7.
I noticed that if I disable the hardware acceleration the problem does not persist but in this way the performances are very poor.
Thanks a lot
This is probably due to the latest update to Android System Web View, that comes automatically from Google Play. If you uninstall the update, it helps. It is of course not a really good solution((((
I know there are a few techniques to see if IOS and Android apps are opened again (so if a user minimizes the app and then reopens it to the same state), but I am not sure how to do this in Cordova. Has anyone had success with this?
My only thoughts on how to solve this is to either just doing a check on the data that I am concerned with every x-seconds to see if there are changes in the background, but that seems bad practice with data on mobile, even though they should be small.
The other thought was to try writing a new plugin that can use the native techniques, but have not reached the point where that seems like a good fit either.
Hoping someone has a better idea or can at least tell me that one of these thoughts is not completely crazy.
Looking at:
http://cordova.apache.org/docs/en/4.0.0/cordova_events_events.md.html#resume
I see:
document.addEventListener("resume", yourCallbackFunction, false);
Which says:
The resume event fires when the native platform pulls the application
out from the background.
Applications typically should use document.addEventListener to attach
an event listener once the deviceready event fires.
My question is essentially a follow up or clarification to this question.
I have an Android app built using Javascript and Adobe's Phonegap Build service, and I'm using "local storage" to store data on the device.
From that other question, I learned that data stored in local storage is essentially "permanent", in that it will stay on the device indefinitely, unless the user acts on it by manually clearing the cache for the app or deletes the app (and maybe other unusual circumstances that I'm willing to live with).
However, part of the accepted answer was confusing to me in that it started to blur the lines between talking about the phone's browser and talking about a Phonegap app.
What is unclear to me is if an app on Android using Phonegap uses the same cache as the phone's built in browser. Is Phonegap essentially an extension of the existing browser facility, or is it it's own separate stand-alone and self contained browser?
Critically, if a user clears the cache in their browser, will that impact an installed app based on Phonegap?
Since Phonegap uses Webiview to render your app : WebView and Phonegap.
And For security reason each app that uses WebView has its own cache and history.
"No User or OS wants such data to be accessed by 3rd party applications".
So in a nutshell, your app will keep its own history and data in its cache folder and will be deleted in one of the following cases:
User manually deleted them.
User used app setting screen and deleted them.
App uninstalled.
To read more about this. take look at WebView cache : Cookie and window management
Nope, the cache created within the in-app browser can only be deleted with the methods:
window.localStorage.removeItem("key");
or
window.localStorage.clear();
or app uninstall
or manual action (delete data/cache) in the application manager.
But the best answer is to make an experiment yourself and see what happens.
Yes it is separate but there are time where you need to pass a variable of some kind to the In App Browser. It makes coding so much more easier to pass a ls item from a current webview to another one like in iOS.
Here is what I did in PhoneGap
I use the InAppBrowser executeScript() to pass a copy of the current webviews localStorage to another.
//add the listener to detect when the page loads after inappbrowser is called into view
ref.addEventListener('loadstop', function(){
ref.executeScript({code: 'SetInAppBrowserLocalStorage(\''+localStorage+'\');'});
});
//In your inAppBrowser page you create a function that will get called on loadStop
//This will pass "all" the contents of the main webviws localStorage to the webview
//created by InAppBrowser
function SetInAppBrowserLocalStorage(localStorageThatWasPassed){
localStorage = localStorageThatWasPassed;
};
You could also clear the localStorage created by SetInAppBrowserLocalStorage() before the use leaves that view as well.
Tested and working 100% :)...let me know if you need more help
***UPDATE*****
This still works ...but not consistently anymore. After much testing I realize this is simply not the way to go. Sometimes the data simply is not passed fast enough when the inappbrowser instance is created. I talked to the cordova guys via there issue tracker and they told me it wasn't a secure way of doing things...I get that...but my response to them was what if I just want to pass ls variables between pages in my app..those are not even accessible from the internet... I honestly don't understand why the ls items can't be accessible globally in the app like it is in iOS and the rest of the web. If anyone has a better solution I would love to hear about it.
By making this setting in your mainActivity (which is extending Droidgap.)
super.appView.getSettings().setCacheMode(WebSettings.LOAD_NO_CACHE);
We are making our app to not to store cache.
I'm trying to write a simple little addon for Firefox Mobile, starting from this skeleton. Ultimately I'd like to be running a bit of code against every new page loaded, which seems to be best accomplished by adding a "DOMContentLoaded" listener to every new tab, which fires when that tab loads a new page. To that end I need to detect new tabs, which is apparently in turn done by adding a "TabOpen" listener to the BrowserApp's deck.
Problem: At startup (but not when installing into an already loaded session), window.BrowserApp.deck is null for the only window. The documentation, what little there is, doesn't seem to suggest this is possible.
To test this yourself, download the skeleton linked above and add
window.NativeWindow.toast.show(window.BrowserApp, "long");
below line 48 of bootstrap.js, then build, install on Mobile Firefox, and restart. You'll see a toast reporting BrowserApp's properties, including 'deck: null'. (I'm also currently hosting a copy of the extension you'll so obtain on my server, which is be much quicker to test: just point your Mobile Firefox browser to that link, install, and restart.)
What gives? Am I misreading something? Is there a better way of doing what I'm trying to do which won't run into this problem? Is there more extensive documentation somewhere?
Wait for the UIReady event.
window.addEventListener("UIReady", function(){your code}, false);
Is there any way to programmatically pause an Android app in Phonegap? I would like to mimic the behavior that occurs when you hit the HOME button. I've already had to overwrite the back button handler using this, and while in most cases I want it to do my action, when in a particular state the user would expect the app to minimize, and I want to replicate this behavior.
Keep in mind, on Android this is not the same as closing the app. That is quite easy to do with device.exitApp(); but I would like it to remember its state and keep running in the background. Especially if there's still an asynchronous job being done in the background.
Is there a feature in Phonegap to achieve this?
Possible duplicate of Manually pause an application in Android Phonegap, but I couldn't find some of the tools the OP mentioned there such as navigator, so I was nervious to totally edit and rewrite their post
The simple answer appears to be: no.
However, for anyone else that comes down this path, its not impossible. It's just that there isn't a feature of Phonegap to do it for you.
The Android equivalent of "sleeping an app" is actually just opening another intent. Specifically, opening the "Home" intent would sleep the running app and bring you back to the home screen. But as far as I can tell from asking around and scoping the docs, Phonegap doesn't have a direct way of opening intents.
What you (supposedly) can do is one of two things:
This plugin is supposed to be promising
Call the Java code that does it yourself using the means described here
Mind you, as of right now I've decided to not go any further with this, so I make no promises about either of those means, having not attempted them myself.
I invite anyone else who decides to pursue this further to update their experience here.