I have various pieces of generated HTML/JS that I load into Activity with WebView#loadDataWithBaseURL. Is there a way to not load in again and again during Activity lifecycle? For example - user goes to check the message and then calls the app again. At that point - the Activity is stopped and probably destroyed, when it's loaded again I do not want to hiccup on loading the content user was already viewing.
For example - user goes to check the
message and then calls the app again.
At that point - the Activity is
stopped and probably destroyed
If the user directly visited the Notification, or clicked HOME, your activity is stopped but not destroyed. In these cases, your WebView should not change content unless you change it.
Your activity will be destroyed if the user presses BACK, or Android needs to close you out because of memory constraints.
In the BACK case, the user is expressly telling you to go away, so reloading your data seems reasonable.
In the memory-constraint way, by definition the device is short on memory, so you're going to need to reload the data if and when you are brought back to the foreground.
When i click HOME, and later i restart my app, the content of WebView retained.
But when i trigger a Intent(such as barcode scanner), after the Intent finished and come back to my app, the WebView in my app was reloaded.
Could i keep my WebView content when the Intent returned?
Related
I have an application with a lot of activities. Among them there is InitialActivity which loads the core data. It's a launcher activity and none of the next activities can live without the loaded data.
So I launch the app, the InitialActivity is loading data, then navigates to the MainActivity and then I'm browsing to some FarAwayActivity. Then I'm switching to other apps (some of them are heavy games) and my application is getting killed on the background. I've inserted log call in my Application.onCreate() and I can see that it's called again, when I switch back to my application. So I'm sure that the app is killed on the background. But Android brings the very last FarAwayActivity to top and it crashes immediately because all the loaded data are nulls.
So the question is: how can I tell the application to start over from the InitialActivity when (and only when) it's getting killed and restored? Something like "forget my back stack", but presumably automatically, in the manifest.
I've already read and tried everything from Activity tag docs, but nothing matches my expectations. The closest thing is android:clearTaskOnLaunch="true", but it clears all other activities on the stack when relaunching app from desktop (and app isn't killed yet, so all the data are available). To be clear, I want to start with InitialActivity only after the app was actually killed.
First I would suggest you to instead of storing it in the Application, you could pass your data to your Activity through Intent.
This way when the Activity get restored, the saved Intent will bring its data back.
Now to a suggestion to your actual question:
When your Activity gets restored, you will check if your data in the Application object is null
if they are you should call this:
Intent newIntent = new Intent(FarAwayActivity.this, InitialActivity.class);
newIntent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
newIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(newIntent);
Now it should clear the stack till find InitialActivity.
I have an app, a single activity app with fragments in it.
The usual use case for this app is, that you start it and put the phone away and every now and then, you get back to the phone and insert some data... It's a logging app, you are doing something and insert your results into the app...
I have the problem, that every now and then, my activity get's destroyed and is recreated with an empty bundle... (Most of the time this is not the case, but every now and then this happens...). My app sometimes starts a service, even this service is killed in this case...
This means, that the system has killed my app, does it? How can I avoid this?
I need to keep the user data and the current top fragments... And they are saved to the bundle and everything works as long as their states and the data get saved...
Btw., my activity is always the TOP ACTIVITY, only that the screen turns off often... I just want to keep my activity alive as long as possible until the user leaves it with the back button... Or to save the state reliably
IMPORTANT NOTE
onSaveInstance does not always work (it's not part of the lifecycle and therefore not guaranteed to be called)... it only works most of the time... I need a way to that works always... If android kills my app...
don't keep your app in memory
You don't want to block Android from killing your app. What you want is to restore your app's state properly. Then the user will never notice the app has been destroyed and the user still gets the benefit of an app that was destroyed when not in use.
If you really want this use a wakelock. This will drain your users battery so I think twice before implementing this... Info at How do I prevent an Android device from going to sleep programmatically?
onSaveInstanceState explained
To do so check what information is needed in the bundle and persist that information with the onSaveInstanceState(bundle:Bundle) method so you can reuse it in onCreate(sameBundle:Bundle).
More information available from Google documentation at Save your Activity state and Restore your Activity State.
About Android Activity lifecycle
As stated by #prom85 in the comments below it's not guaranteed that the onSaveInstanceState method will be called because it's not part of the lifecycle. Workaround for this is using the onPause lifecycle hook to ensure your data is stored.
More information at Android: onSaveInstanceState not being called from activity
I had a similar problem, I arrived at this post while searching for a solution, you have to play with the manifest to achieve this and also understand what exactly activity is, in Android eco system,
In Android activity is a task which has a pre defined work.
I dig a lot in the documentation, I found that, we can configure activity in two ways,
Persistent
non persistent
if you mention for the activity in the manifest as
android:persistent="true"
and run the below use case
Start the APP
Press back or home button
you select the activity in the back stack again to bring it to front
Activity enters start -> pause -> stop - > resume , it does not get into onDestroy method.
if do not mention
android:persistent="true"
for the same use case
Activity enters start -> pause -> stop -> destroy, and if you select the activity from the back stack
Activity enters resume->create->start
If you want to run a service/task on activity start which keeps running when the app is in back stack, then you have to start that in the onCreate method, and kill them onDestroy by specifying your activity as persistent in manifest.
I hope my above solution might help others who arrive here for the same problem
I am developing a game for Android and have what I imagine to be a very common scenario, but I can't figure out how to do it.
I have a Title Screen where the user can select "New Game". When they start up a game, I push a GameActivity onto the stack. Then if the user hits the physical back button the phone, the application goes back to the TitleActivity, as I intend it. However, I need a way to allow the user to resume the game at this point, but I don't know how to get back to htat instance of the GameActivity. Any help is appreciated.
You can't guarantee that you will get back to that instance of GameActivity you need to save the game state somehow, and make your GameActivity able to resume from that saved state.
Make sure you understand the Activity lifecycle. The instance of your activity can be killed at any time when it isn't visible, so you need to save state at the proper point (onSaveInstanceState).
The answer I would give is: don't do this.
Finishing an activity (which is what happens by default when you press back) does finish that activity. You don't return to it.
If you want to allow the user to press back to pause your game into a menu, capture the back key with onBackPressed(), and instead of allowing the default behavior of finishing the activity, simply show your menu in-place in that activity. Generally I think for games making the core game UI be one activity that is the base activity launched for the app makes more sense than trying to split it into activities. Games are just special that way.
I'm not talking about restoring application state (using Bundle or configuration change or even SharedPreferences) i'm talking about the fact that i have a certain task, that is a base activity: HomeScreenActivity and from there i can have a series of activities opened for the user's flow.
I want in case of application's death or user killed his own session to restore the whole task, not just one activity, i mean to restore the whole activity stack i had before the application was killed. if the user was in my billing screen and left off my app i want to take him back to that screen, but i want that if he'll press back he'll go back to my search screen or filtering screen, whatever was there before he left off.
I have no problem saving the activity's order in sharedPreferences and know the order once i start my home screen, but i wonder if there's a way to tel landroid to start an activity, which sould only enter the task's stack and not call the activity's onCreate method unless i actually get to it(with back key).
Perhaps someone will have a better idea, but the only thing that comes immediately to mind is to add a "resetup" flag so that you could sort of replay a script of the user's previous activity navigation actions within your app, having your activities start each other up in turn but due to the resetup flag bypassing most of their code so they don't really do anything except essential setup and start the next one.
One complication is that it's probably the activity they were actually in which android will resume.
if you have an android app that has more than one Activity, and Activity A starts B, so if Activity b crashes the process is killed but is revived by android OS and starts Activity A again instead of just shutting down the app, why ?
You're complaining that Android will attempt to recover your app's state gracefully after a crash? ;)
This is the result of Android's resource management and the Activity lifecycle at work. Keep in mind that a single task can be composed of a number of Activities that may span several processes or apps. As outlined here: http://android-developers.blogspot.com/2010/04/multitasking-android-way.html Android processes don't shut down "cleanly" in the traditional *nix process sense. Your app's components receive lifecycle events but after a certain point the app can be killed without further warning so that the system may reclaim its resources.
For example, a user might be browsing the web, click a youtube link launching the youtube app, then click a share button to launch their favorite social networking app and post the video link. This is all part of the same task; if the user presses back several times they'll come back to the page in the browser that they started from.
Once you start up the social networking app, the system might decide that it's running low on memory and it's going to kill off the browser's process to free up more. (After all, it's not in front and the user won't notice.) When the user presses the back button to return to the browser Activity it gets restarted and reconstructs the last state where the user left it. At worst the user experiences a short delay while things reinitialize.
But this same sequence of events restoring a previous Activity state can happen even within the same app in the same process. In your scenario, Activity B closed as the result of the crash. So the system does exactly what it always does - it returns to the previous Activity: Activity A. But Activity A's process isn't still around (it crashed!) so the system restarts it and it can reconstruct its previous state.