android - java - pass values through intents, bund

Question

Context:

Android

I read a lot of examples on the net for passing datas between activities.

What I learned :

• Pass primitive datas through Intents (intent.putExtra(key,value))
• Bundle the primitive datas and put it in an intent.putExtra(key,bundle object)
• Parcelables -> for complex objects and primitives.

Before you say it, yes, I certainly missed something.

Question:

Well, it seems that there are multiple ways to achieve the same goal.

If I want to pass a custom object, a Parcelable is my man. BUT I will still have to "serialize" it, so in the end, I will also have primitives, right ?

To pass primitives, why should I use a bundle when passing directly in an intent will make it too ?

The android documentation / forums / blogs examples did not make it for me. My C background still holds me back a bit.

Why having 3 different ways to achieve one goal, by the way ?

Answer 1

Using Parcelable is recommended if you're passing objects with non serializables. It means you can implement a serializable representation of your objects yourself to ensure the data is what you expect to be passed back and forward between activities.

If you're passing a simple id or a string back and forward by all means use intent.putExtra()

I found this article on the topic very useful to help understand the differences and benefits between the options: http://www.developerphil.com/parcelable-vs-serializable/

Answer 2

BUT I will still have to "serialize" it, so in the end, I will also have primitives, right ?

Pretty much everything in Java eventually boils down to primitives.

To pass primitives, why should I use a bundle when passing directly in an intent will make it too ?

Either way works. Use whichever makes you feel more comfortable. However, just watch out for collisions on keys (e.g., your activity, and a some base activity of yours that you inherit from, both trying to put the same thing in the same key of the Intent or Bundle).

Why having 3 different ways to achieve one goal, by the way ?

I am going to guess that "one goal" is "to pass data from one activity to another". That involves inter-process communication (IPC), even if the two activities are in the same process, as a core OS process is involved in the routing. For pretty much everything outside of streams from a ContentProvider in standard Android, IPC means that data has to be put into a Parcel, which gets converted into a byte array for passing across the process boundary.

Parcelable represents an interface that can be added to custom classes to allow them to be put into a Parcel.

Bundle is a concrete class that implements Parcelable and represents a HashMap-like structure, but strongly typed to things that are known to be able to go into a Parcel. Bundle is more convenient than a Parcel for developers, in that it offers random access by key, where Parcel does not.

Intent extras are merely a Bundle, for which Intent exposes its own accessor methods.

For all my cases, I should forget about the other possibilities and only use Parcelable ?

AFAIK, what EpicPandaForce was referring to was the comparison between Serializable and Parcelable. Either can go into a Bundle or a Parcel. Of the two, all else being equal, Serializable is slower, because it assumes that the serialized form has to be durable, able to be read in again months or years later. Parcelable assumes that everyone is working off of the same class definition and can bypass some Serializable overhead as a result.

That being said, it's a micro-optimization.

Why are the other still there then ?

Not everything can be made to extend Parcelable, notably java.* classes. Integer, for example, is not Parcelable. Yet, we would like to be able to pass int and Integer values around. Hence, Parcel supports int, as does Bundle.

you mean that I should get it back with the R.blah thing

AFAIK, in that comment, Mr. Marconcini was referring to "id" as a general concept, not referring to R.id values specifically. For example, if you are maintaining an image cache, rather than passing around actual Bitmap objects, pass around some identifier that points back to the cache.