If I start another app's activity with an implicit intent, what does the activity back stack look like and why? I found in the docs that 'the activity runs in a separate process' - does this mean the activity is in its own backstack?
The backstack would still be your activity. Running in a separate process means that they run in separate Linux processes- that they have memory protection and cannot access each other's variables (they communicate by Bundle, which is passed from one to the other via IPC).
I guess it really depends on the flags that you pass in. Try going through
the developers for more info.
Related
If I have a reference (in a non-activity class) to an Activity that isn’t currently being displayed, is there any reason that I shouldn’t use it start another activity?
Example:
Activity A:
Intent anIntent = new Intent(this, ActivityB)
startActivity(anIntent) // happens first
Some Other Non-Activity Class:
Intent anIntent = new Intent(refToActivityA, ActivityC)
startActivity(anIntent) // happens second
You generally shouldn't hold references to Activities or other contexts unless you have a good reason to do this.
1) If your first activity is no longer being shown, it's subject to being killed by the system and garbage collected. If you hold the reference, though, it can't be garbage collected, resulting in a (potential) memory leak.
2) Saving a reference to an Activity means you're coupling that class to that activity, which is generally bad practice.
3) Launching activities is an Android concept and should generally be controlled by other Android components. Unless your class is some navigation abstraction, it probably shouldn't be starting activities.
Without more information, it's hard to say what you should be doing in your specific case, but generally you should use the most local Context to start the activity (which could be a Service, ContentProvider, BroadcastReceiver, etc) and not hold on to Contexts.
Hope that helps.
The quick answer is don't do it.
You have a reference to an Activity that is not being displayed. For all you know, that Activity could be destroyed. The fact that you have a reference to it doesn't guarantee that it'll be in a valid state. Trying to use it may throw an Exception.
Personally, I hate seeing a crash/ANR popup for an app that I'm not actively using.
Arguably if the activity is in a valid state and you are able to use it to launch the new activity, it's an even more annoying experience for the user: You're hijacking whatever they're doing (which is likely outside of your app now) to bring to foreground another activity from an app that they've recently closed.
Bad experience in both cases.
Then again without knowing exactly what it is you're trying to accomplish, it's hard to give a definitive answer. Perhaps reword your question and say what you want to accomplish.
I found and read a lot of articles talking about global variables in Android, some of them suggests using an subclass of Application + declare it in the manifest file as a glbal variable container.
But some articles mentioned that This class could also be killed when system memory gets low, is this correct?
So, is it 100% reliable to use an Application subclass as a global variable container? And could somebody give me a link to some documents explaining the life cycle of an application in Android (not activity)?
EDIT:
Thanks for the answers, I think I need to explain a bit more of my question.
The situation is, I just want to share a global String variable, Activity A modifies it, and activity B reads it.
When B is currently visible and user receives a call,
If A and B are killed but Application keep untouched (is this what Google calls an empty process?), I'm OK with it.
If A, B, and Application class are all killed and when user come back my app gets a clean start, I'm OK with it.
Which I'm not OK with it is, everything was killed including the Application class, when user come back my app doesn't start fresh, I mean, it starts from Activity B, will this happen? then should I start A manually or let Application class to do the initiation? none of these ideas looks good to me...
The answer is both "YES" and "NO" - the Application class can be used as a "global variable container" in that all activities and classes can rely on it.
However, you cannot rely on the Application class (or any other class) to persist indefinitely. In other words, if the user answers their phone, your application could be destroyed and then re-created when the user completes the call and returns to your app. So, you definitely cannot rely on it to persist data, but you can rely on it to provide global access to data when you app is active.
This is the Android documentation:
http://developer.android.com/training/basics/activity-lifecycle/index.html
This is a really good post on it - read the SECOND highest voted response, in addition to the "accepted" response:
Using the Android Application class to persist data
It explains pretty clearly how your app can be killed/destroyed whether you expect it or not.
EDIT:
To clarify, if you have a variable (call it "myVar") in the Application class and a user sets it in Activity A, then proceeds to Activity B, Activity B will be able to read the change.
If Android "destroys" the application class, which can occur anytime the user is not in your app (and in rare instances even if they are...), the app will be reconstructed so that the Activity Stack is still valid but "myVar" is not set, unless you persist the data.
In other words, Android will recreate the Application class and Activity B, but there is no guarantee that it will recreate Activity A until the user does something to destroy Activity B. Also, it will certainly not "replay" the user actions in Activity A in order to recreate the app state, and in your case that means "myVar" is not reliable.
If you read the references provided, you will see that this is the case (and also I have tested it).
EDIT 2:
To persist data, consider SQLite (which is pretty complicated and there are many references) or SharedPreferences:
How to use SharedPreferences in Android to store, fetch and edit values
This class could also be killed when system memory gets low, is this correct?
Yes.
So, is it 100% reliable to use an Application subclass as a global
variable container?
If you want to use it to pass values it is not reliable.
why?
EDIT:
Which I'm not OK with it is, everything was killed including the
Application class, when user come back my app doesn't start fresh, I
mean, it starts from Activity B, will this happen?
yes. It is possible that you set a value in your application from activity A and then when you are in Activity B user leaves your app and after a while android kills your process. then user comes back wants to look at your app. android again recreates application and activity B but not Activity A and instead of fill the application variable with what has passed Activity A to it, it recreates it from default initialization. So simply you missed what has passed or set by Activity A.
Don’t Store Data in the Application Object
I'm a bit confused about the difference between a task and a process in Android.
If I understand correctly a task is just a stack of activities. From what I read so far I think a task could look like this:
| Activity A running in Process P1 |
| Activity B running in Process P2 |
| Activity C running in Process P3 |
So basically activities from different processes can be contained in the same stack. Am I correct?
Another question: What is the real meaning of "application context"? The process or the task?
And final question: The application class (which is basically a singleton) represents the process or the task?
Everything I've ever learned about it, I've learned on this page.
Edit: I also just stumbled upon Activity and Task Design Guidelines. It looks to cover the exact topic you asked about. I learned a lot :)
So basically activities from different
processes can be contained in the same
stack. Am I correct?
Based on my understanding, you are correct. My grasp is that Processes are the units of actual execution while Tasks are about association to get things done. As an example from the aforementioned page, if you create an intent that opens a webpage, the Activity that it creates is created on the web browsers process but is associated with your applications Task. A task, therefore, becomes a virtual stack of Activities running on different processes depending on the application that provided the Activity.
Another question: What is the real
meaning of "application context"? The
process or the task?
This is a good question. Based on reading the page above, my understanding is that an Applications context is associated with the process. I'm basing that on the interpretation of this line from that page, but there may be other info:
Normally, a new instance of an
activity is launched into the process
of the application that defined it, so
all instances of the activity run in
the same process
And final question: The application
class (which is basically a singleton)
represents the process or the task?
With the same interpretation as above, my guess as to why an Application object represents a Singleton is because all of your applications activities get run on a single process and that process is tied to the Application. I don't know that this is a design point, but it appears to be, at the least, a consequence of the current design.
Edit: There are some caveats to this. It appears that your application can be spread across multiple processes so, my guess is that the Application Object and context act as a mechanism for tethering all the processes together. I'm pretty sure your mental model already allowed for this, assuming the processes were from different applications, so its only a small difference to allow it inside a single process.
The manifest element has the attribute android:process with the description as follows:
The name of the
process in which the activity should
run. Normally, all components of an
application run in the default process
created for the application. It has
the same name as the application
package. The element's
process attribute can set a different
default for all components. But each
component can override the default,
allowing you to spread your
application across multiple processes.
If the name assigned to this attribute
begins with a colon (':'), a new
process, private to the application,
is created when it's needed and the
activity runs in that process. If the
process name begins with a lowercase
character, the activity will run in a
global process of that name, provided
that it has permission to do so. This
allows components in different
applications to share a process,
reducing resource usage.
Process:
When an application component starts and the application does not have any other components running, the Android system starts a new Linux process for the application with a single thread of execution. By default, all components of the same application run in the same process and thread (called the "main" thread).Every application runs in its own process and all components of the application run in that process, by default.
for detail process: http://developer.android.com/guide/components/processes-and-threads.html
Tasks:
A task is a collection of activities that users interact with when performing a certain job. The activities are arranged in a stack (the "back stack"), in the order in which each activity is opened.
An activity can even start activities that exist in other applications on the device. For example, if your application wants to send an email, you can define an intent to perform a "send" action and include some data, such as an email address and a message. An activity from another application that declares itself to handle this kind of intent then opens. In this case, the intent is to send an email, so an email application's "compose" activity starts (if multiple activities support the same intent, then the system lets the user select which one to use). When the email is sent, your activity resumes and it seems as if the email activity was part of your application. Even though the activities may be from different applications, Android maintains this seamless user experience by keeping both activities in the same task.
for detail task-http://developer.android.com/guide/components/tasks-and-back-stack.html
An important note from Android Developer :
A common misunderstanding about Android multitasking is the difference
between a process and an application. In Android these are not tightly
coupled entities: applications may seem present to the user without an
actual process currently running the app; multiple applications may
share processes, or one application may make use of multiple processes
depending on its needs; the process(es) of an application may be kept
around by Android even when that application is not actively doing
something.
In my Android application, I overload the Application class, and I updated the tag in my manifest. This application also creates an Android Service.
I have put some logs in the onCreate of my Application class, and I see it being called twice.
The first time is when my application gets launched (this is expected) and then, it's usually right after the Service is being created.
the log also shows that a second instance of the Application is being created.
(I print the "this" value and they are different).
I thought the Application would be created as a singleton.
Is that happening because I create a Service?
Yes, if you used android:process then you have it running in a separate process, so when the service starts a new process is started for it and thus a new Application object for that process needs to be created.
But there is a more fundamental problem - it is just not right for an Application object to start one of its services. It is important that you don't confuse Application with how you may think of an "application" in another OS. The Application object does not drive the app. It is just a global of state for the app in that process. In fact, the Application object is completely superfluous -- you never need one to write an Android application. Generally I actually recommend that people don't use it. It is more likely to cause trouble than anything else.
Another way to put this: what really defines an application is its collection of activity, service, receiver, and provider tags. Those are what are "launched." All an Application is, is something that is created as part of initializing an application's process. It has no lifecycle of its own, it is just there to serve the other real components in the app.
So just ignore Application when designing your app; it will reduce confusion. (In its place, I prefer to use global singletons for such state.)
Also as a general rule, I recommend not using android:process. There are certainly some uses for it, but the vast majority of the time it is not needed and just makes an application use more RAM, less efficient, and harder to write (since you can't take advantage of globals in a single process). It should be obvious to you if you reach a place where there is actually a good reason to use android:process.
A Service should not really be thought of as an Activity, and you're bound to have problems later on if you think this way. Services and Activities can belong to the same application, if you defined them that way in your AndroidManifest.xml, but they behave differently and have different lifecycles. If you want your Service in a different process, then you set android:process="string" in the <service> section to give it a name different from your application name. You won't have access to global variables when it's in a separate process, and you should communicate to your service through Intents. If your service is more complex, you might want to look at making it remotely callable through AIDL. If you want a singleton activity, then set that Activity's launchMode to either singleInstance or singleTask. singleInstance means it will be the first and only instance of this Activity in it's task stack and no new instances will be created for any new Intents. Since it's the only instance of this Activity, it will always be at the top of the task stack, and always in a position to handle new Intents directed at this Activity. If the Activity is declared as singleTask it will also be a singleton but may have other Activities in the same task stack, and may even have Activities at the top of the task stack above it. This is an important distinction to note. Remember this: singleton Activities that are NOT at the top of the task stack cannot handle new Intents, and the Intent will be dropped. If you want your Activity to always be able to handle all new Intents destined for it, then you most likely want to use singleInstance
The problem is that a Service is a component too, with its own lifecycle, just it hasn't got an user interface.
You should check the developer application fundamentals for the alternatives.
I just had this issue and after reading all this, nothing helped. Here is what helped me.
Add the attribute MainLauncher = true to your MainActivity.cs class.
I have an application with a multi-instance activity. I would like each
instance of the activity to appear in a new task and process.
Any suggestions on how to do this? By manipulating the manifest I can
cause all instances of the activity to appear in a specific task and
process, but I haven't found any way to cause each instance to appear in
a different task and process.
(The requirement to have different tasks is that we want each instance
of the activity to appear separately in the task list; the requirement
for different processes is that each instance of the activity is backed
by a chunk of native code with global state. We can't change either of
these.)
Well, you could use FLAG_ACTIVITY_MULTIPLE_TASK but the documentation is pretty clear that you should not use it for what you want to do. It's possible that you could end up with a bunch of Activitys that the user has no method of getting back too.
I suggest reexamining your app's architecture. Maybe you can store the link to the native state in a Local Service and have the activity fetch the correct one from it depending on what is in its Intent.