I'm trying to start an activity (Act2) from another activity(Act1), and it doesn't happen like it should.
In the debugger, I can see that as a result of calling startActivity() the method onCreate() of act2 is called 3 times (!!...), no error shows, or exception caught, and unfortunatly the desired UI doesn't show.
for trying to understand better where is the problem, I run the next 2 tests that showed expected normal behavior:
when I modify Act1 to start Act3 (instead of Act2, just for
understanding if its a problemof Act1), then act3 shows its UI as expected.
when Act4 start Act2, it runs as expected, and show the UI on the screen.
As to the code, I start the activity in the common way of:
Intent intent = new Intent(Act1.this, Act2.class);
startActivity(intent);
Anyone faced such thing?
Thanks.
You might want to read through the documentation on the Activity lifecycle.
OnCreate will only be called one time for each lifetime of the Activity. However, there are a number of situations that can cause your activity to be killed and brought back to life. Thus, onCreate will be called again.
To support this properly, you can save state information in onSaveInstanceState and restore it fron the state bundle you get in on create.
Related
I have recently started working with android. So I am in the initial stages of learning.
The question is: when we call startActivty(Intent) in the middle of execution of another activity.I actually thought that startActivity() will simply jump into the activity called. Isn't it the case? does it simply stacks the call to the activity?
I am getting this doubt bcoz..I actually have a program in which Activity A has a loop. Some where in the middle of loop Activity B is called. I want activity A to resume with the loop only when activity B finishes. I have made a call in A's loop like this:
in = new Intent(this,MyChoiceActivity.class);
in.putExtra("McObj", mc);
startActivity(in);
finish();
So What happens is Activity A calls B, but B is not entered, A simply resumes the loop and again calls B, simply the calls to B are stacked and once the loop in A completes, one by one calls to B in stack are executed so finally the first call to B is executed last(last in first out)...But I dont want the order to change...If A calls B, it should simply go and execute B and only then come to the loop..what should I do to accomplish this?
Your activity can be busy and just 'be there'. If you start a new activity while your activity is really doing something, it will not 'wait' until the other activity is finished: both can be around at the same time.
If it would do this, it would have you end up with a lot of busy-waiting processes, so luckily this is not what happens.
See the activity lifecycle to find out more about what an activity is (it is not just another class as you are using it now, it starts a separate thing that hangs around next to (not instead of / on top of) your current activity).
Instead, beacuse these things go rather asynchronous, you might want to use a different approach: use an ActivityForResult, and start a new one when you get that result.
I'm talking about programming in android.
In early days I thought that, finish() closes current activity and go back to the previous in Activity stack, and System.exit(0) closes the whole application.
But I was wrong.
I made a small experiment and understood that Both will finish only the current Activity.
The only differences that I could notice is that, in Android 2.3.3
The ActivityResult is propagated back to onActivityResult() using finish(). Whereas onActivityResult() not called for System.exit(0).
But in Android 4.2.2, onActivityResult() is called for both! and Intent was null for exit().
(I tested only in these 2 devices)
There is a time lag when using exit() whereas finish() is faster.(seems like more background operations are there in exit())
So,
what's the difference between two?
In which situations, I can use exit()?
I believe there is something more that I'm missing in between the two methods.
Hope somebody can Explain more and correct me.
Thanks
EDIT UPON REQUEST:
Make an Android application with 2 Activities. Call second Activity from Launcher activity using Intent. Now, inside the second activity, upon a button click, call System.exit(0);.
"The VM stops further execution and program will exit."????(according to documentation)
I see first activity there. Why?
(You are welcome to prove that I'm wrong/ I was right)
Actually there is no difference if you have only one activity. However, if you have several activities on the stack, then:
finish() - finishes the activity where it is called from and you see the previous activity.
System.exit(0) - restarts the app with one fewer activity on the stack. So, if you called ActivityB from ActivityA, and System.exit(0) is called in ActivityB, then the application will be killed and started immediately with only one activity ActivityA
According to android Developer -
finish()
Call this when your activity is done and should be closed. The
ActivityResult is propagated back to whoever launched you via
onActivityResult().
System.exit(0)
The VM stops further execution and program will exit.
According to the documentation, The program will exit.
But it seems a bug in the documentation. In case of a java program, it is correct. But coming to Android, You will see the previous Activity from the stack.
Since Android coding is done using java coding, most of the documentation is same as those for java.
From documentation,
System.exit(0)
The VM stops further execution and program will exit.
For Android aspect, we have to replace the word 'program' with something else. May be Activity or Context.
Sa Qada answer is correct after my testing.
finish will close this activity and back to prevous.
but exit will close current activity too and empty all the activity in freeze and start again the previous activity
Actually there is no difference if you have only one activity.
However, if you have several activities on the stack, then:
finish() - finishes the activity where it is called from and you see
the previous activity. System.exit(0) - restarts the app with one
fewer activity on the stack. So, if you called ActivityB from
ActivityA, and System.exit(0) is called in ActivityB, then the
application will be killed and started immediately with only one
activity ActivityA
I have an activity that sends a BC and waits 5 seconds for the response using AlarmManager.
Once i get the broadcast i:
1. remove the FragmentDialog using mDialog.dismiss();
2. start a new activity using getActivity().startActivity(myIntent);
I'm inside a Fragment (using TabFragment from the support library and MyTabActivity which i created).
The thing is i constantly getting balck screen and ANR, if i remove the line startActivity()
I'm not getting the ANR, the fragment does gets dismissed, but my activity doesn't show, i get the black screen and if i press it, ANR.
What i thought about is that the fragment manager started out working on the activity and then i started a new one that fucks up android, since i'm basing myself on fragment i really don't know how to get out of this mess, thought of using handler in the activity to post my activity start in 300 millis, this is a very very ugly solution.
Any nice ideas ?
the problem seems to be that i unbding a service twice in onStop of the activity due to the fact that once i call unbind ServiceDisconnected is NOT called and changes the state of my activity to unbonded (state i follow).
since onStop is never eding the original activity gets the UIthrehad and make the whole app stuck...
I'm trying to kill 2 activities on the onclick of a button. The current activity and the previous activity. Using their pids. I'm just able to kill one activity. Why does this happen?
public void onClick(View v) {
android.os.Process.killProcess(pidofmain);
android.os.Process.killProcess(android.os.Process.myPid());
}
If I see in my logcat, The activity with pid "pidofmain" is getting killed whereas the current activity is not getting killed.
"pidofmain" is an integer i received from the previous activity using an intent.
Leave process killing to the OS. This is bad for any kind of program in a timesharing OS. If you want to conserve memory or something like that, let the OS handle it.
Also you can't really know if the process was correctly killed because well, if it is you wouldn't know, and if it doesn't you were not supposed to do it.
What do you want to do this for?
A much better way to do this is to call finish() for the current activity. You can also signal the previous activity to finish if it calls the current activity using startActivityForResult(Intent). The current activity would call setResult(int) before calling finish() to send a return code back to the previous activity. The previous activity can test the return code in onActivityResult(int, int, Intent) and also call finish() based on the result code.
Killing processes should be left to the OS. Once the activities finish, the will kill it off if it needs the resources. Otherwise it can let it around, which might help speed up a relaunch of your app if the user wants to run it again.
This isn't a definitive answer, but more like some thoughts that I have but it's too late for my to fire up Eclipse and prototype them. If it doesn't help you let me know and I'll try to look into it deeper tomorrow night.
A few thoughts (I hope they help):
1) Android apps really are single-threaded, and your main activity controls all the dispatch events (including events to what I assume to be a second thread that you created). If you kill the main activity, I'm pretty sure that your application would terminate execution immediately following your first call to android.os.Process.killProcess(pidofmain), and you'd never make it to your second call because you would have killed your entire application. Again, this is assuming by the variable name pidofmain that you are killing the main UI thread and not just an activity called main.
2) I'm a little curious also about where you got pidofmain? It sounds like you have three activities total, and in the first activity you get it's process id and send it to the second activity in an intent bundle, which also gets passed along to a third activity (which is the place where you're trying to kill this whole thing)? If that is the case, and you're trying to kill the currently running activity, the table in the documentation here leads me to believe that you can't just kill an activity that's in the resumed state using the same method. Official Android Docs for Activity You might want to try calling the finish() method for your currently running activity.
What exactly do you see in logcat? And what happens in the UI? Does the visible activity continue to run, but the other activity has been removed from the backstack?
1. theNewIntent = new Intent(parentActivity,NewScreen.class);
2. parentActivity.startActivity(theNewIntent);
3. Log.d(TAG,"RETURNED BACK TO HOME VIEW");
Here i creates a new intent and starts a new activity. I want my current activity to be on hold until i finish the newly created activity. What i want is not to execute line 3 until "NewScreen" activity is finished.
Can anyone suggest me to do this.
You cant really achieve this without some kind of synchronization. The easiest thing to do would be to call startActivityForResult() and put your log message in onActivityResult(...). This would give you the synchronicity but would still kind of break your flow over 2 methods. The issue is that startActivity() is a non blocking call.
Your current activity will be on hold in the sense that it wont get any user feedback until the activity on top of it is cancelled.