Develop Reference

How to save full instances of Activities and hence prevent reloading for each start?

My Android app essentially converts a website to a mobile application. The design is as follows:
Navigation Drawer containing the different categories of posts as per the website.
Each option is a different activity. I designed a BaseActivity (with the Navigation Drawer initialisations) from which the other activities extend, so each activity has the Navigation Drawer. (I do not use fragments)
Each activity calls a JSON parser to load posts from the website and hence takes upto 5 seconds to load.
The problem is that activities/screens once opened do not stay in the memory when called another time.
For example: Home Screen --> Category 1 Screen --> Home Screen causes the Home Screen to load a second time and hence takes up an additional 5 seconds.
How can I keep the full (or at least partial) instance of at least 3 activities in memory to avoid this nuisance?
I do call super.onCreate(savedInstanceState) but each activity restarts from the beginning.

For example: Home Screen --> Category 1 Screen --> Home Screen causes the Home Screen to load a second time and hence takes up an additional 5 seconds.
Add appropriate flags to your Intent, such as FLAG_ACTIVITY_CLEAR__TOP, when going back to the "Home Screen" activity. Among other things, this will bring the existing "Home Screen" instance back to the foreground, rather than creating a new one.
How can I keep the full (or at least partial) instance of at least 3 activities in memory to avoid this nuisance?
Your problem is not whether they are in memory. If the user visited them before, they are already in memory. However, without flags on the Intent or attributes in the manifest to help control matters, each startActivity() call creates a new instance of the activity.
So, first, you need to decide what the navigational flow of your app will be, particularly in terms of the BACK button, to decide what existing activity instances can be reused.
Second, you need a more effective caching strategy, rather than just storing stuff in individual activities. That way, even if you do wind up creating new activity instances (to keep the BACK button flow the way you want), those activities can retrieve the data from a cache, rather than have to reload the data from the Web site.

Best practice to display nested lists on android

I would like to display a tree without using the tree component, since I don't know how many levels there will be.
I though about a list, that opens another list on item click, and so on...
Is it correct to open a new activity for each level?
Will it not overcharge the system?
Or is it preferable to have only one list that I clear and refill with children?
How the standard back button will behave on both case?

I would have open a new activity for each level. Unless your tree is extremely deep, it will save you time handling back's button correct behavior by hand if you do it with only one activity.

Android Use One activity for differnet functionality or use Different activiyt for each [duplicate]

I just want to ask what is efficient way of use activity. Mean use one activity for multiple functionality or use multiple activity for every functionality.
In my application working some thing like Category->subcategory->Product listing. In which orientation change design and also need to consume previous functionality state for Back.
Thanks

Per the documentation for Activities, "An activity is a single, focused thing that the user can do". In other words, each different screen of your application should be an activity.
The only time you should have an Activity represent more than one screen is if it's a recursive action like a file browser; i.e. something that just changes the data that is displayed, but is displayed the same way.

It's quite common to create one Activity for every logical "screen" of your application, but to share the same Activity for multiple "states" (eg. dialog boxes, different modes) of that screen.
The back button will automatically go backwards through Activities (by default) and you can override the back button within an activity to revert to a previous state within the same activity (ie. hiding a panel)

Basically, Activity, in case of Android, is not a synonym for functionality. It is synonym for screen UI. Thus, how you implement your functionality is your choice. You just need to consider the following tips:
If you use the same activity for categories and subcategories (using
List elements), then you need time for deleting items for categories
(plus, GC also takes time), populating the list with the values for
subcategories. The weak points here that the user cannot return to
the previous Activity using back button (this violates the default
flow for user interactions), the screens are identical for
categories and subcategories (this can mess the user), it will takes
a long time for deleting unnecessary elements and populating with
new elements. Strong point: you will reduce memory consumption for
your application.
The second option is to use different activities. Weak points: it
also takes time to initialize new activity and to populate the list
with the values of subcategories, it will take more memory to store
two activities. Strong point: clear user understanding, more
responsibility to user's actions (you do not need to run GC to
delete unnecessary objects).
As for me the second approach is better unless you are not restricted with the memory.

Managing a tree of activities in android application

I think I didn't clearly asked this question before(because I didn't get the answer that I needed) and it was a mistake to post this version here, so I'll try one last time.
I have a big tree of activities where there is one root-activity with 6 list items, each item leads to its own activity with its own list of items, etc. One generation of the tree can be displayed in one activity. So there is only 1 activity for the root and 1 for all of its children(just different list items which are displayed during the runtime depending on the previously chosen item). Navigation obviously should work in both directions - forward(get closer to the leaves of the tree) and backwards(get closer to the root). Hops between generations are also possible(eg we can jump from the 1 generation straight to the 3 and backwards). I think that creating intents every time user goes to another activity is not reasonable. Is there any pattern or good practice to manage multiple activities like in this case? Maybe in each activity should be stored a static class which returns its intent or another management class created?

In Android activities are managed on a (back-) stack. Which means you can start a new activity and it is pushed onto the stack and is the activity shown. When going back via finish() this top activity is popped from the stack.
Stacks and trees work together quite well. When you move around in a tree you can keep the path to the root on a stack. This way managing trees of activities is what Android is actually made for.
Going down in the tree means calling the activity of the child node. Going up again is done by simply finishing your activity. You automatically appear at the activty one level up in the tree.

Android - Activities vs Views

I am working on an Android app that has multiple screens the user will need to navigate between and I am curious what the best practices are when switching between those screens. I am torn between creating a new Activity for each screen and simply changing the view (setContentView(R.layout.whatever)). The screens all share at least some variable values so I'm leaning toward changing views and using class level variables, but I'm worried a single activity could become very large and confusing with logic for multiple screens in a single file. I'd like to keep the code clean and separated, but I also don't want to be passing several variables around between views if that isn't needed.
Being new to Android development, I'm hoping some more experienced members of the community could share their thoughts and let me know how best to handle it.
Thanks!
Note:
I wasn't planning on using a viewflipper. My thought was to use a button click event and then call setContentView() to a new view for the page I wanted to bring up next.
Example: My application starts up using R.layout.main as it's view. User clicks the Help button and it calls a method that runs setContentView(R.layout.help); to display the help screen as opposed to switching to a help activity.

You should use an activity per screen as this will make the best use of the framework and allow the OS to selectively kill off screens if things get tight.
If you have a single activity and resources get tight the OS has two choices; kill everything or kill nothing, and if the user is not using your app then it's most likely it'll kill everything.
If you use an Activity per screen the OS can kill off some of the screens the user hasn't visited for a while, whilst still allowing others to remain active which allows the user to go back to them quickly.
As for sharing variables and values, you could use the SQLite database or SharedPreferences stores for passing them around if they are widely shared, or use the putExtra methods in Intent if they're only of use from one screen to the next.

If you have variables that you will reuse make a base class for them, that you will extend.
This can be a your custom activity that extends Activity.
As far I can tell you have to create separate activities for each views, only a few situation can be handled by viewflippers.