I know that fragments are used for making flexible UIs. But I was once asked that what is the advantage of using fragment over layout inflation. In other words we can inflate our custom layout file(one that we inflate for representing fragment UI) into the container layout of the backing activity. So why to use fragments instead?
In my opinion fragments are used over layout inflation for better designing purpose as it has its own lifecycle methods. Can anyone give me a better answer for this.
Fragments intercept Activity's lifecycle events (onCreate(), onStart(), onResume(), etc). Because of it Fragments can save and resume their state and data when your Activity is destroyed and then recreated.
So you may not save the data of your UI, when a user rotate his phone. Fragment does it for you.
Also Fragments are useful when you want to separate your UI into some units.
And with Fragments you may create your own class that builds in Activity's lifecycle.
Of course you may do the same without Fragments, but I believe that Google developed Fragments in order to improve our life and increase efficiency of our working.
Related
As the title suggests, I want to retain my fragments. I have enforced my app orientation to always be in landscape mode in the manifest file so that there will be no rotations.
I have read:
Understanding Fragment's setRetainInstance(boolean)
and
Why use Fragment#setRetainInstance(boolean)?
However, I am not sure if they apply to my situation.
My project consists of a ViewPager with swipe tabs. How can I ensure that the fragments used in the ViewPager are the same ones as created when the MainActivity first starts? Would I use the same tagging method and findfragment by tag?
Additionally, where would it be best to check for the tagged fragment, else create a new fragment?
Just a side question related to ViewPager: what can I do to immediately create all fragments used in the ViewPager when the mainactivity is started, rather than to wait for a swipe event to occur?
To answer your last question view pager will by default create the fragments around the current fragment so you don't need to worry about that part. What I would recommend is let the view pager manage your fragments for you rather changing the behaviour since you might face performance issues.
SetRetainInstance simply keeps the instance of your fragment when its detached so it's up to you to assess whether you need to use it or not.. is there anything you want to maintain about that fragment? if not then do not use it, free your memory as much as possible.
For the last question, why do you want the same fragments created from the first time to be retained ? all the time? if you NEED to do that then rethink your structuring. gracefully recreate your fragments and maybe have some caching of your data on another layer if that is what you are worried about.
I've read Activity and Fragment sections of Android API and many Q&A on these two, but I still don't have a clear understanding of some points.
When android SDK creates an activity for me, it also creates a fragment for it. From what I know I can bind several fragments to one activity and switch them as I like. But I don't understand if I ever have to add any components to activity xml file? I mean all layouting and buttons are in fragment xml. In what situations and why would I need to use activity's xml file? Can I make buttons, for instance, both in activity xml and fragments xmls? Is it a good practice?
What logic should be generally implemented in activity class and what in its fragment? For example, I think that Fragment class is needed only to get data from UI and pass it to activity. Is that right?
Thank you for your patience
An activity is basically a screen in your application (think of it as like a webpage) with all associated logic. A fragment is a sub-activity, a portion of an activity with its own set of logic and UI.
You should use a fragment when either you use the same UI in multiple activities, when you want large parts of your activity's UI to change in and out as people take actions, or when you want to rearrange large parts of your UI in different layouts. When none of those are true you should ignore fragments and just use activities directly. In my experience it ends up being about 80% activities and 20% fragments, but it really depends on what type of apps you're developing- tablet apps use a lot more fragments, for example, because they have more screen real estate.
I have a question about whether to use View or Fragment with ViewPager.
Background:
I have an Activity A that contains a ListView. Each ListView item opens Activity B. Activity B shows different content depending on which ListView item is tapped in Activity A.
Activity B's content is shown inside a ListView.
Question:
Now, instead of going back and forth between Activity A and B to switch contents, I have a requirement to implement horizontal view swiping to switch contents all within Activity B.
One solution I found (tried it and it works) is to create many instances of Activity B's ListView and use it with ViewPager + PagerAdapter.
Another potential solution found on the doc (haven't tried it) is to bring that ListView into a Fragment, create many instances of the fragment and use it with ViewPager + FragmentPagerAdapter or FragmentStatePagerAdapter.
My question is, what's the benefit of using each approach? Should I go through all the trouble of bringing the ListView into Fragment or just simply use ListView with ViewPager?
Thanks
A Fragment is a useful approach, I think, when you want to tie some UI business logic to a particular View (or group of). As you know, that individual Fragment has its own lifecycle callbacks and so forth, just as an Activity would.
Rather than having a single Activity host many ListViews through a single PagerAdapter, it may be cleaner to use the Fragment approach because the Fragment only needs to deal with the logic behind driving a single ListView.
This is a very similar situation to one I've just been facing. I'm showing various vertically scrolling forms (consisting of lots of input fields) within a ViewPager. In my case I have gone for the Fragment approach because in my case, it's possible that the ViewPager will actually need to display a completely different kind of view on certain pages. For example, on the first few pages, user input forms might be displayed. But on the final page, a graph will be displayed. A whole separate set of logic is required to drive that graph. To drive those input forms and one graph from a single Activity would get a bit messy, and I would probably need to contain the business logic in several delegate classes or something. So for me, Fragments were the obvious choice in the end. I have my InputFormFragment and a GraphFragment, and they each contain only the applicable logic for the Views that they supply.
Another thing to consider is that in the near future you too may want to display a different kind of View in your ViewPager. Or, you might want to have another UI layout altogether, perhaps one that doesn't use the ViewPager but displays them all side-to-side (e.g. a layout used on a large tablet in landscape mode). With Fragments, things are just far more modular and you could factor the code to do this quicker. If on the other hand you achieved your objective by using a single Activity that contains a simple PagerAdapter and all the logic for the ListViews within, you might find it takes more work in the future to support new kinds of Views or special tablet layouts.
One thing I will say is having implemented Fragments in a ViewPager myself through FragmentPagerAdapter and FragmentStatePagerAdapter, things can get a bit awkward if you have any special requirements; managing Fragments can be tricky sometimes. For example, for my UI I needed to be able to programmatically add and remove the ViewPager containing the Fragments. I also needed to ensure that the adapter in use didn't destroy Fragments once they had been shown, because I needed to collect data from all Fragments simultaneously at a certain point. Furthermore, I had to extend and modify FragmentPagerAdatper to make sure that the Fragments go through their onDestroy() properly and are removed from the FragmentManager when the ViewPager was removed.
Fragments enable a very modular way of constructing UIs for various screen sizes and orientations, and are excellent in how they allow you to encapsulate business logic and lifecycles for individual UI elements. However if your scenario really is just as simple as several ListViews in a ViewPager and you know that you will never need the modularity, then the overhead of Fragments could be an overkill.
I am trying to make a sudoku application. It's a fragment based design, in which a fragment hosts a custom view which is a board. I am trying to learn how to build an effective communication within FragmentActivity, Fragment and View
Although a view is created using the FragmentActivity context and I can catch a reference to that context within the current view and then call methods inside FragmentActivity I don't want to tie views so directly to a fragment activity. Instead I want to tie the view to use methods inside a fragment. How can i do that, I can I capture a reference to a fragment and call methods inside that fragment from a view?
First of all, I strongly recommend that you read through the documentation on Fragments, as you clearly don't understand the whole concept/purpose of using Fragments in the first place (which is OK, because they are confusing the first time you learn them :P).
A lot of your question doesn't make very much sense to me, because I'm not sure what the View you are speaking of refers to. What I can tell you is that Fragments have their own UI/layout, along with their own separate lifecycle. So it sounds like you don't want your FragmentActivity to interact with the Fragments layouts/methods at all... instead, you should implement the UI's behavior and layout inside of the Fragment itself. That is, the Fragment will be in charge of updating the UI, receiving click/touch events, displaying information on the screen etc. The FragmentActivity will simply hold a reference to the current Fragment(s), and will be in charge of displaying/swapping in and out new Fragments as necessary (via the activity's FragmentManager).
Hope that answers the question somewhat... read through the documentation a couple times, it sounds like you are just misunderstanding the theory/purpose behind Fragments.
can anybody tell how is fragment advantage over using instead of view in android
Thanks
Advantage is that Fragment has a lifecycle which is tied to the lifecycle of the Activity and you can control behavior much more easily.
Also Fragments can be put on backstack using FragmentTransactions which is not possible using views
Fragments are considered as sub activities to be used in one specific activities these fragment are often will reduce activity switching and reduces complexity and If view are added then these cannot have stack management
if activity viewed a view and cannot go back to previous view unless we code but in fragment has similar life cycle method it would maintain other information about previous view
Since Activitymanager even maintain the activity stack for previous menu. its similar to fragment