0

I'm wondering, where is a good place to create and hold objects in android activities? Always the activity highest in the hierarchy? Here's what I mean.

/* Let this be the main launcher activity */
activity1{
  List someList  // Edit: This should of course be public, my mistake.
}

/* The next activity is a child of activity1 
*  and can be started by activity 1 
*/
activity2{
  ...
  do_something(activity1.someList);  // Does this always work?
  ...
}

/* The next activity has no parent and can be launched 
*  when the app receives an intent, for example a 
*  photo is shared to my app.
*/
activityX{
  ....
  receive_intent(...);
  do_something(activity1.someList) // This might work, when app is already running
}

See, my problem is I'm never sure where it's okay to place objects. In my example activity2 needs access to one of activity1's objects, which I never had any problems with. But does this case always work? Will the objects from a parent activity always stay in memory while the child activity is visible?

Can I somehow pass a reference to someList from activity1 to activity2 and pretend that someList has been instantiated in activity2? Or is this not required?

activityX on the other hand clearly will create a nullpointer exception when the app (and thus activity1) is not running in the background (or just not cached?).

Is there a document with guidelines for android programming covering things like this?

Potaito
  • 1,181
  • 2
  • 10
  • 32

1 Answers1

1

Let's see..

/* Let this be the main launcher activity */
activity1{
  List someList
}

You might want to declare your List as public and / or static


/* The next activity is a child of activity1 
*  and can be started by activity 1 
*/
activity2{
  ...
  do_something(activity1.someList);  // Does this always work?
  ...
}

This might work, provided a few conditions are met:

  • It will only work if activity1 is started before activity2, otherwise, someList will be null, as it has not been created yet.

  • If android decides to kill your activity1, someList will be null. (This can happen if memory is low, eg. if your activity2 uses a lot of memory.)

Will the objects from a parent activity always stay in memory while the child activity is visible?

No, they may not stay in memory since android can kill your activity which is not visible at any time. (this does not usually happen though, since most devices have enough memory)


/* The next activity has no parent and can be launched 
*  when the app receives an intent, for example a 
*  photo is shared to my app.
*/
activityX{
  ....
  receive_intent(...);
  do_something(activity1.someList) // This might work, when app is already running
}

What if your user shares a photo without starting your app first? ...SomeList will be null. (it will generate a NullPointerException if your activity is not running in the background)


Don't rely on your app being running, since the android system may kill your app at any time!

If possible, you should transfer your data via intents or recreate as needed. If you want to transfer an array / list via intent, the Intent class provides ways of doing this. If you really need to transfer objects, you should use Parcelable. See here.

There is an interesting thread about this here.

And oh, memory leaks: For example, if you have an inner class, and instantiate this into a static variable in your activity, you will get a memory leak, as the static variable will outlive the activity. (see here for a better explanation)

Community
  • 1
  • 1
Jonas Czech
  • 12,018
  • 6
  • 44
  • 65
  • Thanks for clarifying. I was just trying to safe memory and cpu by using objects that have already been created in a previous activity. But yeah, if the app *might* crash then, it's obviously not worth it. – Potaito Mar 09 '15 at 15:55
  • @potAito It's generally not worth trying to save cpu / memory if your app may crash as a result. Also, you won't save that much memory anyway, since a list with 1000 items will only be a few hundred KB anyway. Also, it does not cost much cpu to create objects, and your app will (usually) be just as fast and smooth whatever you do. But if doing this works for you, and your app _does not_ crash, go ahead and do it ! – Jonas Czech Mar 10 '15 at 18:02
  • @ JonasCz well I asked since I wanted to know the proper way of doing it, and now I do :) – Potaito Mar 10 '15 at 18:35