I have a Fragments which save user data in their onSaveInstanceState method.
I need to get this data when the user finishes the activity and display it in the next intent.
Currently the sequence of my implementation is:
user hits the close button
computation starts relying of data stored in prev calls of onSaveInstanceState, then start new intent
onSaveInstanceState of current fragments get called, information is missed in calculation
new Activity displays
old Activitys onDestroy is called
I thought about starting my calculation and the new activity in onDestroy. Then I need a mechanism to destroy the current Activity.
Or I could somehow call all remaining onSaveInstanceState method calls in the current thread before doing the calculation.
What would be better or is there a better way?
This sounds like a strange design to me for android. For this use case I would do:
user presses abitratry button (in your case close)
click listener gets the needed data (the same way you would get them in onSaveInstanceState)
start an asynctask if lengthly operation and show progress bar or make computation on UI thread if trivial
start intent with computation result for new activity
I have a Fragments which save user data in their onSaveInstanceState method. I need to get this data when the user finishes the activity and display it in the next intent.
Is there any reason you need the data specially from onSaveInstanceState() method?
thought about starting my calculation and the new activity in onDestroy. Then I need a mechanism to destroy the current Activity.
If you call something in onDestroy() there is no need to forcefully destroy the activity since its already in progress. (btw. finish() would do it). Appart from that, onDestroy should do clean up procedures e.g. free resources or close streams, not for calling new activities
Related
Whenever a new Activity is created onCreate is called. Followed by onStart. And onStart is called again when activity is back on to the screen. I know this fundamentals. But, what is the actual difference between when you launch the activity.
I mean to say, when you click on some object on current activity, you start a new activity by startActivity() method with an intent of new activity. Now onCreate() will be called of the second activity and then the onStart(). When will be the activity visible to the user? After onCreate or after onStart? If it is visible after onCreate and before onStart, and I do some of the operations in onStart(), then it will reduce the lag between the user clicking on an object and the screen popping up on screen.
If I move some of the data bindings to onStart will it interfere with the default Activity transitions on lollipop and above (I am not sure about this)?
Is it a good idea to move some of the code to onStart to reduce a lag between click and new activity shown on user's screen? If yes, what kind of code can be safely moved to onStart? Like data bindings, database queries, etc. ?
Any guidance will be much appreciated.
Short question: Is it possible to save data using onSaveInstanceState() method, then call finish() on Activity and upon next start of the Activity to get the data back in savedInstanceState? Or does finish() of an Activity mean the data are gone?
If first answer is correct, I have some problem in my implementation because I am getting null in onCreate() although the data was saved. If second answer is correct, I will have to re-think how I connect my Activities together :o)
Is it possible to save data using onSaveInstanceState() method, then call finish() on Activity and upon next start of the Activity to get the data back in savedInstanceState?
No.
Or does finish() of an Activity mean the data are gone?
Yes. The saved instance state Bundle is for cases where, from the user's perspective, your activity is still around, but it is being destroyed for technical reasons:
Configuration changes (e.g., screen rotation)
Process termination (with the user returning to your app fairly quickly)
If finish() is called for other reasons — you calling it directly, user presses BACK, etc. — then the saved instance state is no longer needed and can be discarded.
As a result, the saved instance state Bundle is for transient data that you would like to retain but are comfortable with losing in the face of configuration changes and process termination, such as the contents of a partially-filled-in form.
If I have a method called onStop and it calls super.onStop();. When does this method run?
In my main activity, I start another activity as follows: startActivity(new Intent(this, MyNewActivity.class));. Does this automatically stop my main activity and call onStop?
Also, what kind of things should I do in the onStop method of my main activity. So far all I have done is unregister listeners to free up space but other than that is there anything else I should do?
Thank you, any help is greatly appreciated.
When does this method run?
This method calls when your Activity is no longer visible to the user
Does this automatically stop my main activity and call onStop
Yes when you start another Activity first onPause() function get called and then onStop().
what kind of things should I do in the onStop method of my main activity
It depends on your implemenetation and your needs but persisting data recommended to implement on onPause() callback function
In my main activity, I start another activity as follows: startActivity(new Intent(this, MyNewActivity.class)); Does this automatically stop my main activity and call onStop?
You can know yourself what happens when you call new activity takes focus just put a simple log statement and check yourself.
http://developer.android.com/guide/components/tasks-and-back-stack.html
Quoting from the docs
When the current activity starts another, the new activity is pushed on the top of the stack and takes focus.
The previous activity remains in the stack, but is stopped. When an activity stops, the system retains the current state of its user interface. When the user presses the Back button, the current activity is popped from the top of the stack (the activity is destroyed) and the previous activity resumes (the previous state of its UI is restored).
onStop()
Called when the activity is no longer visible to the user, because another activity has been resumed and is covering this one. This may happen either because a new activity is being started, an existing one is being brought in front of this one, or this one is being destroyed.
Followed by either onRestart() if this activity is coming back to interact with the user, or onDestroy() if this activity is going away.
Check the topic saving activity state
http://developer.android.com/guide/components/tasks-and-back-stack.html#ActivityState
Note: When the system stops one of your activities (such as when a new activity starts or the task moves to the background), the system might destroy that activity completely if it needs to recover system memory. When this happens, information about the activity state is lost. I believe this happens on priority basis.
If you need to store persistent data do it in onPause
For more info check the activity lifecycle
http://developer.android.com/reference/android/app/Activity.html
In my app, In an special situation I need to start an Activity and put it behind the current showing Activity, I mean if the current Activity, which is being shown by the user was closed, the user now can see the Activity which I just started. how to do that?
You cannot do this.
Activities will always start right away. You cannot manipulate the back stack in the way you want.
You would have to detect the activity closing and then start your new activity then.
You can implement your case by using onDestroy ()
Perform any final cleanup before an activity is destroyed. This can happen either because the activity is finishing (someone called finish() on it, or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method.
Note: do not count on this method being called as a place for saving data! For example, if an activity is editing data in a content provider, those edits should be committed in either onPause() or onSaveInstanceState(Bundle), not here. This method is usually implemented to free resources like threads that are associated with an activity, so that a destroyed activity does not leave such things around while the rest of its application is still running. There are situations where the system will simply kill the activity's hosting process without calling this method (or any others) in it, so it should not be used to do things that are intended to remain around after the process goes away.
Derived classes must call through to the super class's implementation of this method. If they do not, an exception will be thrown.
Source : http://developer.android.com
This may be a bit of a stupid question but when is the best part of the Android life cycle to implement each step? The flow of my game is as follows:
Before onCreate: Data that is stored in a JSON file is parsed into String Lists when the game starts
onCreate: Basic UI is generated
onStart/onResume: Game starts: item selected at random from the lists, user selects corresponding item to proceed
If the user is correct, another item is selected from the lists. Occurs 10 times
After 10 items, game ends and score is displayed to user
Would this be considered good practice? I'm a bit confused about the life cycle steps
This might help with understanding the lifecycle of an Android app more. The following is quoted from that site:
As mentioned in the previous section, the lifecycle of an activity has 4 states and 3
lifetime periods. If you want to monitor and adding your own code
logics to an activity, you can use the following 7 basic callback
methods provided by the android.app.Activity class:
onCreate() - Called when the activity is first created. This is where
you should do all of your normal static set up: create views, bind
data to lists, etc. This method also provides you with a Bundle
containing the activity's previously frozen state, if there was one.
onCreate() is always followed by onStart().
onRestart() - Called after
your activity has been stopped and prior to it being started again.
onRestart() is always followed by onStart().
onStart() - Called when
the activity is becoming visible to the user. onStart() is followed by
onResume() if the activity comes to the foreground, or onStop() if it
becomes hidden.
onResume() - Called when the activity will start
interacting with the user. At this point your activity is at the top
of the activity stack, with user input going to it. onResume() is
always followed by onPause().
onPause() - Called when the system is
about to start resuming a previous activity. This is typically used to
commit unsaved changes to persistent data, stop animations and other
things that may be consuming CPU, etc. Implementations of this method
must be very quick because the next activity will not be resumed until
this method returns. onPause() is followed by either onResume() if the
activity returns back to the front, or onStop() if it becomes
invisible to the user.
onStop() - Called when the activity is no
longer visible to the user, because another activity has been resumed
and is covering this one. This may happen either because a new
activity is being started, an existing one is being brought in front
of this one, or this one is being destroyed. onStop() is followed by
either onRestart() if this activity is coming back to interact with
the user, or onDestroy() if this activity is going away.
onDestroy() -
The final call you receive before your activity is destroyed. This can
happen either because the activity is finishing (someone called
finish() on it, or because the system is temporarily destroying this
instance of the activity to save space. You can distinguish between
these two scenarios with the isFinishing() method.
How are you pre-loading data before onCreate? You got no Context object to work with app filesystem before your onCreate called. Here is documentation for Activity lifecycle, as you can see, onCreate is the first method where you can run your code.
I suggest to put data loading in other thread, for example AsyncTask.
So:
Generate basic UI
Start data pre-loading NOT IN MAIN THREAD
Update UI after data loaded