Mix of questions about Android activity/intent behaviour - java

Can an activity send itself an intent ?
Can an activity A send a "start" intent to start another activity B (onCreate() of B invoked) and B send again another start intent to A to make it appear again (instead of using finish()) ?
Is there another intent to make A appear again on foreground ?
If A has launched services with Java threads is there a risk that those threads are stopped/killed when another activity is started by A ?
Regards,
Apple92

Can an activity send itself an intent ? sort of. your next question is basically what I was going to tell you.
Can an activity A send a "start" intent to start another activity B (onCreate() of B invoked) and B send again another start intent to A to make it appear again (instead of using finish()) ? yes, by using a combination of lifecycles (see onPause() and onResume() methods) and startActivityForResult and onActivityResult(..)
Is there another intent to make A appear again on foreground ? what? you can whenever you want. You don't have to call finish() after you startActivity
If A has launched services with Java threads is there a risk that those threads are stopped/killed when another activity is started by A ? No. Only if Activity A is destroyed will that risk come up, and even then it is determined by how you start threads (a thread in a service will not be killed when its calling activity is killed)

Related

Why should we call finish() method after sending an intent?

I just came across this code in
Intent wizard = new Intent();
wizard.setClass(this, A.class);
wizard.putExtra("Domain", A.getInstance().B);
startActivity(wizard);
finish();
Why should we call finish() method here?
What's it purpose?
finish() Call this when your activity is done and should be closed, when starting an activity calling finish() will close the current activity and it will not be available in the Activity Stack.
finish();
finish is used for closing current activity.It is like you are sending data to other activity/Opening new activity and closing your current activity.
You are not imperative forced to do that...
normally people do that if and only if the want to destroy the activity that is starting the intent, but that must no be your case...
in the life cycle of android you will see:
assuming you activity is visible, then calling finish() method will call
onPause(), then onStop() and finally the onDestroy()
Let's understand it using few quotes
finish - Call this when your activity is done and should be closed. The ActivityResult is propagated back to whoever launched you
via onActivityResult()
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.
when you call finish() on an activity, the methods followed by onDestroy() is executed.. eg: onPause()> onStop() > and onDestroy()they can be differ from the place you call finish()!
onDestroy() is meant for final cleanup - freeing up resources that you can on your own,closing open connections,readers,writers,etc. If you don't override it, the system does what it has to.
It inform the system that you want to finish the selected Activity so it wil call onDestroy() after you finish the activity.(but this does not mean that onDestroy() only gets called by finish(),system can do that when it's running out of resources after the activity is sent to the back state)
Also there are more interesting questions like Activity.finish() called but activity stays loaded in memory that you might like

Is there a way to restart the application instead of having it restart the last activity after a crash?

Since I store certain information that is necessary in my Application class, when a user encounters a crash, sometimes they encounter two crashes since the last activity needs information stored in the application class.
Activity A >> Activity B (needs info from Application class) >> Activity C
Crash occurs on C >> Application tries to open Activity B >> Crash occurs on B because it needs info from the Application class (this has been reset)
I want to avoid this, so I was hoping that there is someway I can restart the whole application after a crash instead of the activity.
This is one possible solution of many but I'll put it here as an option:
You could use startActivityForResult() and when you handle the error in Activity C, finish() it with a result code that you recognize as a crash and handle things appropriately in the onActivityResult() of Activity B.
Getting a Result from an Activity
The nicest solution is to handle the case in which you do not have the necessary information at any activity (in your case Activity B).
You should check at the onCreate method whether you have the information or not, and act in consecuence:
Finishing the activity to go back to your activity A
Launching another activity
Asking the user for feedback
Any other action you think fits best
There may be more than one reason explaining why you don't have that information (as other answers point out), so in my opinion the best option is to handle the case.
Untested theory, just spitballing.
Could you attach yourself as a default exception handler, and start calling finish() on the open activities? If you can finish all your activities, wouldn't that effectively shut down the app, and reopening it would be as if it were getting launched fresh?
You shouldn't keep any state in the Application object. Keep it in the Bundle you receive in the onCreate(). Eventually use onSaveInstanceState / onRestoreInstanceState to save/restore state.

Monitoring an Activity started with startActivity()

I use startActivity() to begin a new Activity within my application and would like to find a way to either poll for or be notified when the started Activity exits. Is this possible?
Clarification:
The Intent passed into startActivity will be using ACTION_VIEW.
startActivityForResult() is the method you want to use.
After your Activity completes a callback will be made to the calling Activity for onActivityResult(), where you can then process the returned data from the closed Activity.
The documentation for Activity details pretty well how you can do this.

Pass current activity to a service so that the service can manipulate the view

What I want to be able to do is toggle the visibility of an element in my activity FROM a service.
How can I pass the current activity to my service class in order to send back messages/call functions in my activity?
What happens if the user exits the app and the service is still running, but obviously without a running activity to call functions within?
Thank you.
I don't think it's a good idea. Here's a good answer about notifying an activity from a service: Notify activity from service.
To answer your first question, you wouldn't be doing anything to the UI from your service. You have a few options for communicating between an activity and a service. You can set up a BroadcastReceiver. You can bind the service to your activity and use Android's AIDL to set up handlers for the communication. Plus others.
To answer your second question - make sure to stop your service in your onDestroy method. Alternately, if you've bound the service to an activity, the service will stop once the final activity that the service is bound to stops.

best practice where to register broadcast receiver?

quick opinion question on where its 'best' to register a receiver? In my case my service sends a broadcast each time the UI needs updating.
Options as i understand them
. Manifest
. Oncreate
. Onstart
. Onresume
With the corresponding unregister of course.
I think for a UI update scenario makes sense to put in onresume and onpause... your thoughts?
If the receiver is only to receive events that would cause you to update the GUI then there are two options. Register to receive them in OnResume and unregister in OnPause if you want it to only update when the activity is in the foreground. OR between onStart and onStop if you want to update when the activity is even partially visible (i.e. a modal screen is partially blocking the activity). See here about 2 pages down. Look for "There are three key loops you may be interested in monitoring within your activity:"

Categories