Ok so the sample app code above should be producing the default
behavior though, right? This is happening on a mac running 1.5. I did
a fresh install of the SDK and the test app on a windows machine here,
and it works as you described on that machine (always resumes instance
if running in background instead of creating new instances).
I'll also see multiple instances when running the monkey test app (on
the problematic machine). In the DDMS process list, there will be one
listing for the test app. I select it, hit the stop button. The list
then shows another instance in its place (has a diff online value
etc). It seems like the monkey test app has launched dozens of
instances of the test app.
On the windows machine, this does not happen, there is only one
instance of my app after the monkey test app runs. When I select it,
and hit stop - it's cleared from the list, and that's the only
instance.
I'm not sure what's going on, but if the sample app above is correct
and functions in the default manner you described, I'll go with that
and then do some further testing on some devices,
Thanks
On Dec 1, 7:37 pm, Dianne Hackborn <hack...@android.com> wrote:
> 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 <mar...@gmail.com> 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 <hack...@android.com> wrote:
> > > On Tue, Dec 1, 2009 at 1:46 PM, Mark Wyszomierski <mar...@gmail.com>
> > 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
> > > hack...@android.com
>
> > > 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 <hack...@android.com> wrote:
> > > On Tue, Dec 1, 2009 at 1:46 PM, Mark Wyszomierski <mar...@gmail.com>
> > 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
> > > hack...@android.com
>
> > > 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 android-developers@googlegroups.com
> > To unsubscribe from this group, send
>
> ...
>
> read more »
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
