tags:

views:

109

answers:

2

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.

  1. 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.
  2. 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.
  3. So far I haven't figured out how to setup having a different Activity control what happens in the center pane.
  4. If I continue down the multiple Activity path, should my main Activity be inheriting from ActivityGroup?
  5. Are using View classes more applicable in this case?

I know this has been a long post. I'd appreciate any advice. Thanks! CB

+1  A: 

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.)

Walter Mundt
Thanks for the input, the approach I'm working is to have my main Activity provide the user a choice of the initial screen(A, B, or C, each their own Activity) to be displayed. Main kicks it off with startActivityForResult. The the user can choose via a click/swipe to go to left/right to see a new screen. However I'm not happy with the hack implementation I'm doing. The Activity calls onFinish on itself to return to main and passes back the user choice left/right and main starts the applicable activity. Of course now the back won't work like I want. Suggestions?
cbursk
How do you want back to work?
Walter Mundt
Guess I worded that last part incorrectly, with by current implementation clicking the back button will take the user back to the main screen, where they choose A, B, or C to display. However, if the user is on A and swipes to view B, I think the expectation might be that when they hit back they go back to A, not main. However, I also don't want to get into a situation where they have navigated to around a lot and then need to click back over and over again before they exit. I'm leaning towards keeping an ArrayList of Activities in my main and then trying to handle it myself.
cbursk
In my previous apps I never had to handle more than a few Activities. It was easy enough to use a tab approach, but the app I'm making now has to have the look/feel of an existing windows app which has a more layered layout of screens.
cbursk
A: 

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.

schwiz