I have a problem that causes me some problems when a user (or another app, like the phone-application) pushes my application to the background.
My application does following:
A User can enter some information that is supposed to be pushed to a server.
When the user clicks "Send" i open a managed ProgressDialog and start an AsyncTask that performs the server communication.
When server communication is complete the AsyncTask reports back to my Activity where i perform a dismissDialog().
Directly after dismissDialog(), I will show another managed dialog using showDialog() that will inform the user about whether the submission was ok or if it failed.
This all works perfectly without any issues; however, when a call happens to come while the AsyncTask is running I get (seemingly random) one of these results:
The activity holding the managed dialog is dismissed completely and the previous view from the stack is presented when I come back.
The activity holding the managed dialog is still on screen, but it is grayed out without showing a dialog. The only way to fix this is to rotate the phone at which point it shows the "Submission sent"-dialog exactly the way it should and everything is ok after that.
All this happens without any warning messages so I get absolutely no clues as to why Android is behaving this way.
I know a way around this and that is to cancel the AsyncTask (so no dialogs are shown at the end). However, in this very use-case the requirements are that the app has to try to complete the server transaction so that there is as little confusion as possible (i.e. the user wondering if it was really sent or not).
Has anybody else had this issue and knows a way around?
I see recommendations to hold a reference to the asynch task in onRetainNonConfigurationInstance
What to do with AsyncTask in onPause()?
Or implement a bus:
https://github.com/commonsguy/cwac-bus/tree
EDIT: The complexity of your challenge is two fold:
1) saving and restoring state of your app on a kill such as when there is an incoming phone call
https://sites.google.com/site/jalcomputing/home/mac-osx-android-programming-tutorial/saving-instance-state
2) somehow continuing the asyncTask on kill instead of canceling it onPause
https://sites.google.com/site/jalcomputing/home/mac-osx-android-programming-tutorial/asynch
Both of these are significant challenges alone, and trying to fix both at the same time would give me a headache. In fact, I am getting a headache just thinking on it :) One clue is that you say the dialog returns on orientation change. This MAY be due to the fact that using the standard architecture for dialogs, the OS handles saving and restoring the state of dialogs for you on orientation change.
[EDIT] See CommonsWare
#Override
public Object onRetainNonConfigurationInstance() {
task.detach();
return(task);
}
and
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
bar=(ProgressBar)findViewById(R.id.progress);
task=(RotationAwareTask)getLastNonConfigurationInstance();
if (task==null) {
task=new RotationAwareTask(this);
task.execute();
}
else {
task.attach(this);
updateProgress(task.getProgress());
if (task.getProgress()>=100) {
markAsDone();
}
}
}
where task is an instance of
static class RotationAwareTask extends AsyncTask<Void, Void, Void> {
I see no reason why this would not work for all types of soft kills, but on a hard kill, well, you get killed. Dead is dead :)
Without looking at your code it is slightly difficult to say what the problem is. However, here is something you could use to help get around the problem. You can override the onPause() method of your Activity.
This is taken directly from the Android Acitivy javadoc:
onPause() is where you deal with the user leaving your activity. Most importantly, any changes made by the user should at this point be committed (usually to the ContentProvider holding the data)
Related
I wondered if anyone can shed some light on this,
I have one activity app which has a listview. In onCreate() I populate some data in that listview (reading it from sqlite database). I have a close button which triggers finish(); too. now when I press close button, activity disappears but when I click on app icon on desktop (or selecting it from phone history button) I see all previous data in the listview. the function that I am looking for is to start app fresh after clicking close button for next run. (something like banking app log-out button). (list view here is only an example to put across the need, so clearing list-view before finish(); is not acceptable. It is very simple and plain request and I do not think any code is necessary but if anyone interested I will post some code too.
What I want is same behavior as a banking app in exit, when user leave the main screen or click sign out, the App closes altogether. I can achieve this by using following methods (number 2 and 3) but apparently these solutions are not best practices. Then what method a banking App uses to close the app instantly? I doubt they use something which is not best practice such as System.exit(0)?! or do they!
Many developers claiming closing an App or killing parent activity
is OS job
Some say use use :
int pid = android.as.Process.myPid();
android.os.Process.killProcess(pid);
(this solution according to this is not a good idea because in next run app acts like it has been crashed last time https://stackoverflow.com/a/24015569/4173238 )
some say use System.exit(0); according to this
https://stackoverflow.com/a/5846275/4173238 is not recommended either
some say use finish(); but finish does not do what I want
Thanks for any input
If you have a mechanism that allows it so that you only deliver messages to the main thread when the application is resumed, then you can register your activities on an event bus like Otto and send an event that every Activity is subscribed to on which they call finish() on themselves.
Another possible solution is starting every activity with startActivityForResult(), and if you click the exit button, then you would say
public static final int KILL_ACTIVITY_RESULT_CODE = 0xD34DB33F; //why not
public boolean onOptionsMenuItemSelected(MenuItem menuItem) {
if(menuItem.getId() == R.menu.kill_activity) {
setResult(KILL_ACTIVITY_RESULT_CODE);
finish();
}
}
#Override
public void onActivityResult(int requestCode, int resultCode, Intent data) {
if(resultCode == KILL_ACTIVITY_RESULT_CODE) {
setResult(KILL_ACTIVITY_RESULT_CODE);
finish();
}
}
}
...and one time I've seen someone make static references to every single activity they had, and called finish() on each and every one of them. But don't do that, that essentially means you have failed as an Android programmer, and there is nothing to redeem you of your sins.
As brilliant CommonsWare, has pointed out in his comment "Static" was the issue! I was using static variables to store data to fill My listView. Apparently even if you have only one Activity and close it, Static variables remain intact! on app re run!
If you asking why I used static variable at the first place, I have to say, right or wrong, I wanted to share that variable between my other java class (my databaseHandler.class).
Why Android not clear all (including static variables) resources when closing the main and only Activity of app, remains a question and this is my next reading topic! but many thanks for anyone who post a comment on this question,
I will also change the question from:
How Banking Apps close? finish() does not do the same job for me
to
closing an activity using finish(); wont make app start fresh in next
run! why?
Is there any best practices when changing activities in Android?
It seems very odd to me, just make an Intent and start another activity over and over.
If I just start another activity and finish the last one, when I have to move back, I need to load all the stuff back. But when I don't do it, does not seem to be the right thing to do in terms of memory handling.
Is it correct to save all the activities in a kind of ActivitiesPool or something like this? Or I will always have to choose between keeping them opened or reload them?
Any directions?
Thanks
It seems very odd to me, just make an Intent and start another activity over and ove
that's how it works on Android. To be more precise we (as developers) are not even allowed by the System to call new Activity() you just startActivity(intent);
I need to load all the stuff back
again, the framework is taking care of loading/unloading resources as needed
Is it correct to save all the activities in a kind of ActivitiesPool
no, it's not correct, don't touch them.
If you want the user to be able to click the back button and go to the previous activity, DO NOT call finish(); on it. You can use onPause()/onResume() callbacks to handle background operations and UI status should be saved on #Override protected void onSaveInstanceState(Bundle outState) callback. You put all the UI state that you need in there. If the system needs memory it will destroy the activity and whenever the user is going back to it, it will create it again onCreate(Bundle savedInstances) and then you'll have all the UI state saved there for you to proper re-create the state where the user was before.
That's how it works.
I'm facing a serious problem with the Croutons Notification Library,
When i quickly switch my activites, sometimes (very often indeed) croutons for updates, like missing credentials, or "insert date first" are not shown anymore,
and so the users stay without any info, what's the problem.
For instance also the simple usecase:
Login To Application,
Logout,
try to re-login but with false credentials,
doesnt show a crouton anymore.
I tried:
Courton.clearAllNotifcations() in inPause(),
and additionally,
Crouton.clearCroutonsForActivity(this) too in onPause(),
to maybe solve the Problem, but it didn't.
I also debugged in the CroutonLibrary and the problem seems to be,
a Crouton gets added to queue, the the activity gets finished, the something finishes (like aSyncTask showing a crouton in onPostExecute(), this one gets added to the queue again, and then the queue is stuck.
Also.clearAllNotifications (which actually clears the queue) doesn't work, because the courton (asynctask finishes after acitvity.finish()) gets added afterwards, and the problem persists.
also tried:
#Override
protected void onDestroy() {
Crouton.clearCroutonsForActivity(this);
Crouton.cancelAllCroutons();
super.onDestroy();
}
knwon issue: https://github.com/keyboardsurfer/Crouton/issues/24
but didn't work too...
Thankful for any advice!
:)
You have found the correct issue on Crouton and the part of the code that is responsible for producing the issue.
In your case it correlates with the AsyncTask which is still running when your Activity actually should have been destroyed already. It's generally a good thing to move long running behavior out of user facing components, i.e. using a service layer.
Until then canceling the AsyncTask should do the trick.
thx #keyboardsurfer for the explanation...
adding...
and extracting the AsyncTask to a member variable...
#Override
protected void onPause() {
Crouton.clearCroutonsForActivity(this);
if (loadTasksTask != null) {
loadTasksTask.cancel(true);
}
super.onPause();
}
fixed the issue! :)
thx a lot :)
I have an Activity that should only get created once. That is, onCreate can only be called once. If it's called again, I want the Activity to do nothing.
Is it advisable to do the following?
protected void onCreate(Bundle savedInstanceState) {
this.setTheme(android.R.style.Theme_Translucent_NoTitleBar_Fullscreen);
super.onCreate(savedInstanceState);
if(onCreateWasCalledAlreadyBoolean) {
setResult(RESULT_OK);
finish();
return;
}
//Do other stuff here
}
I assume you understand how the activity life cycle works. I mean, you are not trying to avoid something that does not apply here (thinking that onCreate may be called multiple times whenever it just onRestarts etc.).
Technically, it's perfectly fine.
However, you should be worrying more about why you need to call your activity ("A") again if it shouldn't be created at all, if that's what you're thinking.
If you've caught yourself checking if your activity A was already "called" (?), this could mean the previous activity ("B") has a mistake in the logic flow of the app, and that B instead should be checking if it must in fact start that activity A. I mean, if you need to decide if you must call an activity, check before starting it.
I don't think that's applicable if you're restarting the activity (e.g.: go Home, then navigate back), but then again you should be restarting it from where you left (B for what I can tell). You won't be navigating back to A. And you didn't give much detail, so I'd guess this is some kind of splash screen, like evilmage93 said.
If that's indeed some kind of splash screen, I would advise to show it whenever the user navigates back all the way to remove your app from the task stack (contrary to his advice). In other words, whenever the user restarts the app from its "front door".
Although that's ultimately a design decision, I prefer to see the splash screen whenever the app is being loaded ("entered") in the stack for the first time, and it should work fine if you (obviously) finish A before calling B (the splash screen is supposed to finish itself when done, even in its first run). It's a matter of consistency: the same app should behave the same way whenever the user performs the same task (start app from its "front door").
Still, I answered your question covering some general aspects because you asked in such way.
// edited:
Finally, by looking at that onCreateWasCalledAlreadyBoolean I'm afraid you may be trying to reinvent part of the activity life cycle mechanism. In this case, don't: proceed with your regular activity logic because the user expects that behavior. Generally I wouldn't advise people to break the normal loading of an activity just because it was killed and restarted by the system.
I don't see why not. Wouldn't it be simpler to not restart the activity at all though?
What are you worried about NOT being okay? Performance..Uncaught exceptions..Code clarity?
I read a lot about handling rotation in android applications, but I still have so many questions and need to much to understand.
Let me explain my problem or implementation, that I'm using now in my application.
If an activity will be opened, a get request will be sent to server. This request will be executed in a Thread (new Thread(...)) and if request was completed, activity's ui will be refreshed.
But what should I do, if the user rotate his device?
By default, the activity will be destroyed and request will be started again and start a new thread, but the thread of destroyed activity may be still running.
I guess, it's a quite wrong way, I have now.
But what is the best approach, to handle this?
Probably is the best way to forbid rotation, but what If I don't want that?!
May be it's the second part of my question:
I saw a video form Google IO. Mr. Dobjanschi suggested to use services and to store retrieved data in content provider. So, probably I can use a service for executing my requests. But should data be replaced every time the get request was completed?!
Well dont know exactly how its done, You can try saving the instance and retrieving the same when config changes with following methods:
I have read about them but haven't really implemented them yet. I hope it can give you some start.
#Override
public Object onRetainNonConfigurationInstance() {
return(myServerThread);
}
private void restoreServerFunctions() {
if (getLastNonConfigurationInstance()!=null) {
myServerThread=(Thread)getLastNonConfigurationInstance();
}
}
You can specify that the activity handles the rotation itself. This is done through adding:
android:configChanges="keyboardHidden|orientation"
in the tag of the activity inside your android manifest. You don't have to actually handle the rotation but this will tell android to not destroy your activity. The base activity class will handle all the rotating of the user interface for you and your thread will be executed correct.
A small side note: if you are doing only a small server task use AsyncTask to execute the call to the server in the background instead of creating a thread. This will minimze some of the programming effort you need to communicate the results from the thread to the activity and update your UI.
One easy way, though I've never tried it. Instead of refreshing the current UI, when the thread finishes, start a new Activity with the just downloaded content. So first, you start an Activity with a blank page (or just the page's frame), then you rotate the blank page as much as you like, then the downloading Thread spawns a new Activity, replacing the blank page Activity with the loaded content page using the current orientation.