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]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
