I have tried the majority of the solutions posted both here and on other sites. I still can't catch the back button on my PhoneGap + jQuery Mobile android app. Let's start with the basic one:
document.addEventListener("backbutton", backKeyDown, true);
function backKeyDown() {
alert('back button pressed');
}
That doesn't seem to be firing at all.
Another thing I want to do is catch when the home button is pressed. I want to make it so that the app gets killed when I press the home button, mainly for security purposes.
Can anybody help me with my above dilemma?
I'm running into the same issue. I haven't fully solved it yet, but the problem seems to be that calls to the app plugin, including the call to enable button events, aren't running.
I was able to get the backbutton event firing by enabling the native part of the event binding in the java code:
super.loadUrl("file:///android_asset/www/loading.html", 20000);
appView.bindButton(true);
Update:
I found the actual cause of the problem - a bug in the development version of cordova that is now fixed.
Usually updating cordova is the first thing I try, but a simple pull didn't work because the repo is now http://github.com/apache/cordova-android - the old incubator-cordova-android still exists, but is not being updated and contains a version of the code from before this bug was fixed.
Related
I am using React Navigation 5, and I am trying to set up a focus listener on a Screen to perform some actions.
The Screen where I need to set up the listener is a Class component that triggers the browser launch, and I want to listen to when the user closes the browser with the "back navigation" and return to the app.
While testing this flow I noticed that the listener is not triggered when returning from the browser, or even when coming up from the background. On the other hand, I could successfully test that when navigating between screens within the app everything works as expected.
Moreover, I set up also the unsubscriber for the focus listener and I can see that it's not called improperly, and the listener still seems alive.
I searched for other issues, questions on SO, read the docs, but I couldn't find a solution. It's also true that I'm a newbie as long as React Native is concerned, but I would expect that the focus listener is triggered also after putting the app to background.
Or is there actually a way to achieve that?
I managed to create a Snack with a sample code (my app is not using Expo CLI, but I saw that the issue is correctly reproduced there too).
It's a very simple StackNavigator with 2 screens. Screen1 is the Class component in which I want to listen for the focus.
by pressing the "GO TO BROWSER" button, the Google website is opened, but navigating back to the app no logs appear informing that the focus is on;
going to background and getting the app back up no logs appear for the focus;
by pressing the "GO TO SCREEN 2" button, the second screen is opened, and upon back navigation, the focus test log informs us that the focus is now on.
My software versions:
iOS and Android 12.4.7 and API 29&24
#react-navigation/native 5.5.1
#react-navigation/stack 5.5.1
react-native-gesture-handler 1.6.1
react-native-safe-area-context 3.0.5
react-native-screens 2.8.0
react-native 0.62.2
node 12.17.0
npm 6.14.6
When a mobile app is closed it generates an event that can be captured.
// trap app shutdown event
Titanium.App.addEventListener(‘close’,function(e)
{
Ti.API.info(“The application is being shutdown”);
});
I would like to create an event handler that pops up an alert to ask "Are you sure you want to quit the app", just in case someone presses the wrong keys...
Is it this possible and can you cancel the shutdown event?
You can do it in Android only. It's not possible on iOS.
Further, on Android, this can only be done if app is closed by pressing back button, not from task manager.
Here's how you do it on Android:
<Alloy>
<Window id='win'>
</Window>
</Alloy>
// for Ti SDK 6.0.0.GA or above, you need to use this code
$.win.onBack = close;
// else use this code for SDK 5.5.1 or below
$.win.addEventListener('androidback', close);
function close() {
alert('Do you want to shut down app????');
}
Read about the androidback event here
And the ticket which added the above breaking change:
https://jira.appcelerator.org/browse/TIMOB-19919
Short answer is: No, you cannot
You can track events related to the lifecycle of the application but you cannot prevent that from happening. Without getting into the bad user experience that this could be let's talk about a user scenario will look like.
If you are using your Android phone and you want to close an app and it just keeps asking you if you are sure you want to close it, the programmer ignored the Yes action and keeps the app running. How insecure and annoying will this be?
I managed to resolve this problem by firstly hooking into the Android back event and secondly by using bencoding Alarm Manager to run the background code constantly. That way, if someone shut the UI down, the app continued to run in the background regardless.
So I've made myself a small "incremental game".
Note: For those who are not familiar with incrementals, you click on a button and it increases a value, a currency of sorts. You buy upgrades to autogenerate this currency after you've laboriously made enough by clicking/tapping manually, saving you the cost of buy a new mouse. Or a new phone, in this case.
Now, I've been testing around with it. New to Ionic and all. I've realized that on the android (I did Ionic run android from my CLI), if I hit the native "back" button on the phone, it pauses the app completely. My autogenerating is suspended. That's fine and all! It's intended after all.
The issue/problem comes when I hit the native "home" button. Which brings me to the home screen on an android as well as when my phone auto "sleeps". Whenever either of this happens, the autogenerating continues in the background, if you already bought upgrades. Which is the opposite of the intended function. It should stop!
So, coming from native android, java. I understand there's a lifecycle to apps.
QUESTION:
How is Ionic's like? And does it go into different states depending on the method of exiting the app? Is it different between iOS and Android? I've thus far fixed it for android but I don't know how to test if it works for the iOS...
Extra info: I'm currently using $interval to keep the game's main loop running. I autogen my currency once per second as well as save it into an sqlite database right after. (Both running at once per second). Also, I have no plugins installed! Using only services.
Okay. I've sort of figured that all this has something to do with the lifecycle. From what I know using my debugging tool, I'm tracking the app doing these two, "Resume" and "Pause" by typing in my controller:
document.addEventListener("resume", function() {
console.log("Resume!");
}, false);
document.addEventListener("pause", function() {
console.log("Pause!");
}, false);
I've figured out my issue using this. So I know that regardless of method of exiting the app, I will encounter "pause" and regardless of from which method you exit the app, it passes through "resume" state on the way back in. So using this two, I simply cancel my interval when it pauses and start it up again when it resumes!
I have developed an app in Cordova 3.6 with latest version of InAppBrowser. Run on Android device (4.1.2 and others) when the user taps a link to open InAppBrowser, occasionally a double window seems to open up. The second of these windows doesn't close.
To check if it was something I had done in my app, I quickly created a default Cordova hello world app and added the standard window.open code with link like this
OPEN WINDOW
and basic testing on the device revealed the same thing was happening - occasionally fast or double tapping made a double window open up, one of which was uncloseable. Either from <300ms double tap, or from double taps where the browser is slow to launch.
This doesn't appear to happen on iOS.
Any help gratefully appreciated.
UPDATE
Part of the problem on my main app was functions declared in wrong place (onpagecreate) being fired multiple times. I put this here in case someone does anything similar...
However on the hello world app the problem still occasionally happens. I tried with and without Fastclick, but Fastclick didn't work properly (possible conflict with jQuery Mobile, arrghh).
your problem is likely caused by using the 'onclick' event to launch the childbrowser.
onclick has a built in 300ms timeout, which can make an app appear laggy and causes some of the issues above.
Use mouseup/mousedown instead, and inside the handler, disable the listener
OPEN WINDOW
function open(url, name) {
// deregister the onclick listener, insuring the callback resolves
window.open(url,name);
// register the listener
}
I've got an app running jQuery 1.9.1, jQuery Mobile 1.4.2 and Phonegap 3.4.0.
It has a login screen so that when you first open the app, you input your info, it does an AJAX check and if all is well, stores your info and moves you past that page.
The ideal scenario, is that everytime the app is sent to the background (the user goes home or switches apps), and then restarts the app they have to login again.
Currently I am accomplishing this in iOS by setting the
<preference name="exit-on-suspend" value="true" />
preference in my config.xml. I am accomplishing the same thing in Android by using navigator.app.exitApp(); in a pause event listener.
This works well enough usually, but some older versions of android have a weird problem. While going home and restarting the app bring you to the login page, you can just hit the back button and it takes you to the last page you were on before you quit, and you are still logged in. I also have a function that destroys all user variables (rendering all pages useless) when the app pauses, but that also seems to be ignored. On older versions of Android (2.3 specifically), it seems that they are ignoring the pause event listener.
How do I fix that, or is there an all around better way of forcing login on restart?
Without knowing what other requirements you have or what behaviors you might expect from the home page, you could capture the back button event and prevent it from going anywhere.
//set a bit or note that you are on the login page
var onHome = true;
...
document.addEventListener("backbutton", backButtonTap, false);
function backButtonTap(e) {
if(onHome) {
e.preventDefault();
alert('Please Login');
}
}
Certainly not the only or perhaps the best way to handle it since the user appears to stay logged in, which you say is supposed to be wiped out, but it should at least prevent navigating away from the login page and going back.