i am using the following method in a new application i'm developing.
there is a main activity, which instantiates different classes that extends RelativeLayout, and i'm using setContentView to switch between the different modules of the application.
i wonder if this is a good approach or necesarily i have to use different activities to the several screens the app haves.
I'd recommend using different activities, then you automatically get navigation between them via the back button. Plus, there will be subtle things that won't work right if you do it the way you're describing -- for example, Android automatically saves the focused control when you switch activities. It won't do this for your content views; you would have to save/restore focus yourself.
Alternatively, if it doesn't make sense for a user to go "back and forth" between the screens of your application, then you could still implement the application with multiple activities, using android.app.TabHost. This is what the Contact app uses, for example. Then each screen is just a sub-activity, and the whole app is really treated as a single activity. And if you want, you can use TabHost without actually having tabs. You can hide the tabs and enable navigation via buttons or menu items instead.
Related
I've recently been looking into the navigation system that Android uses with as intention to port my iOS app that uses an UITabBarController containing multiple UINavigationControllers. To replace the tab bar (which is not available on Android) I settled on using the built in DrawerLayout.
From what I've read, navigation in Android is generally done by creating an Intent, providing it with extras and then just replacing the current activity. This automatically makes sure the back button works, and optionally the back button in the top left if enabled.
However, I am not sure how to implement this way of navigation with the navigation drawer. The tutorial tells me to create a DrawerLayout containing a FrameLayout and a ListLayout where the FrameLayout will contain the actual application and the ListLayout will contain the navigation. This would mean that when I use the method described above to "navigate", it would replace the activity and thus removing the drawer.
What would be the best way to implement what I want (basic navigation with back button support while maintaining a global drawer navigation menu)? The possible options I can come up with is always keeping the same activity and dynamically replacing the FrameLayout, but that would mean a lot of boilerplate to render and possibly a hack to support the back button (and there would be no animations :(). The other option would be to just render the drawer on every activity (via subclassing or something), but that would mean that if the user navigates a lot the back button "stack" would become quite large.
I have tried to explain what I need in as much detail as possible, but it is quite hard to explain the concept. Basically, I want something similar to the UINavigationControllers in the UITabBarController.
You can either have one Activity with one NavigationDrawer and present the user with different views by switching Fragments back and forth within that one Activity. You would use the FragmentManager to switch between different Fragments.
Or you can use multiple Activities that all have a NavigationDrawer.
Second option might sound more difficult but it really isn't. You create a base Activity that all your Activities inherit from and all let them have their own NavigationDrawer, no problem.
Sure there's something in between or something completely different, but that's the most straightforward approaches I can think of.
The tutorial you've probably used (the one with the planets) is imho a bit misleading because it assumes a very basic app structure. If you have only little different 'screens' that might work, for a very complex application it's not suitable (again, in my opinion).
I've always opted for the second option because handling the navigation / backstack is just easier with Activities / Intents.
There's loads of different flags that you can set to your Intent to influence their navigation behaviour.
Also see this and that documentation. These documents might have been written when the NavigationDrawer pattern was not all that common but they are still useful.
This is the image explaining the usage of fragments. The first image shows two fragments and two activities.
Lame doubt. Why use two activities when the sole concept of using fragments is err.. using fragments instead of switching activities.
Depending on your goals you can do it either way.
The method shown in the guide can be implemented entirely in XML layout files so it is a better method to teach to a new user of fragments.
The method you suggest requires the developer to manage fragment transactions in code, which is not too difficult, but why do it if your app does not have any special behavior that requires the extra work.
Also, since the animated transitions between fragments look different than activity transitions, your method will reveal the use of fragments at the user level. The method in the guide uses fragments as a modular programming technique that is transparent to the user.
You end up with an app that uses available space on all device types, but on a small device it acts just like a classic app that users already understand.
The idea is that when you have extra room (such as on a tablet), you can display the content from what would have been two activities side-by-side rather than as two separate activities.
Think about a mail application. On a phone, you fn really only fit the list of mail on a screen, and you click on one to open the content of that mail on another screen.
If you did that on a tablet, there's a huge amount of wasted space; you can display the list of mail on the left side of the screen, and the selected mail's contents on the right side.
Because the list UI is the same in both examples, and the mail-display UI is the same in both as well, you can reuse that UI by including them as fragments. The logic for those UIs is also self-contained in the corresponding Fragment classes.
This allows the user to see more content with fewer activity switches.
I'm starting to build my new application and I'm trying to go the right way from the start to make my life easier later in maintaining and extending the application.
I saw applications that are probably built in fragments only. Of course, there is a host activity that hosts the fragments, but everything else is in fragments.
I suppose they have a Main activity that has the action bar and a layout to host the content in it. Everything else, including different screens such as Login, Home, Settings, Profile, ... is in fragments.
When we click on an item in the navigation drawer, for example on the Settings button, they simply change the content fragment, instead of launching a new activity for Settings.
Is that a good idea to build the main screens all in fragments, and just have one activity to display them?
Yes, it's a good idea to split up your UI into Fragments.
Some advantages:
-reuse in multiple Activities
-self-contained, modular UI
-rearrange fragments
Cons:
-it's a bit more work
-slightly higher learning curve
Are there any patterns on how to handle UI Transitions in Android Activities vs Fragments? I am currently looking into a UI that has at most 3 columns in Landscape.
I would like the UI to start with 1 column all the way across the screen and then on selection of something move in the second column and then on clicking on something in the second fade in the 3rd on tablets and phones and fade out the 1st column on phones.
I am wondering when I should do this as an Activity transition and when I should just use Fragments with Views that Appear. As far as I have read fragments can be moved over to other activities so my choice is either implement Activities with static column layouts that then transition taking the fragments with them or have one Activity with all 3 columns and have the Activity manage the Appearing of the Fragments. Both approaches could work but I was interested in pros and cons from as many angles for both solutions.
There are two questions similar to what I am asking but don't quite answer mine
Two panel UI with Fragments vs Separate activities
Android Honeycomb: layout problem - hide/show FrameLayouts
Fragments can seem like more code up front (since you're putting a view in a fragment, and a fragment in an Activity, instead of just a view in an Activity), but they're great at saving you from headaches in just this kind of situation- Definitely go with Fragments. They even handle the transitions for you.
We have some sample code called "Honeycomb Gallery" you can take a look at here, which has a two-column-plus-actionbar layout, and the ability to show/hide the leftmost column. This should give you a good head start in figuring out how to do layout for multiple fragments and show/hide them.
FYI, one important trade-off to using multiple fragments in an Activity instead of multiple Activities, is that fragments don't directly respond to intents - For instance, if you had a note-taking app where "View Note" page was an Activity, and you changed it so that there was a "view note" Fragment inside the main Activity, then you'd have to set it up such that the main Activity received a note ID AND a note action (create, view, edit, whatever) in the Intent, as opposed to just having the "view note" activity receive the note ID in the Intent. The main Activity would then need to set up the fragments on the page accordingly. Not a huge deal, but if external accessibility to various parts of your application via Intent is important, then it might be easier to break your app out into a few Activities, as well as use fragments to represent the individual components.
Based on the page The Android 3.0 Fragments API, an Activity is stand alone while a fragment can be though of as as a mini-Activity, which must be hosted within an actual Activity.
It goes on to say that the introduction of the Fragment API gave the android developers the opportunity to address many of the pain points developers hit with Activities, so in Android 3.0 the utility of Fragment extends far beyond just adjusting for different screens:
I think that using a single activity for an app is not necessarily a wrong decision, just a matter of style. It is a decision that you should make based on what you are trying to accomplish.
However, the introduction of Fragments was seen to solve real world problems. Based on that alone, I would recommend that you writing some "Proof of Concept" code and evaluate the results. At this time, this may be the only real world test that will matter
Use Activities for Full Screen
Use Fragments for Part of or no Screen (but not a service)
In my main application, there is on-screen tabs in a horizontal scroll-view I wanted to persist across multiple sections of the app. Sections include
News,Photos,Videos,Schedule etc. All single-user focusable tasks.
The main Application that houses it all is a application, and the tabs are just a view which call the fragment Manager.
However, I use Activities for complicated user activities deeper in the application. E.g. if someone plays a video, views a item detail page and the photo-gallery/slideshow sections, because they are all full screen components.
There is no need to show/hide fragments when transitioning to full screen because the activity stack handles everything you want to do it quickly and easily, and keep your code minimal and clean.
So I have Activity -> houses fragments -> launch full screen Activities for special commands.
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.