Let's say I have an Activity with a certain content. Now I need to create a new screen with tabs, so that the content of this activity will become the content of one of those tabs. I know I can do tabs with ViewPagerIndicator, for example. But, in order to do that, I need the screens to be implemented as Fragments. The problem is that the current implementation relies heavily on the Activity hierarchy (lots of calls to methods on the superclass, etc). So, I cannot simply make the current class extend Fragment. What other options do I have in this case?
Now I need to create a new screen with tabs, so that the content of this activity will become the content of one of those tabs
Having activities be the contents of tabs has been deprecated as a technique for nearly three years.
The problem is that the current implementation relies heavily on the Activity hierarchy (lots of calls to methods on the superclass, etc). So, I cannot simply make the current class extend Fragment.
Replace most of those "calls to methods on the superclass" to use getActivity(). as a prefix, where relevant.
What other options do I have in this case?
You could remove the activities entirely and rewrite your UI as custom views. This would be more work than converting them to fragments.
Or, you can just not do tabs.
So, I cannot simply make the current class extend Fragment.
That sounds like you have a huge Software architecture problem. In this case you may consider a complete rewrite (or more a copy & paste rewrite)
Normally it should be really straight forward to "convert" a Activity to a Fragment.
Fragment has nearly the same lifecycle callbacks:
Activity.onCreate() ---> Fragment.onCreateView() etc.
You can also access the parent Activity of the Fragment by calling Fragment.getActivity().
I don't know your code, but it should be definitely possible to "convert" Activities to Fragments.
You may split your activities code in own classes and inject them to the Fragment.
There is not really a alternative I could recommend you!
If you want tabs, use a ViewPager with Fragments. DO NOT USE OLD DEPRECATED STUFF like TabActivity
Related
I used to have 3 activities with 3 layouts.
1. HomeActivity.java (activity_home.xml)
2. HelpActivity.java (activity_help.xml)
3. SettingsActivity.java (activity_settings.xml)
Whenever i had to open other activities, i used animated slide-in-out intents using overridePendingIntent. In this way, all the variables of HomeActivity stayed in itself and HelpActivity's variables/methods were in itself and same for SettingsActivity. I used onCreate() in these to perform some activity specific code. and, android:onClick="fetchSarcasm" from activity_home.xml was calling specified method in HomeActivity.java. So, there were no conflicts. All the normal things, that happen in an AndroidProject with 3 activities and used intents to switch to one another, were happening as i wanted.
But now, I wanted to migrate to ViewPager instead of slide-in-out intent transitions. In this way, there will be only one Activity with an XML of ViewPager. This ViewPager and its FragmentPagerAdapter gets the Pages from 3 classes extending Fragment with relative XML layouts.
I want to ask: Where do i write my Page Specific Code for onCreate(), layoutView's onClick="" and for onChangeListeners. Because, 3 classes extending Fragment do not have any Context or findViewById() and they do not respond to android:onClick="method" in different layouts.
Do i need to mix all that code of three activities into one containing ViewPager? If so, this makes ViewPager activity pretty heavy. and, writing if(page=2){ dothis(); } seems absurd for all pages at every code point. Any checkbox(view) that is in page 3, becomes null in other pages.
I know this might be a stupid question. I have spent almost 4 days trying to achieve something but i can't. Also, this is just my 2nd month in android, so i am new. I do not use Action Bars, Tabbed Bars or Navigation Drawers.
I am available on SO Chat too if you want to ask something more.
I just want to know how do i merge all the work i did when I was not using ViewPager.
If you're only reading the Preferences once for each Fragment, you can move your previous Activity.onCreate() logic to each Fragments onViewCreated() or onCreateView(). Read your shared Preferences there and set your Checkboxes accordingly.
Fragments inside a ViewPager aren't necessarily recreated on each page change. You can change how many Fragments are instantiated at a time with ViewPager.setOffscreenPageLimit(int).
Fragment Lifecycles explained
What scenarios using fragments what scenario using the activity , How can I make sure you when to use the activity when using fragments ！
Basically, when you want a fixed portion of the screen and the rest will be changing, you want to use fragments.
If all your app is going to be on different screens, you want to use Activities.
Anyway, at least you will need one activity to hold your fragments.
Hope this helps.
As i know,You need to extend the fragment when you are displaying the view into tabs.
Otherwise you can extend activity.
It depends on your requirement. if u want to expose your toolbar throughout your application you can use fragment both activity and fragment are quite similar . You can also use only one activity remaining things may be your fragment
It depends on UI which you are creating.
If you are creating Multi-Pane UI then you should use Fragment.
And if you are creating some part of screen which can be reused then for that part you should create Fragment as Fragment is meant for re-usability.
If you are creating stand-alone screen then you should use Activity
For more info please refer this link How to choose Activity or Fragment if both scenarios are possible?
I have implemented ViewPager and number of Fragment as child, here every child override own onAttach, onCreateView, onViewCreated and setUserVisibleHint.
In my app navigation behaviour is random, it not be in sequence every time. Since page viewer perform caching to load extra child, and this is what my problem is. I am not sure exactly when I should initialise/release member of child class.
Required suggestion from you guys, will it be preferable to use PageViwer in this case or I should go with traditional activity flow for each of component.
ViewPager is typically used for move efficient horizontal item to item navigation. Typical use cases would be
Swiping through the related items (e.g. emails, images, songs of an album, etc.)
Swiping between the tabs
Swiping back-and-forth in a wizard-like activity
For more details you can read a section about Swipe Views Android Design pattern.
Regarding the lifecycle, it basically uses the same lifecycle as any other Fragment. The only difference is, that lifecycle methods can be called a bit later or earlier than you expect, because of fragment's caching ViewPager implements.
I am not sure exactly when I should initialise/release member of child class.
You should basically rely on two methods: onStart() and onStop(). In onStart() you create class members and initialize everything you want to. In onStop() method you should deinitialize everything and remove all listeners you set in onStart().
Method setUserVisibleHint() is used independently of onStart() or onStop(). You shoud better not initialize or destroy anything in there. You must not consider it to the a lifecycle method, because it's not. It's there just to give you a hint, that your fragment is visible to the user. Here you can start or stop animation, or request data update or perform similar tasks. This is the only purpose of this method.
Required suggestion from you guys, will it be preferable to use
PageViwer in this case or I should go with traditional activity flow
for each of component.
If your activity fits into one of the points mentioned about, I would suggest you to use ViewPager. Otherwise you might consider other options.
Update: Most likely you won't override onCreate() and onDestroy() lifecycle methods of a fragment very often. You will use onCreateView() and onDestroyView() methods instead. There you can implement so called static initialization, the initialization which doesn't change while a fragment is still alive. This is layout initialization and similar tasks.
ViewPager Usages
Screen slides are transitions between one entire screen to another and are common with UIs like setup wizards or slideshows.
If you have good knowledge in Fragment than ViewPager is right component for implements.
Because viewpager provide a place which you can add fragment runtime.
For eg.
If you want to use TabBar in your project than viewpager is right component for using. Because it's provide a place which you can add Fragment runtime. Tabbar is common in android application. It's provide lot of functionality inbuild we can use to add fragment runtime.
Facebook app using ViewPager to manage tab. Viewpager provide smoothness of your application.
You can Download example from this url and check your requirement fulfill or not
You can download the Example here
ViewPager
It is an widget
Allows the user to swipe left or right to see an entirely new screen.
Easy to show the user multiple tabs
Dynamically add and remove pages (or tabs) at anytime.
To Read More: http://architects.dzone.com/articles/android-tutorial-using
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've started developing Android apps and I am wondering which way is better in case of adding fragments to activity. Let's assume that view for activity contain always three fragments. They won't changed. Always be the same. Thus is it better to add them by tags or include them in the activity code?
And a second question issue:
Let's say I have activity with fragment which is a list. Then when I clicked on item I want to show new view. Can I then replace the list fragment with new completely different fragment? Even if the answer is yes then is it better than creating new activity?
Thanks for all replies
which way is better in case of adding fragments to activity
One approach is not necessarily 'better' than the other - they both serve their own purposes, as with any static vs. dynamic comparison.
For example, fragments declared in a layout cannot be given arguments using setArguments(). Such a fragment can also not be replaced by another fragment: if it's part of the layout, it'll always be there. Of course you can still show/hide the instance, but attempting to actually remove it through a FragmentTransaction will simply not work. Static elements are usually easier to work with though, because they have a well-defined lifetime and behaviour.
Regarding your second question: yes, that's very possible. Some developers build their app around a single Activity container, swapping out fragments as the user navigates its way through the content. In most cases, from a user's point of view, there is little difference between doing this or having multiple activities. The important thing to keep in mind is to choose an approach you're comfortable with, doesn't overly complicate things and takes advantage of the patterns explained in Implementing Effective Navigation.