How do I manage Activity instance resuing in this scenario?

I'm relatively new to Android, and I'm trying to port an app from iOS, which does something slightly unconventional.

My app has an in-house xml language for representing GUI (kind of our own nib/xib in iOS or res/layout/whatever.xml in android, believe me, we had no choice), and an inflation mechanism that inflates this xml and builds a view controller and view instances.

As a result, in iOS, my app had several live UIViewController instances of the same class (added and removed from the navigation stack as necessary) which were all inflated once (from different XMLs) and remained alive as long as the app was.

Now, I'm a bit unsure about the correct way to do this in Android. Ideally, 开发者_开发技巧I would like to be able to create instances of an Activity class, each with its views inflated from our xml language, and do the navigation between then. However, to my understanding this is not possible in Android (since activities are started by intents, and created by class).

1. Is it true that I would not be able to keep activities alive and at the same time - not on stack (i.e. "back" always kills activities)?
2. If so, does this mean I need to inflate the activities and all their views from xml, every time I navigate "forward" (serious performance issue), or is there an alternative?
3. Is it reasonable to at least save the parsed xml structure in an Application subclass, so the inflation will be faster?
4. Would it make sense to only send (on creation) and save (for persistency) an activity identifier to the new activity instance, and have it go to my Application subclass, and inflate itself / get its state by identifier?

In general, assuming having the GUI inflated from XML is a must, and I would like to minimize the need to re-inflate the GUI, what would you suggest as the cleanest solution?

Any other tips will be greatly appreciated… Thanks!

I am not 100% sure I understand your situation - I think what you are saying is that you've got custom XML that defines your layouts and controllers. I am going to answer based on that, correct me if I'm wrong.

First, your questions show an understanding of the problems you face if you go down your current path. I'm not going to answer them individually because I think there's a better solution - use Fragments via the compatibility package.

The way Fragments work is that you have a single Activity, then a series of Fragments inside of it that define the UI. For phones, this ends up looking the same as an Activity-based application. But in your case, it will provide a few bonuses:

• Fragments can be created dynamically in code.

• Fragments can be popped off the stack, but kept in memory so you can re-add them later.

• You can store all of your pre-parsed XML in a retained, invisible Fragment instance (instead of the global Application subclass).

This isn't to say there are no problems with Fragments - there may be limitations there as well (I've only recently started working with them). But I would give them a look to see if they might solve your problem.

Another alternative would be to write a transformation (pre-processed) between your in-house XML and Android's XML. Android's XML View creation is pretty fast because it's optimized for it.