multiple fragments - where to commit them? - java

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.

Related

Managing fragments in Android

Hello i am fairly new to android development and have been using Activities to navigate through my app. Now that i have gotten my feet wet i'd like to write more efficient applications. From what i have read, fragments are a way to limit the creation of unnecessary Activities and reuse UI elements.
I am trying reduce the amount of activities in my applications by converting them to fragments. When a button is clicked, do i call the next fragment from the current fragment, is this good or bad practice? What is the role of the main activity if fragments are directing the flow of the application?
Fragment is good practice but you need more careful handling fragment because it's tight coupling is when a group of classes are highly dependent on one another.
read this tutorial it will help to understand fragment flow [https://guides.codepath.com/android/creating-and-using-fragments]
Fragment is view and Activity is parent View (MainController is must be actvity)

Do fragments keep running even if not on screen?

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.

Android Fragment: Fragment should manage itself being shown/deleted

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?

Adding tablet support: Fragments and Activities for Master/Detail (Android)

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.

stack activity in android

Hi i am working with android , and i have a problem with the activity stack. As i know, when someone uses the back button, reload the back activity. But in the case i have many layouts shown from one activity, how can i go back to them.
Here is the deal, i am using a listview filled with categories, and when i press an item, i reuse the activity and the layout, to show its subcategories. So what i need is to came back no to the back activity, not to the back layout, but to the back "state".
Well, the idea is simple, first i show all the categories with no parent, then when i pressed an item, i show its subcategories.
The easiest way is creating two Activities - for categories and for subcategories. If you try to implement all the logic in a single Activity you won't earn nothing and just end up totally confused. Using Activities simplifies things a lot just because it handles problems such as yours. Hope this helps.
Check out Fragments, they are the stepping stone between a view and an activity. An activity can have multiple fragments and will manage their back stack (if you tell it to).
http://developer.android.com/guide/components/fragments.html
You'll have to use the support library to used them on pre honeycomb devices.

Categories