Reputation: 2078
I'm developing an Android application and I would like to emulate the same behavior of the official Google Plus app when it is opened, which is:
My app has one activity that uses a navigation drawer and several fragments as pages. My goal is to retain the current fragment and display it when the app is resumed from the Recent Apps. I can manage to do so using SharedPreferences
by storing the tag of the current fragment and loading it when the user reopens the app. The problem with is solution is that this kind of data is persistent so the user will always be greeted to the last page even if he first removes the app from the Recent Apps list and reopens it.
So how can I detect whether the app is already in the Recent Apps list or not? Or is there any method that is called when an app is removed from that list so I can clear the last fragment tag from SharedPreferences
? Or am I using the wrong approach?
Thank you for you patience in reading this.
Upvotes: 2
Views: 4321
Reputation: 2078
As it turns out, the behavior I mentioned is automatic and there was a problem with my project that prevented it: this was the activity in my AndroidManifest.xml
<activity android:name=".MainActivity"
android:label="@string/app_name"
android:theme="@style/AppTheme.NoActionBar"
android:noHistory="true">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
android:noHistory
needs to be set false:
A value of "true" means that the activity will not leave a historical trace. It will not remain in the activity stack for the task, so the user will not be able to return to it. - Documentation
Upvotes: 2
Reputation: 1006584
When you return to your app through the recent-tasks list, there are three possibilities:
It has been a long time, over 30 minutes, and your process is not running. In that case, Android just launches your app as if the user tapped on your home screen launcher icon. You are not given your saved instance state, as it is deemed to be stale.
It has not been a long time, so Android wants the user to think that your app has been running since they left it. However, due to memory pressure, Android terminated your process while it was in the background. In this case, Android forks a new process for you, creates an instance of your activity, and passes to you your saved instance state Bundle
in onCreate()
and onRestoreInstanceState()
.
Your process is already running. In that case, your activity is just brought back to the foreground. You do not need your instance state, as your activity instance is still running. Android has not touched your widgets, and so if your UI is not the way you want it to be, that is your own fault, because you did something (e.g., in onPause()
or onStop()
) that screwed up your UI. From your descriptions, I am interpreting it that you are testing this scenario, in which case onRestoreInstanceState()
is not called, because it is not needed.
So, as long as you do not screw up your own UI, your app will work as you described it for Google Plus, so long as you handle the saved instance state for scenario #2 above.
On Android 5.0+, there are related scenarios tied into the PersistableBundle
that you can use with variations of onSaveInstanceState()
and kin. I have not played with the PersistableBundle
much and so I do not have any particular advice related to it.
Upvotes: 3