How to switch between screens?
I looked and attempted the above code, and while it does work, it's not what I'm looking for.
In the above example, you open one intent, and then close it when you're done with it. Another example from above showed that I could create new intents endlessly, but then clicking on the Back button of the Android Device makes me go back once for each new intent created, implying that it's going to eat up memory this way.
What I would like to attempt to do is to move between instances of Intents. There will be times when the screens could allow for an endless, memory eating circle of moving between screens.
For example, Screen1 has a button leading to Screen2. Screen2 can lead back to Screen1, or to Screen3. Screen3 can then go back, or go straight back to Screen1. Is there any way to avoid the memory leak for a large number of screens/screen changing/drilling down(Screen1 eventually leading to Screen12 or something)?
In your situation, i suggest you to use a ViewPager to navigate/switch between your Screens.
Just create a Fragment for each Screen (or recycle an old fragment, it depends on what your screens looks like).
Related
My applications memory consumption seems rather high when switching between activities. I quick explanation is that I have an ActivityA that is singleTop and is basically the home screen, you select an item in a list and it takes you to ActivityB which is a more detailed version of the list item. You then press back and it finishes the activity returning to ActivityA. Both activities are quite rich in controls and have high quality images scattered around, but there's definitely something not right here.
I have drawn a quick diagram to show the lifecycle:
As you can see when the app first starts it is at 34MB, after selecting a list item it goes up 2.5MB, then when I press back it goes up again.. this will continue to happen whilst going back and forth. The first thing I need to establish is whether or not this is normal behavior for an application? If this is not the case I clearly have some work to do in releasing some resources, the issue is, what?
In my onDestroy() of ActivityB I unregister from all my receivers, I call finish() on anything I use and have even tried setting everything to null but still no change! I use no special flags when starting ActivityB or finishing it, could that be part of the problem? The history of the stack is sticking around maybe?
EDIT:
I use SceneTransitionAnimation to move an image between the two activities, when I turn this off it goes up 0.5MB each time I go from A to B and 0.01MB when I go from B to A. I guess I should ask the question of how the much bigger increase can be avoided whilst still using SceneTransitionAnimations??
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.
A fairly common model for iOS apps seems to have a single UITabBarController, where each tab essentially holds a UINavigationController, i.e. a stack of controllers, and pressing a tab switches to the top of the corresponding stack. Can I get the same behavior on Android without a lot of custom code? (Note: I am using menus instead of tabs on Android).
After reading http://developer.android.com/guide/topics/fundamentals/tasks-and-back-stack.html the closest I can see is to have multiple tasks, each one representing a stack (akin to UINavigationController), and to use FLAG_ACTIVITY_NEW_TASK to switch to another task/stack. When I switch, is there a way to go straight to the top of the stack, or do I need to keep that piece of state myself?
One problem with keeping that state myself: I've noticed that if my app launches an Intent that starts a new process, sometimes my original app's process is killed (I think), and all of my global state is destroyed.
The only other solution I can imagine is to have a dummy Activity per stack, to push DummyActivityN essentially right before I switch away from the Nth stack, and, when switching to the Mth stack, to start activity DummyActivityM with FLAG_ACTIVITY_NEW_TASK, and then have DummyActivityM immediately finish() itself.
One last problem: as I navigate to the bottom of one of the stacks, with the back button, I would like to hit the back button once more and NOT go to another stack/task. But this seems easy to overcome by launching an Intent to go to the home screen; is there anything better?
If I understood your problem correctly, if you add this parameter to your Activity declarations in AndroidManifest.xml, the Activities that are launched by your custom menu will be only created once - keeping their state while you move around the tabs.
android:launchMode="singleTask"
I hope this helps,
Best,
-sekran
Sorry, I know that this topic has been covered a bit. I've read the related posts and am still a bit confused. I am working on an app that while the prototype will have 3 main screens, it will eventually have dozens. Each screen will present either dynmically changing status or take user input. To visualize, it is required to be laid out similar to how MS Word or a typical PC is. It has a status bar at the top and a navigation bar at the bottom that is common to all screens (slight tweaks for some screens, like different icons) in the middle is what I would call a view pane that needs to be updated with a applicable layout.
The status, nav bar, and each screen are defined in their own layout xml file. For my first swag at it I just used a ViewFlipper and loaded the 3 screen layouts into it. However that means that currently I have one main Activity which will not be maintainable as I continue to add screens.
It feels right to me that each screen layout should have an associated Activity class that understands how to control that screen. I need to figure out how to load that into the center pane dynamically. However I thought I read in another post that using multiple Activities can be a CPU and RAM drain.
Currently I tried making one of the screens it's own Activity and kick that off from the main Activity by creating an Intent and than calling startActivity. However that causes the new screen Activity to reside on top of the main Activity. The interesting thing is that then pressing the back button dismissed that activity and returns me to the main.
So far I haven't figured out how to setup having a different Activity control what happens in the center pane.
If I continue down the multiple Activity path, should my main Activity be inheriting from ActivityGroup?
Are using View classes more applicable in this case?
I know this has been a long post. I'd appreciate any advice.
Thanks!
CB
As you noticed, Android will implicitly track a stack of started activities in a task, and the 'back' button ends the top one, reactivating the next one down. I would advise you to think about which kinds of things the user might expect the back button to do, and make it so that activities are separated along those lines.
I haven't played with ActivityGroup so I can't advise you there. If you go with completely separate activities, you can have them all use the same "shell" content view with the common nav/status bar. Have a superclass or utility class handle populating and managing that from there. Then use a a LayoutInflater (you can call getLayoutInflater()) to fill in the middle with your Activity-specific view.
If you want one of the activities to have multiple screens, you might still end up with a ViewFlipper in the center slot. Again, you want to have an Activity transition wherever you want the user to be able to go "back"; that also means you may NOT want to have a change of activities in cases where screens are closely related or part of the same logical thing-being-done. (You can override the back button's behavior, but unless you have a good reason to, it's best to just arrange the app so that Android's basic setup helps your app's UI rather than working at cross purposes.)
If you want to use activities in the fashion you talked about, you might look into using a tab activity. It actually works in the way you want, you just need to hide the tab widget and put your navigation bar there instead. Or, you could go a little deeper and make you own similar tab-like ActivityGroup like Walter mentioned if you have more time.
You could use a view pager with fragments to accomplish the flip between the different views but still allow your activity to have full control over it. The activity can control the menus while the fragment controls your viewing area. This way your back button will properly dismiss the activity containing all pages related to the activity instead of walking down the stack.
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.