My app was saving a bigger bundle in activity onSaveInstanceState() each time the screen was rotated, and I came across something really confusing. Here is a minimal example:
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
}
override fun onSaveInstanceState(outState: Bundle) {
super.onSaveInstanceState(outState)
val rcs = outState.getIntegerArrayList("KEY_COMPONENT_ACTIVITY_REGISTERED_RCS")
val keys = outState.getStringArrayList("KEY_COMPONENT_ACTIVITY_REGISTERED_KEYS")
Log.d("MainActivity", "${rcs?.size}: $rcs, $keys")
}
}
I get the following output each time the screen is rotated:
3: [1332505437, 1835553837, 670316111], [FragmentManager:StartIntentSenderForResult, ...
6: [1332505437, 91080073, 1835553837, 381123153, 1187376284, 670316111], ...
...
See the full log after 6 rotations: https://pastebin.com/yfE04Fmc
Each time the screen is rotated, 3 elements are added to these two entries. After rotating the screen for a while, the instance state becomes significantly bigger for no apparent reason.
Target API: 30
Tested on: API 28 and 30
Does anyone know why this is happening?
UPDATE: I want to clarify that I do not save any state into the Bundle. The values I show are created by Android itself: in ActivityResultRegistry. I've created an empty project for this example, and the code I provided is the only code I have - there is nothing else that interacts with the state Bundle.
UPDATE 2: Bug report submitted: https://issuetracker.google.com/issues/191893160
UPDATE 3: Bug fixed, will be a part of Activity 1.3.0-rc02 and 1.2.4 releases
Does anyone know why this is happening?
AppCompatActivity is extended from ComponentActivity (AppCompatActivity -> FragmentActivity -> ComponentActivity)
ComponentActivity is responsible for keeping the reference of ViewModelFactory, so that when the Activity recreates if can instantiate the same ViewModel before screen rotation.
Now inside ComponentActivity you will notice this:
#CallSuper
#Override
protected void onSaveInstanceState(#NonNull Bundle outState) {
Lifecycle lifecycle = getLifecycle();
if (lifecycle instanceof LifecycleRegistry) {
((LifecycleRegistry) lifecycle).setCurrentState(Lifecycle.State.CREATED);
}
super.onSaveInstanceState(outState);
mSavedStateRegistryController.performSave(outState);
mActivityResultRegistry.onSaveInstanceState(outState);
}
Here the important part is mActivityResultRegistry.onSaveInstanceState(outState)
Inside this method you will see
public final void onSaveInstanceState(#NonNull Bundle outState) {
outState.putIntegerArrayList(KEY_COMPONENT_ACTIVITY_REGISTERED_RCS,
new ArrayList<>(mRcToKey.keySet()));
outState.putStringArrayList(KEY_COMPONENT_ACTIVITY_REGISTERED_KEYS,
new ArrayList<>(mRcToKey.values()));
outState.putStringArrayList(KEY_COMPONENT_ACTIVITY_LAUNCHED_KEYS,
new ArrayList<>(mLaunchedKeys));
outState.putBundle(KEY_COMPONENT_ACTIVITY_PENDING_RESULTS,
(Bundle) mPendingResults.clone());
outState.putSerializable(KEY_COMPONENT_ACTIVITY_RANDOM_OBJECT, mRandom);
}
So you can see from there that the Android platform itself is saving this key in the bundle. Hence you can not do much about it.
In other word, One of the parents of AppCompatActivity is saving these keys inside the Bundle. If you are not using ViewModel and do not want these keys to be saved; you can remove super.onSaveInstanceState(outState) from MainActivity (NOT RECOMMENDED). You will still get your saved keys but there could be some side effect, I am not aware of.
Good thing that you have reported an issue regarding this, let's see how the Google Team respond to it.
It all depends on how you store the data in Bundle, according to standard Android developer document https://developer.android.com/guide/components/activities/activity-lifecycle#restore-activity-ui-state-using-saved-instance-state
Saving the state:
override fun onSaveInstanceState(outState: Bundle?) {
// Save the user's current game state
outState?.run {
putInt(STATE_SCORE, currentScore)
putInt(STATE_LEVEL, currentLevel)
}
// Always call the superclass so it can save the view hierarchy state
super.onSaveInstanceState(outState)
}
companion object {
val STATE_SCORE = "playerScore"
val STATE_LEVEL = "playerLevel"
}
Restoring the state:
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState) // Always call the superclass first
// Check whether we're recreating a previously destroyed instance
if (savedInstanceState != null) {
with(savedInstanceState) {
// Restore value of members from saved state
currentScore = getInt(STATE_SCORE)
currentLevel = getInt(STATE_LEVEL)
}
} else {
// Probably initialize members with default values for a new instance
}
// ...
}
Am not sure why you are getting the data from the bundle in onSaveInstanceState() method.
Also since you are saving list, want to highlight this point.
Saved instance state bundles persist through both configuration
changes and process death but are limited by storage and speed,
because onSavedInstanceState() serializes data to disk. Serialization
can consume a lot of memory if the objects being serialized are
complicated. Because this process happens on the main thread during a
configuration change, long-running serialization can cause dropped
frames and visual stutter.
Do not use store onSavedInstanceState() to store large amounts of
data, such as bitmaps, nor complex data structures that require
lengthy serialization or deserialization. Instead, store only
primitive types and simple, small objects such as String. As such, use
onSaveInstanceState() to store a minimal amount of data necessary,
such as an ID, to re-create the data necessary to restore the UI back
to its previous state should the other persistence mechanisms fail.
Most apps should implement onSaveInstanceState() to handle
system-initiated process death
First of all, why u don't use ViewModel instead?
This may not solve your problem but one thing that you could try is removing the duplicate values. Keep the latest ones and remove the olders. Something like this:
Kotlin
override fun onSaveInstanceState(outState: Bundle) {
super.onSaveInstanceState(outState)
removeDuplicates(outState)
}
private fun removeDuplicates(bundle: Bundle) {
val prevRCS = bundle.getIntegerArrayList("PREVIOUS_KEY_COMPONENT_ACTIVITY_REGISTERED_RCS")
val newRCS = bundle.getIntegerArrayList("KEY_COMPONENT_ACTIVITY_REGISTERED_RCS")
val newKeys = bundle.getStringArrayList("KEY_COMPONENT_ACTIVITY_REGISTERED_KEYS")
if (newRCS == null || newKeys == null) return
if (prevRCS == null) {
bundle.putIntegerArrayList("PREVIOUS_KEY_COMPONENT_ACTIVITY_REGISTERED_RCS", newRCS)
//bundle.putStringArrayList("PREVIOUS_KEY_COMPONENT_ACTIVITY_REGISTERED_KEYS", newKeys)
} else if(prevRCS.size() != newRCS.size()) {
for (rcs in prevRCS) {
val index = newRCS.indexOf(rcs)
newRCS.remove(index)
newKeys.remove(index)
}
bundle.remove("KEY_COMPONENT_ACTIVITY_REGISTERED_RCS")
bundle.remove("KEY_COMPONENT_ACTIVITY_REGISTERED_KEYS")
bundle.putIntegerArrayList("KEY_COMPONENT_ACTIVITY_REGISTERED_RCS", newRCS)
bundle.putIntegerArrayList("PREVIOUS_KEY_COMPONENT_ACTIVITY_REGISTERED_RCS", newRCS)
bundle.putStringArrayList("KEY_COMPONENT_ACTIVITY_REGISTERED_KEYS", newKeys)
//bundle.putStringArrayList("PREVIOUS_KEY_COMPONENT_ACTIVITY_REGISTERED_KEYS", newKeys)
}
}
Java
#Override
protected void onSaveInstanceState(Bundle outState)
{
super.onSaveInstanceState(outState);
removeDuplicates(outState);
}
private static final void removeDuplicates(final Bundle bundle)
{
if(bundle == null) return;
final ArrayList<Integer> prevRCS = bundle.getIntegerArrayList("PREVIOUS_KEY_COMPONENT_ACTIVITY_REGISTERED_RCS");
final ArrayList<Integer> newRCS = bundle.getIntegerArrayList("KEY_COMPONENT_ACTIVITY_REGISTERED_RCS");
final ArrayList<String> newKeys = bundle.getStringArrayList("KEY_COMPONENT_ACTIVITY_REGISTERED_KEYS");
if(newRCS == null || newKeys == null) return;
if(prevRCS == null) {
bundle.putIntegerArrayList("PREVIOUS_KEY_COMPONENT_ACTIVITY_REGISTERED_RCS", newRCS);
//bundle.putStringArrayList("PREVIOUS_KEY_COMPONENT_ACTIVITY_REGISTERED_KEYS", newKeys);
} else if(prevRCS.size() != newRCS.size()) {
for(Integer rcs : prevRCS) {
final int index = newRCS.indexOf(rcs);
newRCS.remove(index);
newKeys.remove(index);
}
bundle.remove("KEY_COMPONENT_ACTIVITY_REGISTERED_RCS");
bundle.remove("KEY_COMPONENT_ACTIVITY_REGISTERED_KEYS");
bundle.putIntegerArrayList("KEY_COMPONENT_ACTIVITY_REGISTERED_RCS", newRCS);
bundle.putIntegerArrayList("PREVIOUS_KEY_COMPONENT_ACTIVITY_REGISTERED_RCS", newRCS);
bundle.putStringArrayList("KEY_COMPONENT_ACTIVITY_REGISTERED_KEYS", newKeys);
//bundle.putStringArrayList("PREVIOUS_KEY_COMPONENT_ACTIVITY_REGISTERED_KEYS", newKeys);
}
}
I'm getting user reports from my app in the market, delivering the following exception:
java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState
at android.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1109)
at android.app.FragmentManagerImpl.popBackStackImmediate(FragmentManager.java:399)
at android.app.Activity.onBackPressed(Activity.java:2066)
at android.app.Activity.onKeyUp(Activity.java:2044)
at android.view.KeyEvent.dispatch(KeyEvent.java:2529)
at android.app.Activity.dispatchKeyEvent(Activity.java:2274)
at com.android.internal.policy.impl.PhoneWindow$DecorView.dispatchKeyEvent(PhoneWindow.java:1803)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112)
at com.android.internal.policy.impl.PhoneWindow$DecorView.superDispatchKeyEvent(PhoneWindow.java:1855)
at com.android.internal.policy.impl.PhoneWindow.superDispatchKeyEvent(PhoneWindow.java:1277)
at android.app.Activity.dispatchKeyEvent(Activity.java:2269)
at com.android.internal.policy.impl.PhoneWindow$DecorView.dispatchKeyEvent(PhoneWindow.java:1803)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112)
at android.widget.TabHost.dispatchKeyEvent(TabHost.java:297)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112)
at com.android.internal.policy.impl.PhoneWindow$DecorView.superDispatchKeyEvent(PhoneWindow.java:1855)
at com.android.internal.policy.impl.PhoneWindow.superDispatchKeyEvent(PhoneWindow.java:1277)
at android.app.Activity.dispatchKeyEvent(Activity.java:2269)
at com.android.internal.policy.impl.PhoneWindow$DecorView.dispatchKeyEvent(PhoneWindow.java:1803)
at android.view.ViewRoot.deliverKeyEventPostIme(ViewRoot.java:2880)
at android.view.ViewRoot.handleFinishedEvent(ViewRoot.java:2853)
at android.view.ViewRoot.handleMessage(ViewRoot.java:2028)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:132)
at android.app.ActivityThread.main(ActivityThread.java:4028)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:491)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:844)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:602)
at dalvik.system.NativeStart.main(Native Method)
Apparently it has something to do with a FragmentManager, which I don't use. The stacktrace doesn't show any of my own classes, so I have no idea where this exception occurs and how to prevent it.
For the record: I have a tabhost, and in each tab there is a ActivityGroup switching between Activities.
Please check my answer here. Basically I just had to :
#Override
protected void onSaveInstanceState(Bundle outState) {
//No call for super(). Bug on API Level > 11.
}
Don't make the call to super() on the saveInstanceState method. This was messing things up...
This is a known bug in the support package.
If you need to save the instance and add something to your outState Bundle you can use the following:
#Override
protected void onSaveInstanceState(Bundle outState) {
outState.putString("WORKAROUND_FOR_BUG_19917_KEY", "WORKAROUND_FOR_BUG_19917_VALUE");
super.onSaveInstanceState(outState);
}
In the end the proper solution was (as seen in the comments) to use :
transaction.commitAllowingStateLoss();
when adding or performing the FragmentTransaction that was causing the Exception.
There are many related problems with a similar error message. Check the second line of this particular stack trace. This exception is specifically related to the call to FragmentManagerImpl.popBackStackImmediate.
This method call, like popBackStack, will always fail with IllegalStateException if the session state has already been saved. Check the source. There is nothing you can do to stop this exception being thrown.
Removing the call to super.onSaveInstanceState will not help.
Creating the Fragment with commitAllowingStateLoss will not help.
Here's how I observed the problem:
There's a form with a submit button.
When the button is clicked a dialog is created and an async process starts.
The user clicks the home key before the process is finished - onSaveInstanceState is called.
The process completes, a callback is made and popBackStackImmediate is attempted.
IllegalStateException is thrown.
Here's what I did to solve it:
As it is not possible to avoid the IllegalStateException in the callback, catch & ignore it.
try {
activity.getSupportFragmentManager().popBackStackImmediate(name);
} catch (IllegalStateException ignored) {
// There's no way to avoid getting this if saveInstanceState has already been called.
}
This is enough to stop the app from crashing. But now the user will restore the app and see that the button they thought they'd pressed hasn't been pressed at all (they think). The form fragment is still showing!
To fix this, when the dialog is created, make some state to indicate the process has started.
progressDialog.show(fragmentManager, TAG);
submitPressed = true;
And save this state in the bundle.
#Override
public void onSaveInstanceState(Bundle outState) {
...
outState.putBoolean(SUBMIT_PRESSED, submitPressed);
}
Don't forget to load it back again in onViewCreated
Then, when resuming, rollback the fragments if submit was previously attempted. This prevents the user from coming back to what seems like an un-submitted form.
#Override
public void onResume() {
super.onResume();
if (submitPressed) {
// no need to try-catch this, because we are not in a callback
activity.getSupportFragmentManager().popBackStackImmediate(name);
submitPressed = false;
}
}
Check if the activity isFinishing() before showing the fragment and pay attention to commitAllowingStateLoss().
Example:
if(!isFinishing()) {
FragmentManager fm = getSupportFragmentManager();
FragmentTransaction ft = fm.beginTransaction();
DummyFragment dummyFragment = DummyFragment.newInstance();
ft.add(R.id.dummy_fragment_layout, dummyFragment);
ft.commitAllowingStateLoss();
}
It's October 2017, and Google makes Android Support Library with the new things call Lifecycle component. It provides some new idea for this 'Can not perform this action after onSaveInstanceState' problem.
In short:
Use lifecycle component to determine if it's correct time for popping up your fragment.
Longer version with explain:
why this problem come out?
It's because you are trying to use FragmentManager from your activity(which is going to hold your fragment I suppose?) to commit a transaction for you fragment. Usually this would look like you are trying to do some transaction for an up coming fragment, meanwhile the host activity already call savedInstanceState method(user may happen to touch the home button so the activity calls onStop(), in my case it's the reason)
Usually this problem shouldn't happen -- we always try to load fragment into activity at the very beginning, like the onCreate() method is a perfect place for this. But sometimes this do happen, especially when you can't decide what fragment you will load to that activity, or you are trying to load fragment from an AsyncTask block(or anything will take a little time). The time, before the fragment transaction really happens, but after the activity's onCreate() method, user can do anything. If user press the home button, which triggers the activity's onSavedInstanceState() method, there would be a can not perform this action crash.
If anyone want to see deeper in this issue, I suggest them to take a look at this blog post. It looks deep inside the source code layer and explain a lot about it. Also, it gives the reason that you shouldn't use the commitAllowingStateLoss() method to workaround this crash(trust me it offers nothing good for your code)
How to fix this?
Should I use commitAllowingStateLoss() method to load fragment? Nope you shouldn't;
Should I override onSaveInstanceState method, ignore super method inside it? Nope you shouldn't;
Should I use the magical isFinishing inside activity, to check if the host activity is at the right moment for fragment transaction? Yeah this looks like the right way to do.
Take a look at what Lifecycle component can do.
Basically, Google makes some implementation inside the AppCompatActivity class(and several other base class you should use in your project), which makes it a easier to determine current lifecycle state. Take a look back to our problem: why would this problem happen? It's because we do something at the wrong timing. So we try not to do it, and this problem will be gone.
I code a little for my own project, here is what I do using LifeCycle. I code in Kotlin.
val hostActivity: AppCompatActivity? = null // the activity to host fragments. It's value should be properly initialized.
fun dispatchFragment(frag: Fragment) {
hostActivity?.let {
if(it.lifecyclecurrentState.isAtLeast(Lifecycle.State.RESUMED)){
showFragment(frag)
}
}
}
private fun showFragment(frag: Fragment) {
hostActivity?.let {
Transaction.begin(it, R.id.frag_container)
.show(frag)
.commit()
}
As I show above. I will check the lifecycle state of the host activity. With Lifecycle component within support library, this could be more specific. The code lifecyclecurrentState.isAtLeast(Lifecycle.State.RESUMED) means, if current state is at least onResume, not later than it? Which makes sure my method won't be execute during some other life state(like onStop).
Is it all done?
Of course not. The code I have shown tells some new way to prevent application from crashing. But if it do go to the state of onStop, that line of code wont do things and thus show nothing on your screen. When users come back to the application, they will see an empty screen, that's the empty host activity showing no fragments at all. It's bad experience(yeah a little bit better than a crash).
So here I wish there could be something nicer: app won't crash if it comes to life state later than onResume, the transaction method is life state aware; besides, the activity will try continue to finished that fragment transaction action, after the user come back to our app.
I add something more to this method:
class FragmentDispatcher(_host: FragmentActivity) : LifecycleObserver {
private val hostActivity: FragmentActivity? = _host
private val lifeCycle: Lifecycle? = _host.lifecycle
private val profilePendingList = mutableListOf<BaseFragment>()
#OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
fun resume() {
if (profilePendingList.isNotEmpty()) {
showFragment(profilePendingList.last())
}
}
fun dispatcherFragment(frag: BaseFragment) {
if (lifeCycle?.currentState?.isAtLeast(Lifecycle.State.RESUMED) == true) {
showFragment(frag)
} else {
profilePendingList.clear()
profilePendingList.add(frag)
}
}
private fun showFragment(frag: BaseFragment) {
hostActivity?.let {
Transaction.begin(it, R.id.frag_container)
.show(frag)
.commit()
}
}
}
I maintain a list inside this dispatcher class, to store those fragment don't have chance to finish the transaction action. And when user come back from home screen and found there is still fragment waiting to be launched, it will go to the resume() method under the #OnLifecycleEvent(Lifecycle.Event.ON_RESUME) annotation. Now I think it should be working like I expected.
Here is a different solution to this problem.
Using a private member variable you are able to set the returned data as an intent that can then be processed after super.onResume();
Like so:
private Intent mOnActivityResultIntent = null;
#Override
protected void onResume() {
super.onResume();
if(mOnActivityResultIntent != null){
... do things ...
mOnActivityResultIntent = null;
}
}
#Override
public void onActivityResult(int requestCode, int resultCode, Intent data){
if(data != null){
mOnActivityResultIntent = data;
}
}
Short And working Solution :
Follow Simple Steps
Steps
Step 1 : Override onSaveInstanceState state in respective fragment. And remove super method from it.
#Override
public void onSaveInstanceState( Bundle outState ) {
}
Step 2 : Use
fragmentTransaction.commitAllowingStateLoss( );
instead of fragmentTransaction.commit( ); while fragment operations.
BEWARE, using transaction.commitAllowingStateLoss() could result in a bad experience for the user. For more information on why this exception is thrown, see this post.
I found a dirty solution for this kind of problem. If you still want to keep your ActivityGroups for whatever reason (I had time limitation reasons), you just implement
public void onBackPressed() {}
in your Activity and do some back code in there. even if there is no such Method on older Devices, this Method gets called by newer ones.
Do not use commitAllowingStateLoss(), it should only be used for cases where it is okay for the UI state to change unexpectedly on the user.
https://developer.android.com/reference/android/app/FragmentTransaction.html#commitAllowingStateLoss()
If the transaction happens in ChildFragmentManager of parentFragment, use
parentFragment.isResume() outside to check instead.
if (parentFragment.isResume()) {
DummyFragment dummyFragment = DummyFragment.newInstance();
transaction = childFragmentManager.BeginTransaction();
trans.Replace(Resource.Id.fragmentContainer, startFragment);
}
I had a similar problem, the scenario was like this:
My Activity is adding/replacing list fragments.
Each list fragment has a reference to the activity, to notify the activity when a list item is clicked (observer pattern).
Each list fragment calls setRetainInstance(true); in its onCreate method.
The onCreate method of the activity was like this:
mMainFragment = (SelectionFragment) getSupportFragmentManager()
.findFragmentByTag(MAIN_FRAGMENT_TAG);
if (mMainFragment == null) {
mMainFragment = new SelectionFragment();
mMainFragment.setListAdapter(new ArrayAdapter<String>(this,
R.layout.item_main_menu, getResources().getStringArray(
R.array.main_menu)));
mMainFragment.setOnSelectionChangedListener(this);
FragmentTransaction transaction = getSupportFragmentManager()
.beginTransaction();
transaction.add(R.id.content, mMainFragment, MAIN_FRAGMENT_TAG);
transaction.commit();
}
The exception was thrown because the when configuration changes (device rotated), the activity is created, the main fragment is retrieved from the history of the fragment manager and at the same time the fragment already has an OLD reference to the destroyed activity
changing the implementation to this solved the problem:
mMainFragment = (SelectionFragment) getSupportFragmentManager()
.findFragmentByTag(MAIN_FRAGMENT_TAG);
if (mMainFragment == null) {
mMainFragment = new SelectionFragment();
mMainFragment.setListAdapter(new ArrayAdapter<String>(this,
R.layout.item_main_menu, getResources().getStringArray(
R.array.main_menu)));
FragmentTransaction transaction = getSupportFragmentManager()
.beginTransaction();
transaction.add(R.id.content, mMainFragment, MAIN_FRAGMENT_TAG);
transaction.commit();
}
mMainFragment.setOnSelectionChangedListener(this);
you need to set your listeners each time the activity is created to avoid the situation where the fragments have references to old destroyed instances of the activity.
If you inherit from FragmentActivity, you must call the superclass in onActivityResult():
#Override
protected void onActivityResult(int requestCode, int resultCode, Intent intent) {
super.onActivityResult(requestCode, resultCode, intent);
...
}
If you don't do this and try to show a fragment dialog box in that method, you may get OP's IllegalStateException. (To be honest, I don't quite understand why the super call fixes the problem. onActivityResult() is called before onResume(), so it should still not be allowed to show a fragment dialog box.)
Fragment transactions should not be executed after Activity.onStop() !
Check that you do not have any callbacks that could execute transaction after onStop(). It is better to fix the reason instead of trying to walk around the problem with approaches like .commitAllowingStateLoss()
Possibly the smoothest and the simplest solution I found in my case was to avoid popping the offending fragment off the stack in response to activity result. So changing this call in my onActivityResult():
popMyFragmentAndMoveOn();
to this:
new Handler(Looper.getMainLooper()).post(new Runnable() {
public void run() {
popMyFragmentAndMoveOn();
}
}
helped in my case.
I was getting this exception when i was pressing back button to cancel intent chooser on my map fragment activity.
I resolved this by replacing the code of onResume(where i was initializing the fragment) to onstart() and the app is working fine.Hope it helps.
Courtesy: Solution for IllegalStateException
This issue had annoyed me for a lot of time but fortunately I came with a concrete solution for it. A detailed explanation of it is here.
Using commitAllowStateloss() might prevent this exception but would lead to UI irregularities.So far we have understood that IllegalStateException is encountered when we try to commit a fragment after the Activity state is lost- so we should just delay the transaction until the state is restored.It can be simply done like this
Declare two private boolean variables
public class MainActivity extends AppCompatActivity {
//Boolean variable to mark if the transaction is safe
private boolean isTransactionSafe;
//Boolean variable to mark if there is any transaction pending
private boolean isTransactionPending;
Now in onPostResume() and onPause we set and unset our boolean variable isTransactionSafe. Idea is to mark trasnsaction safe only when the activity is in foreground so there is no chance of stateloss.
/*
onPostResume is called only when the activity's state is completely restored. In this we will
set our boolean variable to true. Indicating that transaction is safe now
*/
public void onPostResume(){
super.onPostResume();
isTransactionSafe=true;
}
/*
onPause is called just before the activity moves to background and also before onSaveInstanceState. In this
we will mark the transaction as unsafe
*/
public void onPause(){
super.onPause();
isTransactionSafe=false;
}
private void commitFragment(){
if(isTransactionSafe) {
MyFragment myFragment = new MyFragment();
FragmentManager fragmentManager = getFragmentManager();
FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();
fragmentTransaction.add(R.id.frame, myFragment);
fragmentTransaction.commit();
}
}
-What we have done so far will save from IllegalStateException but our transactions will be lost if they are done after the activity moves to background, kind of like commitAllowStateloss(). To help with that we have isTransactionPending boolean variable
public void onPostResume(){
super.onPostResume();
isTransactionSafe=true;
/* Here after the activity is restored we check if there is any transaction pending from
the last restoration
*/
if (isTransactionPending) {
commitFragment();
}
}
private void commitFragment(){
if(isTransactionSafe) {
MyFragment myFragment = new MyFragment();
FragmentManager fragmentManager = getFragmentManager();
FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();
fragmentTransaction.add(R.id.frame, myFragment);
fragmentTransaction.commit();
isTransactionPending=false;
}else {
/*
If any transaction is not done because the activity is in background. We set the
isTransactionPending variable to true so that we can pick this up when we come back to
foreground
*/
isTransactionPending=true;
}
}
I think using transaction.commitAllowingStateLoss(); is not best solution.
This exception will be thrown when activity's configuration changed and fragment onSavedInstanceState() is called and thereafter your async callback method tries to commit fragment.
Simple solution could be check whether activity is changing configuration or not
e.g. check isChangingConfigurations()
i.e.
if(!isChangingConfigurations()) {
//commit transaction.
}
Checkout this link as well
Whenever you are trying to load a fragment in your activity make sure that activity is in resume and not going to pause state.In pause state you may end up losing commit operation that is done.
You can use transaction.commitAllowingStateLoss() instead of transaction.commit() to load fragment
or
Create a boolean and check if activity is not going to onpause
#Override
public void onResume() {
super.onResume();
mIsResumed = true;
}
#Override
public void onPause() {
mIsResumed = false;
super.onPause();
}
then while loading fragment check
if(mIsResumed){
//load the your fragment
}
If you are doing some FragmentTransaction in onActivityResult what you can do you can set some boolean value inside onActivityResult then in onResume you can do your FragmentTransaction on the basis of the boolean value. Please refer the code below.
#Override
protected void onResume() {
super.onResume;
if(isSwitchFragment){
isSwitchFragment=false;
bottomNavigationView.getTabAt(POS_FEED).select();
}
}
#Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
if (requestCode == FilterActivity.FILTER_REQUEST_EVENT && data != null) {
isSwitchFragment=true;
}
}
In regards to #Anthonyeef great answer, here is a sample code in Java:
private boolean shouldShowFragmentInOnResume;
private void someMethodThatShowsTheFragment() {
if (this.getLifecycle().getCurrentState().isAtLeast(Lifecycle.State.RESUMED)) {
showFragment();
} else {
shouldShowFragmentInOnResume = true;
}
}
private void showFragment() {
//Your code here
}
#Override
protected void onResume() {
super.onResume();
if (shouldShowFragmentInOnResume) {
shouldShowFragmentInOnResume = false;
showFragment();
}
}
The exception is threw here (In FragmentActivity):
#Override
public void onBackPressed() {
if (!mFragments.getSupportFragmentManager().popBackStackImmediate()) {
super.onBackPressed();
}
}
In FragmentManager.popBackStatckImmediate()，FragmentManager.checkStateLoss() is called firstly. That's the cause of IllegalStateException. See the implementation below:
private void checkStateLoss() {
if (mStateSaved) { // Boom!
throw new IllegalStateException(
"Can not perform this action after onSaveInstanceState");
}
if (mNoTransactionsBecause != null) {
throw new IllegalStateException(
"Can not perform this action inside of " + mNoTransactionsBecause);
}
}
I solve this problem simply by using a flag to mark Activity's current status. Here's my solution:
public class MainActivity extends AppCompatActivity {
/**
* A flag that marks whether current Activity has saved its instance state
*/
private boolean mHasSaveInstanceState;
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
}
#Override
protected void onSaveInstanceState(Bundle outState) {
mHasSaveInstanceState = true;
super.onSaveInstanceState(outState);
}
#Override
protected void onResume() {
super.onResume();
mHasSaveInstanceState = false;
}
#Override
public void onBackPressed() {
if (!mHasSaveInstanceState) {
// avoid FragmentManager.checkStateLoss()'s throwing IllegalStateException
super.onBackPressed();
}
}
}
If you have crash with popBackStack() or popBackStackImmediate() method please try fixt with:
if (!fragmentManager.isStateSaved()) {
fragmentManager.popBackStackImmediate();
}
This is worked for me as well.
In my case I got this error in an override method called onActivityResult. After digging I just figure out maybe I needed to call 'super' before.
I added it and it just worked
override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {
super.onActivityResult(requestCode, resultCode, data); //<--- THIS IS THE SUPPER CALL
if (resultCode == Activity.RESULT_OK && requestCode == 0) {
mostrarFragment(FiltroFragment.newInstance())
}
}
Maybe you just need to add a 'super' on any override you are doing before your code.
Kotlin extension
fun FragmentManager?.replaceAndAddToBackStack(
#IdRes containerViewId: Int,
fragment: () -> Fragment,
tag: String
) {
// Find and synchronously remove a fragment with the same tag.
// The second transaction must start after the first has finished.
this?.findFragmentByTag(tag)?.let {
beginTransaction().remove(it).commitNow()
}
// Add a fragment.
this?.beginTransaction()?.run {
replace(containerViewId, fragment, tag)
// The next line will add the fragment to a back stack.
// Remove if not needed.
// You can use null instead of tag, but tag is needed for popBackStack(),
// see https://stackoverflow.com/a/59158254/2914140
addToBackStack(tag)
}?.commitAllowingStateLoss()
}
Usage:
val fragment = { SomeFragment.newInstance(data) }
fragmentManager?.replaceAndAddToBackStack(R.id.container, fragment, SomeFragment.TAG)
Starting from support library version 24.0.0 you can call FragmentTransaction.commitNow() method which commits this transaction synchronously instead of calling commit() followed by executePendingTransactions(). As documentation says this approach even better:
Calling commitNow is preferable to calling commit() followed by executePendingTransactions() as the latter will have the side effect of attempting to commit all currently pending transactions whether that is the desired behavior or not.
I know there is an accepted answer by #Ovidiu Latcu but after some while, error still persist.
#Override
protected void onSaveInstanceState(Bundle outState) {
//No call for super(). Bug on API Level > 11.
}
Crashlytics still sending me this weird error message.
However error now occurring only on version 7+ (Nougat)
My fix was to use commitAllowingStateLoss() instead of commit() at the fragmentTransaction.
This post is helpful for commitAllowingStateLoss() and never had a fragment issue ever again.
To sum it up, the accepted answer here might work on pre Nougat android versions.
This might save someone a few hours of searching.
happy codings. <3 cheers
To bypass this issue, we can use The Navigation Architecture Component , which was introduced in Google I/O 2018.
The Navigation Architecture Component simplifies the implementation of navigation in an Android app.
change getFragmentManager() to getChildFragmentManager(). Don't use parent FragmentManager, try to use self.
Add this in your activity
#Override
public void onSaveInstanceState(Bundle outState) {
super.onSaveInstanceState(outState);
if (outState.isEmpty()) {
// Work-around for a pre-Android 4.2 bug
outState.putBoolean("bug:fix", true);
}
}
I have also experienced this issue and problem occurs every time when context of your FragmentActivity gets changed (e.g. Screen orientation is changed, etc.). So the best fix for it is to update context from your FragmentActivity.
I ended up with creating a base fragment and make all fragments in my app extend it
public class BaseFragment extends Fragment {
private boolean mStateSaved;
#CallSuper
#Override
public void onSaveInstanceState(Bundle outState) {
mStateSaved = true;
super.onSaveInstanceState(outState);
}
/**
* Version of {#link #show(FragmentManager, String)} that no-ops when an IllegalStateException
* would otherwise occur.
*/
public void showAllowingStateLoss(FragmentManager manager, String tag) {
// API 26 added this convenient method
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
if (manager.isStateSaved()) {
return;
}
}
if (mStateSaved) {
return;
}
show(manager, tag);
}
}
Then when I try to show a fragment I use showAllowingStateLoss instead of show
like this:
MyFragment.newInstance()
.showAllowingStateLoss(getFragmentManager(), MY_FRAGMENT.TAG);
I came up to this solution from this PR: https://github.com/googlesamples/easypermissions/pull/170/files
I am making a frisbee logger and have an ArrayList of Team objects. Each Team has an ArrayList of Player objects. Everything is using Serializable properly to be sent using Intent.
In my main activity I am displaying the list of Team objects in a ListView and an option to add another Team (only a name is needed). Once a Team is selected I pass the object to another activity using Intent. On this second activity I have it display the list of Player objects and have fields to enter another player object into the passed list.
When I return to the main activity and go back to the add Player activity, what I have added is gone.
I cannot use static because there is obviously more than one Team object. I think passing back the changed ArrayList could work but that seems a little lame, time-consuming, and frustrating.
Is there a built-in way in Android Studio that does this or am I on my own?
Note: I am not using SQLite as suggested in the comments
There's not a whole lot to show on this but here it is I guess:
MainActivity.java
private static ArrayList<Team> listOfTeams = new ArrayList<>();
private static ArrayList<Game> listOfGames = new ArrayList<>();
private ListView gameList, teamList;
.....
teamList.setOnItemClickListener(new AdapterView.OnItemClickListener() {
#Override
public void onItemClick(AdapterView<?> parent, View view, int position, long id) {
Team t = (Team)teamList.getItemAtPosition(position);
viewTeam(t);
}
});
.....
//Item select in teamList. Start the TeamViewActivity
public void viewTeam(Team t)
{
Intent i = new Intent(this, TeamViewActivity.class);
i.putExtra("teamView",t);
startActivity(i);
}
TeamViewActivity.java
private Team team;
private ListView rosterList;
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_team_view);
rosterList = (ListView) findViewById(R.id.playerList);
Intent i = getIntent();
Bundle extras = i.getExtras();
if(extras!=null)
{
if(extras.get("teamView")!=null)
{
team = (Team) extras.get("teamView");
}
}
populateRosterList(team.getRoster());
}
public void addPlayerToRoster(View view)
{
String checkFirst = ((EditText) findViewById(R.id.firstText)).getText().toString();
String checkLast = ((EditText) findViewById(R.id.lastText)).getText().toString();
String checkNumber = ((EditText) findViewById(R.id.numberText)).getText().toString();
if(!checkNumber.equals(""))
{
team.addPlayer(checkFirst, checkLast, Integer.parseInt(checkNumber));
((EditText) findViewById(R.id.firstText)).setText("");
((EditText) findViewById(R.id.lastText)).setText("");
((EditText) findViewById(R.id.numberText)).setText("");
populateRosterList(team.getRoster());
}
}
public void returnToMain(View view)
{
Intent i = new Intent(this, MainActivity.class);
i.putExtra("teamView", team);
startActivity(i);
}
private void populateRosterList(ArrayList<Player> list)
{
ArrayAdapter<Player> adapter = new ArrayAdapter<>(this,
R.layout.activity_list, R.id.genericText, list);
rosterList.setAdapter(adapter);
}
Consider your concept:
You serialize an object, i.e. you transform it into a transferrable format which is then copied over to the other activity and reconstructed as a new instance.
Consequently, you alter another instance, which is not available in the previous activity, if you do not return it - again, serialized - and finally reconstruct and copy it back into the respective instance.
What you need is a shared memory storage in your application, which can alter and retrieve data cross-activity OR a proper data routing using Intents w/ ISerializable.
Options:
Always serialize objects and pass and copy them around.
-> No multithreaded alteration, possibly slow, unbeautiful
Singleton application with global data storage ir Context Object (I do NOT recommend the due to memory management and Garbage
Collection inbetween Activity Switches BUT for consistency I'd
wanted to mention this option)
SQLite3
-> Quick, Simple and Scalable, But a bit cumbersome to get started with
Any other file-structure stored and maintained in the data folder
-> I'd expect a lot of boilerplate code here, and low performance
Webservice and remote database
Proper component setup, i.e. initialize all accessing components in your software with the appropriate reference to the data structs using for example fragments (Thanks to #mismanc, I actually missed that option initially)
In general you could abstract all that away using services and repositories, which allows you to under-the-hood test options like 3. 4. And 5. and find your best solution, and in addition, keeo the accessing code simple and clean.
in your case, you can use startActivityForResult instead of startActivity, then get your modified Team object from onActivityResult(int requestCode, int resultCode, Intent data) to update your list.
startActivityForResult example
You can use fragments. You hold the list in the MainActivity and pass its reference to ShowListFragment and AddPlayerFragment by interfaces. And you can also do other operations over them. If you dont want to use json or sqlite it can be a good way for you.
MainActivity.java
public class MainActivity extends Activity implements ShowListener{
public interface ShowListener{
ArrayList<Team> getTeamList();
}
private ArrayList<Team> listOfTeams = new ArrayList<>();
#Override
public ArrayList<Team> getTeamList() {
return listOfTeams;
}
}
ShowListFragment.java
public class ShowListFragment extends Fragment {
private ArrayList<Team> listOfTeams;
private ShowListener listener;
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
listener = (ShowListener)getActivity();
listOfTeams = listener.getTeamList();
}
}
As #Kingfisher Phuoc mentioned you could use srartActivityForResult in case you don't want to change your approach.
Otherwise I will suggest you use either :
SharedPreference to store your arraylist object (by converting the arraylist to json then store it as string in json format). In the PlayerActivity you retrieve the data, manipulate it then save it. see this post
SQLite
I am using a class with static values called DB (for Data Base) in my application. When I first run the app, a static byte array from this class is filled and used. Then, when I partially close my app (not closing it definitily just put in background) if a reopen it after 20 seconds more or less, the value of the variable is still here but if I let my app in the background for more than 1 minute the value turns to null.
How can I avoid this to happen?
store your variable value to shared preferences and load the value from shared preferences in the onResume() Method of activity and store the value in the onPause() Method.
Handling lifestyle events properly is an important aspect of Android development.
I suggest that you read the following to make sure that you understand what happens to your app when you turn off your screen, change to another application or any other action that might change the state of your app:
http://developer.android.com/training/basics/activity-lifecycle/index.html
My suggestion is to store your data by overriding onSaveInstanceState() like so:
#Override
public void onSaveInstanceState(Bundle savedInstanceState)
{
// Save the user's current game state
savedInstanceState.putInt(STATE_SCORE, mCurrentScore);
savedInstanceState.putInt(STATE_LEVEL, mCurrentLevel);
// Always call the superclass so it can save the view hierarchy state
super.onSaveInstanceState(savedInstanceState);
}
Then on your onCreate(), you can reload it like so:
#Override
protected void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState); // Always call the superclass first
// Check whether we're recreating a previously destroyed instance
if (savedInstanceState != null)
{
// Restore value of members from saved state
mCurrentScore = savedInstanceState.getInt(STATE_SCORE);
mCurrentLevel = savedInstanceState.getInt(STATE_LEVEL);
}
else
{
// Probably initialize members with default values for a new instance
}
...
}
I hope that this helps!
Good luck in your future developing!
I found a solution with the help of the commenters.
For those who had the same problem:
Copy this in all your Activities to ensure that the data is constantly updated in the preferences:
#Override
public void onPause(){
super.onPause();
String bytearray = Base64.encodeToString(DB.bytearray, Base64.DEFAULT);
prefs.edit().putString("BYTEARRAY", bytearray).apply();
}
#Override
public void onResume(){
super.onResume();
String bytearray = prefs.getString("BYTEARRAY", Base64.encodeToString(DB.bytearray, Base64.DEFAULT));
DB.bytearray = Base64.decode(bytearray, Base64.DEFAULT);
}
Then, add this code in all your Activities to ensure that the values are not saved when you close your app.
#Override
public void onDestroy(){
super.onDestroy();
String bytearray = "";
prefs.edit().putString("BYTEARRAY", bytearray).apply();
}
So I have a Calendar obj which implements serializable by default and I want to pass it in a bundle so the value of it is saved on screen rotation.
Should I pass it as a serializable or extract the values and recreate the obj for efficiency?
bundle.putSerializable("key", calendar);
or
bundle.putInt("dayKey", calendar.get(Calendar.DAY_OF_MONTH));
bundle.putInt("monthKey", calendar.get(Calendar.MONTH));
bundle.putInt("yearKey", calendar.get(Calendar.YEAR));
Using Serializable is not recommended in Android; use Parcelable instead.
I would guess it depends on the size of the Object and how cumbersome it is to recreate manually.
Go with Parcelable over Serializable. If performance matters, Parcelable could be around 10x faster (http://www.developerphil.com/parcelable-vs-serializable/)
Additionally, you can use https://github.com/johncarl81/parceler to avoid generating (and maintaining!) all the boilerplate code that would otherwise exist.
#Parcel
public class Person {
...
}
Parcelable parcelable = Parcels.wrap(new Person(..));
Person = Parcels.unwrap(parcelable);
Honestly, while Parcelable is definitely the preferred serialization method, I think for this case you're fine just putting it as a Serializable extra. Considering the amount of work that is done recreating the Activity, I think the expense of serializing a Calendar instance would be negligible.
If nothing else, it makes your code more maintainable and succinct.
onSaveInstanceState method is used for store Activity's state. and it called when activity you rotate the screen or press home button or open new activity from notification bar.
It called after onPause() method.
You can save your custom Object or any primitive data type i.e. called Activities's states as
#Override
protected void onSaveInstanceState(Bundle outState) {
super.onSaveInstanceState(outState);
outState.putSerializable(KEY_CALENDAR, cal);
}
onRestoreInstanceState() method is used for restore your Activities's states.
It called after the onStart() method
You can Activities's state restore like
#Override
protected void onRestoreInstanceState(Bundle savedInstanceState) {
super.onRestoreInstanceState(savedInstanceState);
cal = (Calendar) savedInstanceState.getSerializable(KEY_CALENDAR);
}
Here you can use serializable for save Activities's state.
You can also use onCreate() method for restore your saved state because bundle is same deliver in both method onCreate(), onRestoreInstanceState() like
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
if(savedInstanceState != null) {
cal = (Calendar) savedInstanceState.getSerializable(KEY_CALENDAR);
} else {
cal = Calendar.getInstance();
cal.setTime(new Date());
}
}