I'm implementing a fragment hierarchy similar to the one described in Fragments (Android Developers).
In adition in tablets in portrait the app should behave as in the second case. My problem is to handle the transaction from an orientation to other.
The first idea I considered was:
From landscape-to-portrait:When the activity A goes to portrait: Remove the fragment B to the view. Start activity B for result passing the propper values for recover the original fragment B state
From portrait-to-landscape: When the activity B goes to portrait. finishes (with the fragment 2 status in the result). The activity A with the result restores and adds the fragment B to its layout.
But this solution is pretty complex and I think it provably is not a nice idea. The alternative solution I have considered is only to have an Activity. That activity layout is:
<FrameLayout>
<LinearLayout>
<Fragment A>
<Fragment B>
<Slot>
For small devices:
The app removes the fragment B and when a item is selected add to the backstack the fragment to the "Slot"
For tablets:
Using fragmentTransactions the fragment B is moved from Its position to the "Slot" using the backstack to behave properly to the orientation changes
I think the second option sounds better but, is the correct way of doing this?
Thanks
If you want my advice, I'd say it depends on way too much factors. I think you should stick with what you find manageable enough. It depends too on how complex your app's screen flow is.
Keeping it in one activity is, for me, a good idea if you don't have that much fragments to manage. An advantage of this approach is that you don't need to fiddle around with the life cycle of two different activities.
Anyway, finding the implementation complex is in a way an indicator that what you're planning won't be manageable for you in the future.
Hope that helps!
I dont get why would you want to do it in such a complicated way. Have one activity on tablets, two activites on phone. Have first activity implement a listener that would fire if list fragment's item was clicked. The activity knows if it is inside single or dual pane mode, so inside that onItemSelected callback method, have it either start a new activity in case of a single pane mode, or replace a fragment, in case of a tablet.
You can also see this, using Master/Detail template when creating a new project.
Related
I'm trying to wrap my head around how and where i should be setting up my fragments.
Use case senario i'm trying to implement
I have a mainActivity that has a bottomNigationView widget that will open different fragments (fragment A, B and C)
In FragmentB i ask the user to input some information, then they click the next button which should should load another fragment lets say called FragmentB2
FragmentB2 should carry over some information that the user imputed from FragmentB
My question is, should i be making the fragment transactions of both fragments B and B2 in the mainActivity? Since i read online that it's not good practice to have nested fragments.
Currently, what i have is inside of FragmentB, i start a fragment transactions when the next button is clicked, so that it creates and goes to FragmentB2. I think this is whats called a nested Fragment, correct?
If you're near the beginning of your project, this is a great time to look into using a navigation controller from google's new architecture components.
https://developer.android.com/topic/libraries/architecture/navigation/
This will let you abstract the management of these individual stacks of fragments. I know this is a bit of a tangential response, but if you are worried about nesting, maybe take a step back and see if you can put together the higher level scaffolding of your navigation first.
I have a Android app that shows lots of real-time data jammed onto one large scrolling activity.
Now i want to split it up into two simpler screens using fragments, where only one fragment may be on the screen at any one time.
I read up a whole lot on fragments and watched several videos, but before i start ripping up my code to convert it to fragments i wanted to know the following.
If i create two fragments A and B, then while showing fragment B, data comes in for fragment A. Can the controlling activity still communicate with fragment A giving it data even though its off screen? OR do i have to save the data somewhere and then when the user switches to fragment A then I give fragment A the data to be shown, while saving incoming data for fragment B which will now be off screen?
The problem is that right now im not saving any data because everything is on one screen, so as data come in i just displayed it, but if i switch to using fragments i dont know if i can do the same thing by passing the data to the fragments even if they are not on screen at the same time.
Thanks.
If you retrieve your data with multiple asynchronous requests in your Activity, you may create a fragment for each of them and move related retrieval operation into that fragment (probably to oncreateView() method). Then, you can use ViewPager (probably with TabLayout) in the parent Activity to be able to use all those fragments. Therefore, your Activity only deals with setting the ViewPager and leave the rest to fragments.
ViewPager shows one page at a time but it can initialize other fragments as well, even before they are shown. You can use ViewPager's setOffscreenPageLimit() method to increase that range.
In case you need a communication channel between fragments and the activity, you may create callback mechanisms, as described here.
In a master detail flow, when I go from landscape to portrait, my detail fragment is still there.
What's the best place and time (lifecycle callback) to get rid of it? I only have to get rid of it because my menu items and actionbar title are coming from the detail fragment, in portrait mode, and so it doesn't make any sense.
In the onCreate method of your activity, you could try that:
DetailFragment detailFrag = getFragmentManager().findFragmentByTag
if( <your logic to see if portrait> && detailFrag !=null && detailFrag.isVisible()){
<Remove the Fragment using a normal fragment transaction>
}
Short answer would be onCreate
And there are multiple things you would need to know
When screen orientation change, which is one of the configuration changes, which will trigger Activity recreation.
You can stop Activity recreation by setting onConfigChange, but do NOT do this unless this is a special app, e.g. Camera
Activity recreate is trying to help you, and your case is exactly where it is needed, and you can do the correct setup in onCreate
There are multiple ways to handle the different orientation, the basic way would be to use different layout, e.g. for your layout, say activity_main.xml, you can define a similar xml with the same name, under layout-land folder. When you setContentView(R.layout.activity_main), Android will select the right layout for you depending on your configuration.
In your case, you are switching between 2 fragments and 1 fragment, there are additional works you need to handle for the fragment transaction. However, this would depends on your existing FragmentTransaction and this will go too broad to go on, so I will stop here.
I vaguely understand what fragments are used for. However, I don't understand why ADT seems to suggest that we should ALWAYS use them. I am aware that I can simply delete the fragment layout, as well as the code in Activity for the fragment. But is it ACTUALLY recommended to use fragments all the time? What are the benefits of not deleting it?
Is there even a point of an Activity having a single fragment? What is the difference with it having no fragments at all?
Additionally, how do you know whether to create multiple fragments in one Activity, multiple Activities with a single or zero fragments or a combination of Activities and fragments?
For example, if you have a Terms and Conditions button in your Activity, and you want it to open a screen containing a document listing the terms and conditions, should I be starting a new Activity for that? Or should I just move a fragment containing this content to the front?
Using Fragments is how modern apps are developed today.
Some of the benefits are a better performance when switching content (lets say 2 fragments)
because you are not leaving the current Activity.
Also, apps with swipe tabs (for example) are built with an Activity as a container and Fragments as the content itself.
Other benefit is that you can do much more with one activity, distributing work between the fragments. Each Fragment have its own Layout and therefore its own components, so maintaining the code and keeping organized is easier.
Eclipse does this way as suggesting a start point. You can totally ignore this and start from scratch. And that's all.
I suggest you to keep the Fragment to start getting used to it. Even if there is just one.
And, if later you need to work more with that Activity, it will be easier to add new features by creating a new Fragment, without modifying your previous code.
Good luck.
it is me again and i first wanted to apologize for asking that much today.
Here is my situation.
Because of my design my FragmentActivity( topmost parent in obiect hierarchy) has only one member, which for itself has a collection of objects like fragments, i have one level between fragmentactivity and the fragments. I would like to avoid some kind of event bus and/or observable pattern to pass the events of the fragments buttons to my object which would forward them to fragment activity to be then handled there.
Especially showing fragment, deleting replacing fragments is preferred to be handled in my object in between or even in the fragment itself.
Is this recommended? Or will I get into any trouble?