Requirement
I have an application with 2 activities, say A and B, with navigations like A->B and B->A (on back press). My requirement is
I want a view/layout floating on screen, irrespective of which
activity is currently visible. I inflate this view on app
start(onCreate of activity A), it remains static on screen during the
transition from A->B and when B is onscreen.
So naturally this view should be inflated only once (when app starts,
onCreate of A).
What I found out
I did some searching, and from what I could find, there are 2 methods to reuse layout in android
using <include>
It just seems like a tool to write xml code of commonly used UI elements. It gets inflated every time it is used in a parent layout.
using ViewStub
I did some research on using ViewStub and It also seems a way to reuse code segment in many layouts. It also need to be inflated every time we use it in a layout except it gets inflated only when we make them visible at run time.
Another hint of my requirement
For people familiar with iPhone development you can add view's to UIWindow, which stays there irrespective of which UIViewController is currently active. I want exact behavior in my application.
My original setup
I am targeting android 2.1 and above. It seems Fragment is available from API level 11 (android 3.0) and above. One option is to use android compatibility library that enables usage of Fragment in older versions. I am currently researching on that now. But I also would like to know if there is any other methods available to fulfill my requirement, rather than change my entire project and use fragments.
I have around 30 odd activities in my application and I want this layout floating over all of them. I just made out a test case with 2 activities to make the question simple and easy.
Solution 1: FrameLayout
I think what you want to use is the FrameLayout. FrameLayout is designed to block out an area on the screen to display a single item. Child views are drawn in a stack, with the most recently added child on top.
http://developer.android.com/reference/android/widget/FrameLayout.html
Then read here about the back stack that you could use in your activity to flip back and forth between the activities using the back button:
http://developer.android.com/guide/topics/fundamentals/tasks-and-back-stack.html
Solution 2: Fragment Transactions
Rather than code two separate Activities, code a single Activity with two Fragments. Here is a blurb from the Fragments documentation:
"A fragment must always be embedded in an activity and the fragment's lifecycle is directly affected by the host activity's lifecycle. For example, when the activity is paused, so are all fragments in it, and when the activity is destroyed, so are all fragments. However, while an activity is running (it is in the resumed lifecycle state), you can manipulate each fragment independently, such as add or remove them. When you perform such a fragment transaction, you can also add it to a back stack that's managed by the activity—each back stack entry in the activity is a record of the fragment transaction that occurred. The back stack allows the user to reverse a fragment transaction (navigate backwards), by pressing the Back button."
Related
I am currently writing an Android app for my Masters final project. The app has two Activities and both have layouts corresponding to each activity. I also have a settings activity with settings fragment but I am not concerned about this one.
Activity A currently has a Spinner and a button which when pressed will do some stuff and then launch a Activity B. Activity B displays a chart, contains a couple of actions and a button to go back to Activity A.
Neither of these activities have Fragments currently but I am curious if it would be better to include Fragments. As far as I can tell using a Fragment wouldn't hinder performance so at this point it would be a cosmetic change.
Fragments are usually needed if you need to re-use some specific layout.
E.g--> If you have an app which displays movies, you can click and get movie details.
Here it would be better to use fragments as the layout would be the same for each movie and only the content would change inside.
In your case however, since there is not need for such frequent scenarios, you really do not need fragments.
If you want to change the content without changing your activity due to some actions of user, implementing UIs inside Fragments can be useful. Just set the the desired fragment inside Activity by using its FragmentManager. However, otherwise don't think about such change (shifting lots of code/layout from activities to fragments) in the code.
I'm trying to wrap my head around when exactly I should use Fragments and if I'm going to use them how to do so properly.
To my understanding Fragments should be used if you want a more flexible UI as it will be easier when rotating the device and easier to have your layout work with multiple screen sizes.
It seems to me that it is good to use them because you could have an app with ONE activity and multiple Fragments so the activity will be able to get calls from callbacks while the Fragments change what the user is seeing and interacting with. If I were to compare two apps, one made with Activities and the other with Fragments I would imagine to see something like this:
Activity app has a log in screen. The user can log in and it brings them to the main menu (New Activity). Once there they select the Friend button which brings them to a new Friend activity.
Fragment app has an Activity that loads the Log in Fragment into it's FrameLayout. The Log in Fragment allows the user to log into their account. Once it logged in, it replaces the Log in Fragment in the FrameLayout with the Main Menu Fragment. User presses Friend button, it opens the new Friend Fragment in the Activities FrameLayout. In this case all the work is being done in the Fragments but the Activity is just really holding them.
Please tell me why this is the incorrect use... or why this is correct.
Cheers
Take a look at the official Fragments doc. Short answer: always use Fragments. Fragments are better for reusability, flexibility, etc., etc.
I'm currently creating an app in which the main screen is build up out of 2 Fragments.
When the user selects options on the main screen, one part of the screen gets replaced by a new Fragment, all pretty much basic stuff.
Now I'm trying to create a screen with several tabs, which all open a new fragment inside them. I had this working with regular intents, but that was before switching to Fragments.
I read that this is possible by using a FragmentActivity, but sadly you can't replace a Fragment with a FragmentActivity, simply because the transaction won't let you.
Is there any way of doing this inside an ordinary Fragment? Or should I try mimicking the behavior by using a layout with a fragment inside which gets replaced by another one at the press of a button, much like the main screen? (Or won't that work due to fragments in fragments?)
There is an example in Android's support library that describes what seems to be what you need. You can find it here: FragmentTabs.
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.