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.
Related
I have to implement a tree browser in Android. For this particular case, the tree will be a folders hierarchy. So the user will start in a root directory, and will be able to browse the whole hierarchy.
I have experience in iOS development, and this could be done using a UINavigationController, pushing a new controller each time the user taps a folder, but I am not sure if using the same strategy in Android is the right thing to do.
My first idea is to have a FolderViewActivity, create the first one with the root path, and every time the user taps a folder, create a new one with the new path. So you have a stack of activities, and if the user wants to go up, the current activity will be finished and the previous one will be shown.
Is this the right approach? Could be any problems with the back button doing this?
I have seen a few projects in github implementing a file browser, and it seems that everybody tries to reuse a single activity for doing everything, updating an adapter with new data when the user taps a folder. For me this is a poor implementation, unless there is a good reason for doing it (something Android specific?)
In Android you should use as less activities as you can. Activity is quite expensive object and it should be instantiate only if you need specific context with some different settings (orientation, action bar) or if you want to do some new things (for example, editing file content or displaying settings).
When you navigate through file tree you actually do the same action every time: show directory content with some path. For this routine you should use such lightweight and reusable objects as Fragments (http://developer.android.com/guide/components/fragments.html).
The benefits of such approach are: less memory, less expensive calls (create or destroy activity), more fast, more flexible, you can handle back button press as you like.
So you should not create a stack of activities, you should create one activity and then replace fragments for every new folder.
I'm doing the same using a recyclerview. No need for fragments or activities. Firs load the root, after a click you need to update the adapter of the recycler view with the new child objects. You can keep a navigation stack in order to have a navigation back strategie.
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.
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.
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
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm starting Android doing an application for searching restaurants, and some guidance would be welcome!
On the first screen I'd like to have a search field with a submit button (I get the data from a web service), and below a list with the results of the search. When clicking on one of the items of the list it will show a screen with the restaurant details as well as a map showing its location. My questions are:
Can I do everything in one single activity or should I do an activity for the search, one for the result list, one for the restaurant description, and another for the map?
Would doing one single activity make the application more responsive?
How can I use a list and a map within a normal activity (without ListActivity and MapActivity)?
Can I do everything in one single activity or should I do an activity for the search, one for the result list, one for the restaurant description, and another for the map?
The answer to this really depends on the flow of your application. I think the most important thing to keep in mind here is how the user will control your app with the "back" button. When you create a new Activity, that puts it on the stack, and the user can always press "back" to pop it from the stack.
One extreme is to put all these steps into different Activities. Then the user has ultimate control using the "back" button, but they might get annoyed jumping around Activities. Putting it all into one Activity is the other extreme, and I highly advise against that; users expect new screens to be a different Activity, one that they can "back" out of, and so if you put all your eggs into one Activity you'll have to start handling "back" yourself.
I think there's a good middle ground that your app could take, though of course your UI design may differ than what I propose. I would say you could do this in two Activities; in the first, you have a search field at the top (with a submit button next to it), and below that search field is a ListView which is populated with results. In the second, you use a TabActivity, where one tab is for the description and the other is for the map. I think this is advantageous for two reasons: on the first Activity, the user sees the results of their search on the same page as the search, and can quickly change the search parameters if necessary. And on the second Activity, the back key encapsulates backing out of one restaurant.
Would doing one single activity make the application more responsive?
Not really. Activities take time to create/tear down, but not that much time. It's better to segment your application in a logical way (for the user experience).
How can I use a list and a map within a normal activity (without ListActivity and MapActivity)?
You can get away with a ListView inside of a normal Activity without ListActivity; just include a ListView in your Activity's content, then in code grab the ListView and set its adapter manually. All ListActivity does is add some handy wrapper functions for one primary ListView, but it's not necessary at all.
Maps are a different matter. You will need to use a MapActivity for displaying maps, because MapActivity has special setup and teardown code that needs to run. Sorry.
I would like to add some guidance to Daniel's excellent answer.
Users can't tell the difference between one activity with views that change and multiple activities each with their own view - until they press the back button. So it is actually quite important that the back button should have a natural and logical purpose in relation to what is on the screen when it is pressed. The user should never be surprised by what happens when they use it.
So for each activity you have, ask yourself if the behaviour of the back button is logical to the end-user at all times. If you find a scenario where it is not then you should look at refactoring your activities - which could involve combining two or more activities into one, moving some responsibilities from one activity to another (but keeping them both), or even splitting an activity in two.
Creating a user interface that behaves logically as the user navigates around it is important, and the more your application does (and the more navigation there is) the more important it becomes. Unpredictable navigation behaviour stops people from learning how to get the best out of your application at the time when they are most likely to uninstall it - in the first few hours after downloading it.
I would have an Activity with both the search and list, then another that shows the details of the restuarant.
I don't think it would work well with just a single Activity.
Activities can contain multiple views - a single activity can contain a map and a list if necessary.
If you are looking to write modular, reusable and portable code, one activity is the way to go. Activity is an Android-only concept. The main flow and the business logic of any well-designed application should be platform-independent. Involving activities in your higher-level code ties your project to Android, which goes against platform-independence, a core principle in both Java and quality programming in general.