I have a simple navigation flow:
Screen A -> Screen B
After I do some work in Screen A, I navigate to Screen B, and do some work there. Then I remember I forgot to finish a task in Screen A, and I press the system back button and it takes me back to A. I can see all the local states are preserved/remembered (texts in textfield, counts, etc). As I finish my task, I want to return to Screen B, but it is already popped off of the stack. So I manually navigate to Screen B, and with no surprises, the local states are gone.
My goal is, as I can navigate backwards easily, I want to navigate forward in same manner (states preserved). Any help will be appreciated. Thanks.
Navigation isn't really designed to work like that, but you can work around it by manually saving the states yourself. You can save specific data in onSaveInstanceState() and restore it in onRestoreInstanceState(), however there are some cases when onRestoreInstanceState() isn't called when the activity is destroyed.
You're probably better of manually saving your state in SharedPreferences in onPause(), and restore them in onCreate()
Related
Hello I currently have an Activity A with a fragment inside that the user can interact with, the goal here is to simply "background" Activity A and fragment and allow the user to use the rest of the app normally with a floating button that when pressed the user will be taken back to Activity A and the UI will be restored the same as the user left it. I've looked into onSaveInstanceState but that only applies to when the system ends it or when screen rotation happens and not when the user presses the back button. So is it possible to save Activity A with the same UI and restore it at any given time?
Edit: I also have no way of accessing/modifying the fragment's components since it's coming from an SDK already.
I am Working on Device lock Application . for that I need to maintain my Lock activity's state on any action.
You could use the lifecycle aware components like viewmodel that stay around even after view has been destroyded and recreated check out their patterns here
I am calling Activity2 from Activity1 through intent and on pressing back button I want my activity2 not to get destroyed and go back to Activity1 and again from activity1 want to start activity2.
I have tried to override the back button but then by using moveTaskToBack(true)
is taking me back to my phones home screen but i want to come back to previous activity.
Activities (and Fragments) are designed to destroy when onBackPressed is called. Since the user has no intention to proceed interaction with the screen anymore.
I think the best approach of your navigation should be use of Fragments with manually handled navigation. When Activity starts initialize both Fragments. When you'll need to open second screen, just replace current fragment with Fragment2. When onBackPressed is called - replace Fragment2 with Fragment1. In this case both fragments are always available to be shown.
One thing to be aware of - state saving, since the system can destroy your app in the background anyway. In this case, save state manually when Activity is being destroyed.
I've got an app with two screens, we can call them List and Details.
If an user is at Details and presses Home to minimize the app and then switches back I want to stay in the view and just restore, but if he presses Back I want to go back to List, I figure I can save a "Done"-button this way. But...what's the proper way to do this?
Currently I've overriden onPause and onSaveInstance but it seems they're both called in both cases.
I'm thinking about overriding onKeyDown instead, like he did; How to control Activity flow - Back button versus Home button, but that doesn't seem like a "nice" way to do it so I thought I'd check if anybody else has another idea.
Make two activities, for list and for details. When you will press the back key in the details activity it will finish and will show up the list activity.
I am implementing a dashboard plus action bar UI, like in the Twitter app:
Each button on the dashboard takes the user to a different activity. A few of these activities are more important than the others, and I could imagine the user switching between them via the dashboard reasonably often.
I feel like I have two options:
Keep an activity cycle going using intent flags, so that when the user goes back to the dashboard it just pushes the dashboard activity to the top of the stack. Then when the user returns to another activity, it pushes that one to the top of the stack. No activity would be destroyed until the OS does it to gain back memory, which would be fine.
Let the activities be destroyed when the user goes back to the dashboard, then recreated later.
Which option is better in terms of performance and best practices? I like option 1 but am not sure if I'm abusing the purpose of those intent flags. And if I do go with option 1, should I also override what the back button does so that finish() isn't called?
Personally I like the first option better. This way, you would easily remember the state of the other activities when the user returns to them.
For example, if in a child activity the user scrolls some list, then goes back to the dashboard, and then returns back to the child activity, the scroll position will be where he left it off.
Regarding memory, I don't think it's an issue. Let's take a tab component for example (which is a parallel navigation controller to your dashboard). With a tab control, all the child activities (the tab activities) are never destroyed as well.
If memory does become an issue, I would combine your two ideas. For the less important activities I would implement approach 2 (destroy them on back), and for the more important activities (where state is important for the user for example), I would implement approach 1.