I don't know what you are doing. If you try one of the sample apps like ApiDemos you will see this works fine.
On Tue, Dec 1, 2009 at 4:18 PM, Mark Wyszomierski <[email protected]> wrote: > Hi Dianne, > > The default behavior is what I'm going for - but I'm just not seeing > that - I made this small test app - it just has two activities. I > start the app from the app tray. Then have the first activity launch > the second activity. I hit the home button to put the app in the > background. When I hit the app icon from the app tray again, instead > of seeing the app resume from its paused state (the 2nd activity > should be showing?), the first activity is shown again: > > > > > package com.test.teststates; > > import android.app.Activity; > import android.content.Intent; > import android.os.Bundle; > import android.view.View; > import android.view.View.OnClickListener; > import android.widget.Button; > > public class ActivityMain extends Activity { > @Override > public void onCreate(Bundle savedInstanceState) { > super.onCreate(savedInstanceState); > setContentView(R.layout.main); > > Button btn = (Button)findViewById > (R.id.activity_main_btnLaunchActivity); > btn.setOnClickListener(new OnClickListener() { > public void onClick(View v) { > // launch the second activity from button click. > Intent intent = new Intent(); > intent.setClass(ActivityMain.this, > ActivityChild.class); > startActivity(intent); > } > }); > } > } > > > > > > package com.test.teststates; > > import android.app.Activity; > import android.os.Bundle; > > > public class ActivityChild extends Activity { > @Override > public void onCreate(Bundle savedInstanceState) { > super.onCreate(savedInstanceState); > setContentView(R.layout.activity_child); > } > } > > > > > > > <application android:icon="@drawable/icon" android:label="@string/ > app_name"> > > <activity android:name=".ActivityMain" > android:label="@string/app_name"> > <intent-filter> > <action android:name="android.intent.action.MAIN" /> > <category android:name="android.intent.category.LAUNCHER" / > > > </intent-filter> > </activity> > > <activity android:name=".ActivityChild" > android:label="@string/app_name"> > <intent-filter> > <action android:name="android.intent.action.VIEW" /> > <category android:name="android.intent.category.DEFAULT" / > > > </intent-filter> > </activity> > > </application> > > <uses-sdk android:minSdkVersion="3" /> > > > > > > > > > > > > > > > > > > On Dec 1, 5:09 pm, Dianne Hackborn <[email protected]> wrote: > > On Tue, Dec 1, 2009 at 1:46 PM, Mark Wyszomierski <[email protected]> > wrote: > > > I guess I'm not understanding the default process creation method. > > > > Fwiw, what we are talking about has absolutely nothing to do with > processes. > > Please make sure you read this starting at "Activities and Tasks": > http://dirkbd:9092/guide/topics/fundamentals.html > > > > Note that the interaction it describes as the normal behavior for tasks > is > > what you seem to be asking for. > > > > Using a new project, with two activities, A and B (both have no custom > > > > > flags set in the manifest, and Activity A is set as MAIN and > > > LAUNCHER): > > > > > 1) Launch the app from the app drawer > > > 2) Have activity A start activity B. > > > 3) Hit the home button. > > > 4) Go to the app drawer again, try launching the app again. > > > 5) Looks like a brand new process instance of the app is created, > > > instead of returning to the original process instance that's already > > > in the background. As a user, I'd (personally) rather just return to > > > the instance already running in the background, rather than create a > > > new instance. > > > > The normal behavior, if you don't do anything, is that in step 4 you will > > bring the current stack of the task from step 1 brought to the > foreground, > > in its current state. This is why most of the built-in apps behave this > > way. If they do something different, they are doing something special. > For > > example the settings app sets a flag on its root activity to always have > the > > task clear when it is launched. But that is not the normal behavior. > > > > So the question is: what are you doing that is different? All you have > > mentioned so far is using singleTask, which if used in certain in > > appropriate ways can cause this kind of thing (and other strange > behavior). > > So my first suggestion is to not use this. > > > > Given that I have no other information about what you are doing, I have > no > > other suggestions than to use the debugging tools I pointed out to try to > > see what your app is doing. > > > > > For my application, it doesn't make sense to open multiple instances > > > of the application. Like the Browser application, there should really > > > only be one instance, and anytime the user hits the Browser app icon, > > > they should just return to any running instance they have on the > > > system, rather than create a new one. > > > > Is your app being launched from other applications like the browser is? > If > > not, you are not like the browser, so please don't model your app after > it. > > The browser does a lot of special things because of things that are very > > special about it. It is a really bad model. (And in fact this behavior > > causes some strange interactions, and a lot of complicated code in the > > browser to try to make it behave as the user expects, so in the future I > > would really like to get rid of this aspect of it.) > > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see > and > > answer them. > > On Dec 1, 5:09 pm, Dianne Hackborn <[email protected]> wrote: > > On Tue, Dec 1, 2009 at 1:46 PM, Mark Wyszomierski <[email protected]> > wrote: > > > I guess I'm not understanding the default process creation method. > > > > Fwiw, what we are talking about has absolutely nothing to do with > processes. > > Please make sure you read this starting at "Activities and Tasks": > http://dirkbd:9092/guide/topics/fundamentals.html > > > > Note that the interaction it describes as the normal behavior for tasks > is > > what you seem to be asking for. > > > > Using a new project, with two activities, A and B (both have no custom > > > > > flags set in the manifest, and Activity A is set as MAIN and > > > LAUNCHER): > > > > > 1) Launch the app from the app drawer > > > 2) Have activity A start activity B. > > > 3) Hit the home button. > > > 4) Go to the app drawer again, try launching the app again. > > > 5) Looks like a brand new process instance of the app is created, > > > instead of returning to the original process instance that's already > > > in the background. As a user, I'd (personally) rather just return to > > > the instance already running in the background, rather than create a > > > new instance. > > > > The normal behavior, if you don't do anything, is that in step 4 you will > > bring the current stack of the task from step 1 brought to the > foreground, > > in its current state. This is why most of the built-in apps behave this > > way. If they do something different, they are doing something special. > For > > example the settings app sets a flag on its root activity to always have > the > > task clear when it is launched. But that is not the normal behavior. > > > > So the question is: what are you doing that is different? All you have > > mentioned so far is using singleTask, which if used in certain in > > appropriate ways can cause this kind of thing (and other strange > behavior). > > So my first suggestion is to not use this. > > > > Given that I have no other information about what you are doing, I have > no > > other suggestions than to use the debugging tools I pointed out to try to > > see what your app is doing. > > > > > For my application, it doesn't make sense to open multiple instances > > > of the application. Like the Browser application, there should really > > > only be one instance, and anytime the user hits the Browser app icon, > > > they should just return to any running instance they have on the > > > system, rather than create a new one. > > > > Is your app being launched from other applications like the browser is? > If > > not, you are not like the browser, so please don't model your app after > it. > > The browser does a lot of special things because of things that are very > > special about it. It is a really bad model. (And in fact this behavior > > causes some strange interactions, and a lot of complicated code in the > > browser to try to make it behave as the user expects, so in the future I > > would really like to get rid of this aspect of it.) > > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see > and > > answer them. > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
