8

Why do I need to parcel my object even if I just need to send it to another thread of the same task? Actually I need to open an activity that will run even on the same thread (the main thread).

In other words why didn't Google provide a version of startActivity that take a generic object ad parameteer instead of a bundle to let me start an activity in case I know it is within the same process or (most of the times) even the same thread (the main one)?

  • Why have you opened a bounty for this question? You really don't expect anyone to answer the "Why didn't Google..." part of the question, do you? What is it that you want to know that isn't already covered in the answers provided? – David Wasser Sep 07 '12 at 17:05
  • 1
    I just wanted to be sure that I'm not forgetting ab out something that would explain why the sdk works like that. There are no answer to the question. I'm not talking about the second part that was just a way to make it more clear. you said that it is not necessary because you can use static variable. I do not consider it a real solution at least not in my case so the question is still open. Why can't I do it? –  Sep 10 '12 at 08:26
  • 1
    more in generl I don't feel confident when I use something but I don't know why it works like that –  Sep 10 '12 at 08:31
  • I added some more details to my answer. Perhaps this will help. If not, please indicate specifically what it is you want to know. – David Wasser Sep 10 '12 at 10:10

5 Answers5

12

You don't need to use Parcelable to pass an object from one activity to another. You can just store a reference to the object in a static member variable, like this:

public class Globals {
     public static MyObject myObject;
}

Now, in the code that has the object, you just do:

Globals.myObject = object;

and in the new activity, you can get it like this:

doSomethingWith(Globals.myObject);

Now, having said that, you need to be aware of the following:

Android can kill your process if your application is in the background pretty much any time it wants to. When the user then returns to your application, Android will create a new process for your application and then it will recreate only the activity that was on the top of the activity stack (ie: the one that was showing). In that case, the newly created activity will not be able to get the iobject by accesing Globals.myObject because the process has been newly created and that member variable is null.

To get around this you can either:

  1. Determine that your process has been killed and restarted (by checking Globals.myObject == null and react accordingly - Tell the user he needs to go back, or just go back yourself, or show a dialog or whatever)
  2. Save the object when Android calls onSaveInstanceState() in your activity (which Android will do before sending your app to the background) and restore the object in onCreate()

Hopefully this both answers your question and explains what to do about it.

EDIT: Add more information about why Intents contain serialized (Parcelable) objects and not the objects themselves

  1. When you call startActivity() or startService() Android may end up starting the activity or service in another process. In this case, if you passed an object in the Intent, Android would somehow need to serialize that object to pass it to the other process. Because of the "implicit Intent resolution" that Android uses to determine which component gets to handle the Intent, the caller may or may not know which component will get started.

  2. Android saves the contents of Intents for various reasons:

    A. Android can kill a process at any time. If it does that and the user wants to return to the application, Android creates a new process and then recreates the activities in that process as needed. To create the activities Android also needs to make the Intents available to the activities. If the process has been killed then any "objects" in the Intents would have to be saved and restored. Because the Intents contain serialized objects, it isn't a problem to recreate these as needed. B. PendingIntents are use by Android as a way for the Operating System to act as a proxy for the sender of an Intent. An Android component can create a PendingIntent and give that to the Operating System so that it can trigger the sending of that Intent at some later time. The sending component may or may not be active at the time that the PendingIntent is actually sent. This means that any object that could be passed in a PendingIntent must be able to be serialized so that Android can hold on to it even if the calling component no longer exists.

  3. Intents are not intended as a general "parameter passing" mechanism between components. Of course you can use it like that, but you can also use other (easier) mechanisms. Within a given process you can pass objects around using standard Java mechanisms. There is nothing wrong with using static (class) variables for this.

Community
  • 1
  • 1
David Wasser
  • 93,459
  • 16
  • 209
  • 274
  • Thank-you. I was thinkking about this solution. As you explained it is always a bit risky not only because of the risk you described but also because I would need to be careful about opening two instances of the same activity with different objects... –  Sep 04 '12 at 16:49
  • Well, you pretty much have control over opening multiple instances of the activity, so I wouldn't worry about that. As long as you understand what you are doing it is fine. I actually think this is usually a better way of "handing off objects from one activity to another", because you don't need to serialize/deserialize them. If you understand the consequences it isn't a problem. – David Wasser Sep 04 '12 at 16:54
  • Actually I don't. If the activity is not defined as singleTask or singleInstance, more than one instance can be opened and in that case this solution is not the easiest to be implemented. –  Sep 07 '12 at 13:59
  • If your application is not started by other applications then you don't need `singleTask` or `singleInstance`. You can control the rest using `singleTop` if necessary, but I still think that you can use this mechanism pretty reliably with low overhead. – David Wasser Sep 07 '12 at 17:04
  • OK point 2.A is an answer to my question but I'm not sure it is correct. As far as I know savedInstanceState is called to save the status so I could pass an object to the activity and eventually save a serializable object (as a Bundle) in savedInstanceState –  Sep 11 '12 at 11:53
  • In other words your answer is: the reason why the paramter passed to startActivity is serializable is that the framework can decide to send it again to the callee after having killed it. But does this really happen? Isn't the bundle provided in savedInstanceState sent instead? –  Sep 11 '12 at 11:56
  • 1
    If your activity is killed (due to orientation change) or your process is killed (to reclaim memory) and then the user returns to your application, the activity will be recreated and the `Bundle` returned from `onSaveInstanceState()` is passed to the `onCreate()` method. That's true. But...the original `Intent` is also made available if your app calls `getIntent()`. – David Wasser Sep 11 '12 at 16:19
  • Sorry the bounty is expired and I forgot about it :-( –  Sep 17 '12 at 11:52
4

The Android official documentation (in the FAQ) provides a lot of info about how to pass complex data structures.

How do I pass data between Activities/Services within a single application? http://developer.android.com/guide/faq/framework.html#3

Primitive Data Types

To share primitive data between Activities/Services in an application, use Intent.putExtras(). For passing primitive data that needs to persist use the Preferences storage mechanism. Non-Persistent Objects

For sharing complex non-persistent user-defined objects for short duration, the following approaches are recommended:

Singleton class

You can take advantage of the fact that your application components run in the same process through the use of a singleton. This is a class that is designed to have only one instance. It has a static method with a name such as getInstance() that returns the instance; the first time this method is called, it creates the global instance. Because all callers get the same instance, they can use this as a point of interaction. For example activity A may retrieve the instance and call setValue(3); later activity B may retrieve the instance and call getValue() to retrieve the last set value.

A public static field/method

An alternate way to make data accessible across Activities/Services is to use public static fields and/or methods. You can access these static fields from any other class in your application. To share an object, the activity which creates your object sets a static field to point to this object and any other activity that wants to use this object just accesses this static field.

A HashMap of WeakReferences to Objects

You can also use a HashMap of WeakReferences to Objects with Long keys. When an activity wants to pass an object to another activity, it simply puts the object in the map and sends the key (which is a unique Long based on a counter or time stamp) to the recipient activity via intent extras. The recipient activity retrieves the object using this key.

Persistent Objects

Even while an application appears to continue running, the system may choose to kill its process and restart it later. If you have data that you need to persist from one activity invocation to the next, you need to represent that data as state that gets saved by an activity when it is informed that it might go away.

For sharing complex persistent user-defined objects, the following approaches are recommended:

- Application Preferences
- Files
- contentProviders
- SQLite DB

If the shared data needs to be retained across points where the application process can be killed, then place that data in persistent storage like Application Preferences, SQLite DB, Files or ContentProviders. Please refer to the Data Storage for further details on how to use these components.

Why this is necessary:

Because of Android's unique ability to multitask and the idea of component life-cycles. In order to allow a user to leave an app (say with Activities A, B, and C, and intents i1, i2, i3) The system separates the application into components.

That way, if the user launches Activity B using intent i2, but gets a phone call or checks their email, they can go back to Activity B and the Android system can redeliver intent i2. And the user can easily and seamlessly pick up where they left off in your app.

With component life-cycles you make entry and exit to each individual component much easier. It also allows for asynchronous communication between different types of components such as BroadcastReceivers, Services and Activities.

To do this, the OS does what's called "marshaling". It flattens data to primitive data types (such as int and char) so that it can easily be held in memory or written to temporary storage for later retrieval.

Additionally this is required for any type of IPC (inter-process communication).

Using an Intent allows a developer to let the Android OS perform the marshaling -- which normally would be tedious (and possibly difficult or buggy).

pjco
  • 3,826
  • 25
  • 25
2

Android requires that any object you pass between tasks, activities, threads or services must be flattened into a Parcel or implement Serializable. They do this so that you can pass the object by value. When you pass objects to methods or functions, you're passing by reference. Intents are passed to the system and the system determines where to route your intent, whether it starts one of your activities or maybe opens another app.

In the case of the receiving object not being a part of your app, the receiver won't have access to your app's memory. For that reason, passing an Object reference would cause the receiving app to crash. By flattening the object to a Parcel or Serializable blob, the receiver can act on the values that were sent without having access to the original reference. If Google were to implement a facility where you can pass a basic object, it would require them to write deep copy functions for all objects and you would be required to write deep copy functions for all of your custom objects which would get really messy, slow and would take up quite a bit of system memory which could overflow the VM. By providing a common, basic facility for passing objects, they're able to speed up performance, reduce memory requirements, and ensure security by not allowing other apps to reference your app's memory.

As mentioned before though, you can create global references to object you want to pass between activities so long as they're all part of your application. It's not the most elegant solution and requires you to null out references when you're done with them so you don't eat up unneeded memory but it works well enough.

Michael Celey
  • 12,645
  • 6
  • 57
  • 62
1

All Activities, you create run only on the UI thread. There is no other way. With regards to your question about the need to parcel your objects, actually it is not the only way. You can pass objects by making the objects implement the Serializable interface also.

At a high level, Intents is asynchronous messaging mechanism for communicating between different components like: Activities, Services & Broadcast Receivers. The source & destination component may or may not part of the same application (hence process) and Android framework needs a standardized way of passing objects across processes if required.

-3

In order to pass your custom class object(s) between Activities/Services/etc. using Bundle within Intent, your class must need to implement Parcelable or Serializable.

That's the reason you need to parcel your object before pushing into Bundle

waqaslam
  • 67,549
  • 16
  • 165
  • 178
  • Sorry but this is not actually an answer. I asked why I need to do it and you answered "because you need to do it". I know that if I can't assume that the destination will run on the same task I must serialize the object but the question is explictly about the case when I know that the receiver will run on the same task. –  Sep 04 '12 at 13:49
  • what do you mean "receiver will run on the same task"? If you want to pass your own object via Intent, then your class should properly implement Parcelable. Since its the requirement, so you have to follow it. Parcelable actually serializes your object so that it can be sent and reconstructed at the other end. For more info read [this](http://developer.android.com/reference/android/os/Parcelable.html) – waqaslam Sep 04 '12 at 14:03
  • :-) but you keep answering that I must do it because it is required. But the question is about why it is required. –  Sep 04 '12 at 14:08
  • why Parcelable required? **because you need to pass your object through intents and to pass your object through intent, your class must implement Parcelable**. Now if you still dont understand this simple logic then i'm really sorry. Perhaps try reading some google docs carefully :) – waqaslam Sep 04 '12 at 14:38
  • It looks like I'm not managing to make the question clear. If someone understands why this is not an answer can he/she help me explaining why please? Thank-you in advance –  Sep 04 '12 at 15:06