All I want is to be able to use FragmentTransaction.replace(...) and have fragments slide into and out of place just like activities, using the default activity animation.
By default the fragments simply appear and disappear. That is an acceptable default behavior.
With FragmentTransaction.setTransition(...) I can get Fragments to fade with a slight zooming animation. That is pretty cool, but it looks nothing like what activities do.
With FragmentTransaction.setCustomAnimation(...) a clusterfuck of things happen, and it looks ugly as hell.
And now I'm out of options. All I want to do is to have fragments slide left as I push to the stack, and have fragments slide right as I pop from the stack. Anybody know how to do this short of implementing my own FragmentManager?
I have somewhat gotten around the problem by placing all of my fragments into a ViewPager. I can then setCurrentItem() to scroll between fragments. It's not pretty, and it takes a fair bit of manual effort, but it runs nice and quickly.
If there are any answers that aren't as hackish as what I've done, I'll definitely accept them.
Related
Is it possible to build up an architecture like this with fragments:
Navigation drawer showing the main menu and then when clicking one of the menu items an ordinary combo of list/detail is shown (so far so good, all tutorials explain this). But what if I want a button on the detailed fragment to show a second combo of list/detail fragments, which should not be reached through the Navigation Drawer?
As I have implemented it now, one fragment instatiates the next, which is wrong according to the guides (fragments should always communicate through an activity). But it works fine as long as the user is clicking deeper into the app. The issue comes when he starts to use navigate back, because all the UIs then start to be laid on top of each other.
I wouldn't. Fragments aren't 100 percent consistent across all versions of Android, unless you're using the support library. Even then- nested fragments have always been a bit broken. They weren't even supported at first. The more levels of nesting you add, the less likely it is to work as expected. I wouldn't add more than 2 levels of fragments, and I'd try hard to keep it to 0-1.
I have a design for an app that will have a row of buttons below the action bar. Each button will open a different fragment. I am aware of ViewPagers, but I do not want the swipe between fragments functionality. I know that I can disable this functionality, but at that point is it worth using a ViewPager? I know this is a pretty common design paradigm, so how do most apps handle this sort of thing?
It seems like the ViewPager will provide some nice functionality out of the box, like switching between fragments and what not. So, I am leaning towards using one, but was hoping someone could provide some feedback on this approach.
Thanks!
Keep the buttons in the layout of your main activity. Have them call a function lets say loadFragment(Button button) on click.
This function then handles switching of the fragments, and you can change the display of the navigation buttons inside this function itself to highlight the appropriate button or something equivalent.
Google Design is always worth the reading.
Check http://developer.android.com/design/patterns/swipe-views.html for details.
Personally I have used ViewPager with tab layout for swiping purpose and it makes it easy to me to synchronise the transitions ( tabs and pages) where I put a red circle to the tab corresponding to the viewed page. With this approach I got a clean separated code.
I'm trying to find out what technique I have to use with my intended approach.
I have a layout that should consist of 3 parts: a top and right part that stay the same and a left part that can change in runtime. When the user decides to change this left part, it should display another layout at that location.
So far I've found these approaches:
ViewFlipper
Not really what I'm looking for since it's used by sliding your finger to the side instead of pressing a button
ViewPager
Seems to be pretty much the same as the ViewFlipper.
ViewStub
Can only be used once so not a viable option (I want the user to be able to change back and forth).
Sadly, none of them do the job (unless I have misinterpreted something). Is it even possible to do what I want?
If it's something not too complex, you could go with ViewAnimator.
For something more advanced Fragments are the solution.
Note: You could call setDisplayedChild() on a ViewFlipper to programmatically switch between views.
You could also call setCurrentItem() on a ViewPager (which by the way can use Fragments).
Are Fragments and Fragment Activities inherently faster than Activities?
If I don't need to load my activity in fragments, should I be using FragmentActivities and Fragments over Activities?
Reason I am asking is because I have been using Activities, exclusively, for years, and the Facebook SDK as well as Google Maps 2.0 have forced me to use Fragments, and I wonder now if they are inherently "better" or not, versus some other implementation.
If this "not constructive" or "too open ended" then obviously the answer is "no". But if there are some Google developer documents or blog on this exact subject, then I would like to be aware of it
I became a believer in Fragments in my last application. Whether or not they are computationally faster, they feel faster because you can swap them in and out basically instantaneously, including full support for the back stack if you do it right (call addToBackStack() on the transaction, or something very similar).
I now use Fragments / Fragment activity for all navigation I want to feel very quick, like clicking on a row to get more details. I only launch new activities for when I want to do a fundamentally different thing and have a clean slate to work with. For instance, I usually have a LoginActivity that deals exclusively with logins/registrations, and at least one more that is the core of the app.
But the fundamental benefit of Fragments still remains their flexibility. I can show fragments on top of other fragments, re-arrange them on different screen sizes, etc. But there are loads of other benefits. It just takes a while to feel natural (just like Activities did at first).
One caveat, I always regret embedding fragments in my layouts. I can't give exact reasons here off the top of my head, but essentially you just lose some flexibility. Instead, I build a normal layout for each fragment, and add a placeholder view in the activity layout, create the fragment programmatically, and use transaction.replace() to add it to the layout. Perhaps because this is the main way I swap fragments in and out of that placeholder view, and prefer to just have a single way of doing things where possible.
yeah, fragments are introduced exclusively for supporting large screens to use the area efficiently.handling fragments is very easy and in terms of memory.but nested fragments makes trouble
Fragments are very useful if you want to split a screen. So you can have different views within the same screen. Another way of using fragments, lets say you've got tabs to categorise items. Could have clothes, shoes as your tabs. Each tab will have a fragment to hold the products. The tabs could either held in activity or a fragment. I do find fragments a slightly faster than activities but really its not something you would really notice in most cases. Regardless if they was intended for speed or not they still seem/feel little quicker.
The downside of using fragments, is certain callbacks like onBackPressed is only in an activity. Fragments has no access to this. I often find its best to minimise how much activities as possible. Also don't forget Activities aren't just views, they're also a screen. Whereas fragment is only a view and doesn't have a screen. tool/action bars etc. are also only for Activities however if your using a custom toolbar, you can use this in a fragment by implementing onTouch(if not button but some object) or onClick(buttons) the method for these will give you what you need. So really there are some drawbacks but there is almost a workaround for at least some of them.
I do agree Fragment transition is awesome and pop the stack when working with back buttons and onBackPressed Does the trick.
I always use a switch in parent activity etc. to see, which fragment needs to be in view, i often update it using interface passing bundle etc. Not sure if anyone else has found a more efficient way or not. But I do find it really useful when switching views.
Yep fragments are top brass for most things.
I'm looking for the the best way to reproduce, in an Android app, the behavior of the iPhone UiNavigationController within an UITabBarController.
I'm working on this Android app where I have a TabActivity and 4 tabs. I've already gone through a lot of posts regarding the use of activities and tabs and how it's not a good idea to use activities for everything, which seems fair enough. I decided to use one Activity on each tab anyway, since it makes sense in my application.
However, in one of those activities I have a deep navigation tree with more than one branch and up to 12 different views the user can go through.
The problem is: Android controls the navigation through activities inside an app, if you click the back button it will go to the previous one, but if I'm navigating through views, using one Activity, and I click back, it just finishes it. So how can I have a smooth navigation behavior between views in an Activity?
I had implemented this using a TabActivity with FragmentActivity as each tab. Utilizing Fragments API you can organize the code just like you would be using 12 different activities, still using only 1 for each tab in fact. Fragment's framework will handle back key press for you to show previous fragment instead of closing the entire activity.
There are some problems with such approach, for example, there's no MapFragment, but the workarounds can be found here on SOF.
You will need Android Support Package if your minimum SDK version is lower than 3.0.
Well I know very little about UiNavigationViewController, but I guess you want something to navigate between different Views. As you are using TabActivity, every tab should load into a separate Activity.
But since you want to branch it out, using that many Activities is not a perfect solution, neither the ActivityGroup too. The better solution, as per my opinion(I have run into similar problem once) is to have the main or root tabs loads into separate Activity, but for their branches, use the ViewFlipper, which flips the Views. So the whole Layout(Subclass of View) can be flipped.
You may run into some problem while flipping more than two Views (as what people say, though I never had any problem). So in that case you can use layout.setVisibility(View.GONE) to hide the layout and just change it with View.VISIBLE for next view.
And about the concerns of back button, you need to store the last used View or Activity into a variable, and in the override of onBackPressed(), just need to call them.
There might be better solution than this, not that I can remember, but yeah it's the easiest solution I can come up with.