Develop Reference

Refresh the backstack Activities after Night Mode has changed

I have seen a lot of questions and answers about recreating the current activity after changing the application's Night Mode, but I have seen nothing on how to refresh the back stack Activities.
Say I have the backstack A > B > C. Activity C allows to change the night mode by calling AppCompatDelegate.setDefaultNightMode(). After this call, the current Activity (C), can refresh its theme with delegate.applyDayNight() or recreate().
However, when the user navigates back to B or A, the activities are still using the "old" mode, either day or night.
I tried to add something like that to the Activities:
override fun onResume() {
super.onResume()
delegate.applyDayNight()
}
But it does not seem to work.
I did multiple attempts to fix this:
One idea would be to recreate the backstack completely like suggested here or here, but since the backstack is not static, it's not doable for me.
Another idea would be to have a class that handles the night mode change and provides a LiveData. Each Activity would listen to the LiveData for a mode change and call recreate(). However, we are stuck in an infinite loop because the Activity would recreate directly after starting to listen to the LiveData.
I find it hard to believe that I am the first one trying to refresh the Activities from the backstack after changing the night mode. What did I miss?
Thanks!

If you can detect when the day/night mode has changed, you can simply recreate an activity that is resumed when the back stack is popped.
In the following demo, there are three activities: A, B and C. A creates B and B creates C. Activity C can change the day/night mode. When C is popped, activity B sees the change in the day/night mode and calls reCreate() to recreate the activity. The same happens in activity A when activity B is popped.
The video below shows the effect. The light-colored background is the "day" mode and the dark is "night" mode.
I have created a GitHub project for this demo app. If this works as a solution, I can incorporate more text into the answer from the project.

Refreshing your back stack completely is probably overkill and may add some overhead/lag to the UX; and as you mentioned, most applications will not have access to a full, static back stack.
You are essentially describing a more general issue: global changes to the theme or WindowManager itself affect the subsequent drawing of views. But previous layouts for Activities in the stack may not be redrawn. It might seem odd for you in this situation, but there could also be many good reasons why one would not want to redraw an Activity in the stack if once the user goes back to it. And so this is not an automatic feature.
I can think of a couple of options:
1) Write a custom class inheriting from Activity that invalidates all it's views when it moves to the front of the stack again. E.g. in onResume() or onRestart(), call (if in Fragment)
View view = getActivity().findViewById(R.id.viewid);
view.invalidate();
Use this custom Activity for all your activities that you want to keep consistent with the current day/night mode.
2) Use ActivityLifecycleCallbacks. This helps keep all your logic in one place, and avoids the need for custom inheritance as above. You could invalidate your views here as needed as activities are paused/resumed. You could include a Listener, if it is your app that is changing the theme, and record as SharedPreference, for example.
To use, add the callbacks to your Application class:
registerActivityLifecycleCallbacks(new ActivityLifecycleCallbacks() {
#Override
public void
onActivityCreated(Activity activity, Bundle savedInstanceState) {
//can check type of Activity for custom behaviour, if using inheritance
if(activity instanceof MainActivity) {
mMainActivities.put(activity, new MainActivityEntry((MainActivity)activity));
//...
}
}
#Override
public void
onActivityDestroyed(Activity activity) {
}
#Override
public void
onActivityPaused(Activity activity) {
}
#Override
public void
onActivityResumed(Activity activity) {
if(activity instanceof MainActivity) {
//...
}
//can update Entry properties too
final MainActivityEntry activityEntry = mMainActivities.get(activity);
if(activityEntry != null) {
//record state /perform action
}
}
#Override
public void
onActivitySaveInstanceState(Activity activity, Bundle outState) {
}
#Override
public void
onActivityStarted(Activity activity) {
}
#Override
public void
onActivityStopped(Activity activity) {
}
});

Quick answer:
#Override
protected void onRestart() {
super.onRestart();
recreate();
}
You add the above codes to your MainActivity and it will work.

create a static boolean variable in the project and in each activity check if the boolean is true or false, then apply daylight and night based on value.

background a react-native android app using back button

I've followed the example pattern for handling the android back button in the react-native docs and it works well. I can use the hardware back button to pop my navigation stack.
At the point that there's only 1 view in the stack though I don't pop it (just like the example), and I return false from my hardwareBackPress event listener. At this point it I see the componentWillUnmount method being called in my final view, at which point my app shuts down.
If I return true then nothing happens at all obviously.
What I want to happen is that the app merely gets "backgrounded" instead of exiting completely.

Answered my own question. The trick is to override the default back button behaviour in the MainActiviy:
public class MainActivity extends ReactActivity {
#Override
protected String getMainComponentName() {
return "foo";
}
#Override
public void invokeDefaultOnBackPressed() {
// do not call super. invokeDefaultOnBackPressed() as it will close the app. Instead lets just put it in the background.
moveTaskToBack(true);
}
}

Though I may be very late in giving the answer it may help other facing the issue.
Recently I came across the same requirement where I have to move the app to the background. I tried the solution provided by #pomo. Though it worked I faced problems. Sometimes on multiple clicking of the back button, the app misbehaves in android though it worked perfectly fine in iOS.
And then I came across the following issues in GitHub where it mentions the reason for the misbehaviour.
The following solution works perfectly fine now.
// android/app/.../MainActivity.java
#Override
public void invokeDefaultOnBackPressed() {
moveTaskToBack(true);
}
<!-- AndroidManifest.xml -->
<activity
...
android:launchMode="singleTop">
Link from where I get the solution
I hope I'm able to help guys with the same requirement.

onOptionsItemSelected not called for Up button in Android 4.0.3

I am adding a Up button to my Android application. The app's minimum SDK is 14, and I am testing it with an HTC phone on SDK version 15.
The activity is a subclass of android.app.Activity (not ActionBarActivity from the support package).
ActionBar style display options includes the homeAsUp flag, and I am able to see the standard arrow. However, clicking on the logo does nothing.
I have connected the debugger, and I am able to see that the onOptionsItemSelected method is not called at all. This cannot be because of misspelt name, because other menu items (e.g., Settings) do work (and I can see in the debugger that onOptionsItemSelected method gets called).
The parentActivityName and meta-data PARENT_ACTIVITY are set correctly (although I believe this would only matter if the method got called).
Is there anything I am missing? And how do I get the up button to work?

I encountered the same issue "onOptionsItemSelected" not called when using the ActionBarDrawerToggle it seems like the solution is setting this listener - it is called when the Up button is clicked.
drawerToggle.setToolbarNavigationClickListener(new View.OnClickListener() {
#Override
public void onClick(View v) {
finish(); // or any other code you want to run here
}
});

ActionBarActivity back button not popping from backstack

I'm using this template https://github.com/kanytu/android-material-drawer-template just to try out material design so I've implemented a few fragments some have webviews some have not.
My problem is when switching between the fragments I can see them being successfully added to the backstack
getFragmentManager().beginTransaction().replace(R.id.container, new FAQ()).addToBackStack("FAQ").commit();
But when I press the back button it just closes the app.
When I change it to use Activity instead of ActionBarActivity the navigation works fine but I lose some other functionality.
There is an override on the back button
#Override
public void onBackPressed() {
if (mNavigationDrawerFragment.isDrawerOpen())
mNavigationDrawerFragment.closeDrawer();
else
super.onBackPressed();
}
but even if that's removed it still happens. I think the problem lies somewhere in the super.onBackPressed
Is there any reason ActionBarActivity would break the back button?

I recently read a post about this, sorry I can't find it anymore... But basically, it explained that the primary function of the back button is to finish the current Activity.
In fact, according to the onBackPressed() official documentation:
Called when the activity has detected the user's press of the back key. The default implementation simply finishes the current activity, but you can override this to do whatever you want.
And it would appear that even though the back button used to pop the backstack before 5.0, Google would have changed this behaviour with the new ActionBarActivity.
For my part, I used some workarround that works for me but that might not work for everybody, depending on your navigation implementation.
But in case it could be helpful to somebody, here it is :
#Override
public void onBackPressed()
{
if (mDrawerLayout.isDrawerOpen()) {
mDrawerLayout.closeDrawer();
} else if (getFragmentManager().getBackStackEntryCount() > 0) {
getFragmentManager().popBackStack();
} else {
super.onBackPressed();
}
}
This way, ActionBarActivity.onBackPressed() is only called when the backstack is empty, in which case it destroys the ActionBarActivity.

You should check "getFragmentManager" & "getSupportFragmentManager" is matched your activity & actionbaractivity or not.
Because, in Activity:
public void onBackPressed() {
if (!mFragments.popBackStackImmediate()) {
finish();
}
}
in FragmentActivity:
public void onBackPressed() {
if (!mFragments.popBackStackImmediate()) {
finish();
}
}
We can see the same code which already handled pop fragments backstatck.
In my situation, I used actionbaractivity(extends FragmentAcvitiy), but I also used "getFragmentManager" , so I got the same error as you. After I have replaced "getFragmentManager" to "getSupportFragmentManager", that's ok! You also can replace "actionbaractiviy" to "Activity" to fix this problem.
Must ensure "getFragmentManager" match "Activity", "getSupportFragmentManager" match "FragmentActivity(ActionbarActivity)".
If you want add actionbar On API level 11 or higher, You can see below:
https://developer.android.com/guide/topics/ui/actionbar.html#Adding
On API level 11 or higher
The action bar is included in all activities that use the Theme.Holo theme (or one of its descendants), which is the default theme when either the targetSdkVersion or minSdkVersion attribute is set to "11" or higher. If you don't want the action bar for an activity, set the activity theme to Theme.Holo.NoActionBar.

onClick launches Activity incorrectly (in 2.3.6)

I'm working on an interface that provides a set of multiple Button objects, each of which has attached the same OnClickListener. When said Buttons are clicked, they should launch an Activity, as specified in onClick.
Here is my code for reference:
public class Calcs extends SherlockFragment {
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
// ...
CalcLoader buttonListener = new CalcLoader(getActivity());
LinearLayout buttons = (LinearLayout) v.findViewById(R.id.calculatorlist); // v is the inflated View
for (int i = 0; i < buttons.getChildCount(); i++) {
View b = buttons.getChildAt(i);
if (b instanceof Button) {
((Button) b).setOnClickListener(buttonListener);
}
}
// Test Code: Location 1
Intent i = new Intent(getActivity(), MyCalcActivity.class);
getActivity().startActivity(i);
// ...
}
private class CalcLoader implements OnClickListener {
private Activity mOwner;
public CalcLoader(Activity owner) {
mOwner = owner;
// Test Code: Location 2
Intent i = new Intent(mOwner, MyCalcActivity.class);
mOwner.startActivity(i);
}
public void onClick(View v) {
if (v instanceof Button) {
// Actual Code: Location 3
Intent i = new Intent(mOwner, MyCalcActivity.class);
mOwner.startActivity(i);
}
}
}
}
Despite this, however, I'm getting some odd behavior. In the above code, I've placed some startActivity tests, labelled locations 1 and 2. In both cases, the Activity launches correctly, and all is well!
However, at location 3, where the working code should execute, I get some strange behavior from the launched Activity:
At first, the Activity is launched just fine. It displays a single text field and it is focused, with the soft keyboard coming up. This is correct.
Now, when I click the back button, the keyboard closes. This is correct.
Click back again, and the field loses focus. This should NOT happen. Instead, the Activity SHOULD close and return to the previous one.
Click back again, and the entire app closes (instead of returning to the previous Activity). Obviously, this should NOT happen.
To reiterate, when the Activity is started from location 1 or 2, everything functions correctly; the back stack is correct and returns to the initial Activity properly.
What is going wrong here? Why, when I start my Activity from onClick, does it fail, while it works from any other location?
Update: Saving the Intent in the constructor and reusing it in the onClick method produces the same glitched result, as does starting the Activity from the UI thread.
Second update: Making the text field unfocusable had no effect on the glitch; the back button still closed the app. Additionally, running in the 2.3.3 emulator had the same result. Oddly, though, after the second back button press (the text field losing focus), if you wait ~3 seconds, the Activity closes and returns to the main one.
Third update: No key events (onKeyDown or onBackPressed) are fired for the back button that takes focus from the text field. Additionally, if you interact with the Activity after the text field loses focus, it shows the animation of loading a new Activity of the same type, but the glitch is present here as well.
This appears to be an OS-level issue, found in Android 2.2 (API 8), 2.3.1 (API 9), and 2.3.3 (API 10). Eclair (API 7), and APIs 11+ do not have this issue. At this point, I believe I'm looking for some kind of workaround...

Turns out my issue was not caused by something I detailed in my original post, so I apologize for that.
The issue was caused by a SurfaceView item on a tab unrelated to the tab I was testing on. After rebuilding the tabs and layouts from the ground up (and building each time), I discovered the lag-back-glitch was only caused when a SurfaceView was present in a non-focused tab.
I finally found that I was not the only one with this issue.
To solve:
Created an onPause method in the main Activity. In here, I destroy the SurfaceView using container.removeView(..);.
Created an onResume method in the main Activity. In here, I inflate the SurfaceView from a new XML file containing ONLY the SurfaceView item, and add it to the original container.
Lastly, implemented a android.view.SurfaceHolder.Callback in the SurfaceView to erase the contents of the surface before it is removed.
It stumps me that this happens only on APIs 8-10, but I'm glad it's solved now. Kudos to everyone that offered their assistance!