Intent.putExtras size limit?

Question

I'm trying to pass data from one activity to another via Intent.putExtras like this:

private ArrayList<HashMap<String, String>> mGroups = new ArrayList<HashMap<String, String>>();
private ArrayList<HashMap<String, String>> mUsers = new ArrayList<HashMap<String, String>>();
...

Bundle data = new Bundle();
data.putInt("mode", mode);
data.putSerializable("groups", (Serializable) mGroups);
data.putSerializable("users", (Serializable) mUsers);
data.putInt("current_class", mCurrentClassId);
data.putInt("current_user", mCurrentUserId);

Intent intent = new Intent(ctx, ChildActivity.class);
intent.putExtras(data);
ctx.startActivityForResult(intent, 0);

Here mUsers is a List of HashMap<String,String> with users' data, including Base64-encoded photo, sum of strings sizes in this list is about 500Kb

Call to startActivityForResult hangs for several minutes with black screen and then I get ANR error. Sub-Activity's onCreate is not called at all.

If I don't add large strings into mUsers (no Base64-encoded photos) - works just fine.

Please help.

Answer 1

if both activities are yours, use a decent data model. Android doesn't encourage that much to very well designed application. Or turn it differently, it allows for fast developped application and doesn't promote much of good software application principle.

The solution of @Jean-Philippe Roy (québec ?) is interesting but singleton are quite an anti-pattern when it comes to more elaborate things, namely statefull models or serviceS.

The best option is to use an application class. This class is your singleton, by nature in android. So,

• define an application class in your manifest
• provide a static method to access the unique instance of the application class (it is always a singleton).
• give it a method to receive and hold your data, call it from your first activity
• and a second one to get them back in your second activity

---Updated after @straya's answer and 18 more month of Android programming :)

The question of sharing a data structure or processes accross application, activities, views, fragments is always present at mind when building Android application. It's important to know and consider that the application scope is the right place to hold shared structure, but using the application class itself to put a data structure in that scope is not viable with regards to :

• code quality, if all shared data structures and process are know of the application, it will quickly become bloated with accessors for all those entities.
• there is only one global shared pool of entities, which is not find grained enough and may lead to hard to detect ways of coupling entities

I now tend to prefer using Dependency Injection managed singletons. Dagger or RoboGuice both allow to create and inject a single instance of a given class into other classes. This technique, and DI more generally offers great possibilities for good Android designs :

• don't degrade quality of code, it is even shortened quite a lot. Use @Inject to inject dependencies and they will get injected.
• don't give 2 responsibilities to the singletoned class : it will not handle the singleton instance creation, the framework will do it.
• it's easier to pass from a singleton to a normal instance
• as those singletons become normal classes with a simple annotation, they do not contain static methods anymore and this allows to mock them very easily. And that's a big point.
• and of course, DI annotations make it very clear when a class depends on another class, helping to self document code more.

Answer 2

Maximum size is 1MB at Process Level, not at bundle level. This 1MB is for a shared buffer used by all state transactions in progress in the app's process, e.g. onSaveInstanceState, startActivity and others.

On Android 7.0 (API level 24) and higher, the system throws a TransactionTooLargeException when this process level limit is reached. On older versions you only get a warning.

As others suggested, you should research alternatives, if you need to pass a larger payload, e.g. use local database, file system, application level in-memory cache, remote storage, shared preferences (although these need to be small too), etc.

Source of truth: https://developer.android.com/guide/components/activities/parcelables-and-bundles

Answer 3

Just in response to Snicolas' answer:

Application is already a Singleton, no need to "turn it to" one.

Personally, after some serious reliance on Application to hold data for a long time, I've come to not trust it entirely. I use self-caching data objects to mitigate the problems though ;)