I have developed one app in which there is option for sharing on twitter.Its working properly fine.Now one requirement came which says that if the app is force killed it should again ask for authentication with twitter so that we can give user id and password again.The main thing is if user want to login to twitter with his new credentials how he will do that.Any idea how to solve this issue.Right now if i am uninstalling the app or clearing the data it is doing authentication but it should do on force killing the app.
You can't detect your app being force killed: https://groups.google.com/forum/?fromgroups#!topic/android-developers/xfkfRc-j4cw
It might be possible to set a flag when your app starts, and clear the flag when your app stops in an orderly way. If the flag is set when your app is starting, then you know it was last stopped in a disorderly way, like being force killed. This method of detection will probably give you both false positives (if someone pulls the battery out of their phone, your flag will probably still be set) and false negatives (if your app considers itself to have been stopped in an orderly way, and is then force killed). This method will surely give you angst and tears unto the fifth generation. Here be dragons, and the dragons will eat you.
You should push back against the requirement.
For your problem, you can clear your tokens when the app starts again, in an onStart(); method for example. So next time the user will use the application after the forced kill, this last wouldn't get any access tokens to work properly and would be consequently "forced" to ask tokens again via a classic OAuth Authentication Flow.
Reauthentications are just like classic authentications. At the end, the Twitter API will give you back the missed (or deleted) access tokens.
Related
About Android (6.0 to the last version)
I'm developing an app and we want that the user, once he accepts all the terms, don't be able to kill the process or force stop the app. Honestly, I'm completely lost right now, because on the last versions of android, and specially some brands like Xiaomi, we are having a lot of trouble with it, and we don't know how to act right now.
In the case that it could not be possible, could at least get an alert whenever the user is killing the app?
Thanks!!
It is not possible to prevent the user from killing an app. Android is a unique system where the app has no direct control over its lifecycle but the system has. The system can (and will, when required) kill the app or any of its processes at its own will. To make your app aware of these changes, the android framework provides for various callbacks such as onPause, onStop and onDestroy which are called in succession when the user kills the app.
Side Note : There is no guarantee that onDestroy() will be completely executed when the app is killed. Do not place essential code there.
Of course, you can block or try to prevent the user from closing your app by overriding the back, home and recent buttons but it is highly recommended not to do so. Even if you do so successfully, the user has other means to close your app such as rebooting their phone.
So what to do?
You are looking for a kiosk mode app. Kiosk mode is used for single purpose phones such as at a restaurant or for a cab driver. Kiosk mode apps lock down the user to only a specific app (or a specific set of apps).
For normal apps, it is not possible to prevent the user from force closing your app. You can only get alerts by checking for lifecycle changes as described above. Moreover, it is not at all recommended to change the natural behavior of the hardware buttons on android. The user can still find a way to close your app. If your app is doing something really essential which should proceed in the background, consider using a service for that instead. Also, the user can uninstall your app at anytime if they find your app being too intrusive and you won't be able to do anything in that scenario.
Tl;dr: Use kiosk mode to prevent the user from exiting the app. This will only allow the user to access your app(s) in their device.
Usually you cannot! Even if you try to disable some buttons, user can always stop app or restart device. In addition at times, the OS will stop the App. Your responsibility as a programmer is to program around this, and give the user the feel that it never stopped. If you are doing background monitoring, you will need to use service. Users will still be able to stop service. Having said that, you can set your app as a Device Administration app, see here, which may disallow stopping, but unless you are distributing internally to a company, noone will install.
I would like to get a list of users connected to internet and set their status as online. I am using Firebase Presence for it but it only works when the user in the application. When the user closes or minimizes the app, the status is set to offline but I want to keep the status online as long as the user has an active internet connection.
Note: I am using Android 8.0 and I know about limited background services.
How can I achieve this? Thank you.
Android may kill an app's process when it's no longer being used. This is something you should expect to happen. When that happens, Firebase will obviously lose its connection, and the app will be considered offline.
The only way to extend the life of your process is to start a foreground service in your app that stays active indefinitely. Even then, Android may still kill your app to make room for apps that are visible on screen. There is no way to guarantee that your app's process will never get killed for something more important to the end user.
Please read this documentation thoroughly to understand how Android prioritizes apps. Also read the documentation for Service.startForeground().
I have a Bike computer app that logs data while the user is riding. I have had a user report an issue I had not considered. He was out for a long ride (100+ miles) but while out and logging data the app got updated via Google plays auto-update. This unfortunately killed off the app mid recording and the user lost data till they spotted what had happened and restarted the app.
Ideally I would like to be able to programmatic stop the auto-update happening while the app is data logging. All my research indicates that this is not possible possible but I may of missed something so dose anyone know of a way of doing this?
Given no solution the best I can do is advice the users to enable the update only over wifi option in the Play app which in this instance would of helped. Unfortunately one of the key points about my app is that it will log indoor sessions using ANT+ sensors so I have a good number of people using it with wifi active.
Edit
I managed to do the experiment to see what happens myself last night. I had an app going in the background data logging then pushed a new version to Google Play. Unfortunatly it was not picked up totaly automaticaly when I had to leave 10 hours latter but I opened up the play store app and it found the update it did not start updating automaticaly but I forced it. The act of downloading and installing the new version killed off what was in progress. It was already dead before I used the notification to go to the new version.
As you say yourself, you can't do that what you are asking for. You could hack your way around it by changing the permissions each time you update. The users will then be prompted about it in the regular way.
I'm not sure about the "life-cycle" for automatic updated apps that are running. But I read somewhere that is wasn't the re-install but the reopen of the app that crashed it. If that is the case you could set a flag indicating that the user is currently logging and then on restart just resume the logging. But again we need to know more about the inner workings of activities/apps which are running and get an automatic update (actually didn't think it could happen).
Edit
Based on your findings I'd say you have to handle the app is shut down in onDestroy etc. or/and make sure you save everything persistently. Then you might need to have 2 apps where 1 listens to the other being re installed and when that happens it starts it up again (there is an interesting discussion here). If you are targeting api >= 12 then the broadcast action ACTION_MY_PACKAGE_REPLACED might also have interest.
I want to create a password-protected android application. The password should be asked when the task is started or when it comes to foreground.
The complex part is that my app can invoke device inbuilt camera application to capture photo/video, so I cannot control that activity.
So the behavior should be that whenever user starts/returns to my app then password should be asked except for the scenario when he is returning from camera that I sent him to in the first place.
I have thought following ideas, but none of them solve my problem completely, the best one I could think of is
1) Set a flag(flagA) while sending the user to camera, then in a service keep checking that the foreground app is our app. When the foreground app is not our app then set another flag(flagB) to indicate that our app has gone to background. When the app in foreground is our app again, then check if flagA is false (we didnt send him to camera) and flagB is true (app is coming from background). Then show the password screen
Problems
1) The polling interval must be small like 3-4 seconds, so that foreground is detected quickly. This drains the battery.
Thanks
A few ideas come to mind.
This is just a quick idea of mine so it might not be useful but considering you haven't told us what you've already tried / have in mind we don't have a lot to go with.
You'll need at least 2 Activities to handle the whole password idea.
Firstly, when you start the app, run Activity A. This will ask for the password (assuming the password is always the same). If the password is correct -> start an intent with Activity B.
If the password is incorrect, close the app.
In B, give the user the option to invoke the camera. After using the camera, return to Activity B.
It doesn't get much better with the amount of info you've given us, but it should give you an idea on how to start.
I have solved the problem partially
1) Have a static long variable to track the time between onPause() and onResume(). During normal app operation this time is under 1 second, but if app goes to background and comes to foreground then this duration is more than 1 second. So in onResume() if the duration is more than 1 second then show the Password screen.
2) To handle the camera problem I am having a flag to detect whether I opened the camera, if that flag is set then dont ask for password in onResume().
This solution is not fool proof but works in most scenarios.
I created an new Android app and succeeded in its working. Its all functionality are working fine. While starting it will ask use name and password.
What my problem was "If my Application is idle for some 4 to 5 hours, then automatically it get quit , while restarting its again asking to login"
I need to know how to avoid automatic quit of my app.
I'm sorry if its simple or already asked quetions.
I need to know how to avoid automatic quit of my app.
No, you do not. Simply redirect the user to log in again, or, as #Rasel suggests, persistently cache credentials in a file or database or something.
Android applications do not and must not live forever. Phones have limited RAM. Android will terminate unused applications after a period of inactivity, to free up RAM for other applications. This is perfectly normal, just as it is perfectly normal for a user to close a Web browser after visiting a Web app.
Its completely natural for the android application.Android OS automatically kill the process when it needs to do.So if you want keep your application alive you have to think differently.To keep always running you can use service that will monitor your application states and handle the situation when it prompts for the login info again.
Another option you can write the login information in the shared preference and can clean when user intentionally leave the application.So when starting again if you find the information you can directly prompt to the user without entering the login information