Android Which Fragment (and Activity) to Use - android

I have a library of Android code that I use throughout my Android projects. I created it a while back, and it uses the v4 support library (any Fragment subclasses inherit its Fragment, and all my Activitys are FragmentActivitys).
In most of my projects I have a BaseActivity class that inherits from FragmentActivity so that I don't have to worry about accidentally defining a non-support library Activity and try to use one of the Fragments from the support library. I put a lot of my application specific boilerplate in this BaseActivity.
I'm now working out the logistics of dropping support for one of my apps for devices below ICS. I have found a few issues regarding how to continue to use my Android library, which mostly boil down to whether I should continue to use FragmentActivity and the support library's Fragment even after dropping support for HC-.
I'm stuck between the convenience of "native Fragment and ActionBar and the new capabilities they come with, and the backwards compatible nature of the support library (eg, nested fragments for 4.0-4.1).
Anyone have any input as to whether I should keep using the support library, or if it's worth it to find some way to have a ridiculous amount of version checking and code overhead to provide implementations for versions that needs the support library and versions that can use the current API?

I would suggest keeping the support library implementations. This allows you use things like ViewPagers without worrying or mixing and matching implementations. It also ensures that the underlying code won't change on you until you update the support library jar.

Related

Android.app Fragments vs. android.support.v4.app using ViewPager?

I have a question regarding the Android Support Libraries, Fragments, and as a specific example, the ViewPager class. My intention is to create an app with similar functionality to the sample provided on the Android Developer website (http://developer.android.com/training/animation/screen-slide.html or http://developer.android.com/training/implementing-navigation/lateral.html). Looking into their code, I've noticed they utilize the android.support.v4.app library, which from my research is the only way to access the ViewPager class.
In my situation, I have no interest in backward compatibility. The minimum API level is 14 (Ice Cream Sandwich) and the build target is 4.2 Jelly Bean. In it's simplest form, my app performs exactly as does the second demo I linked on the Android dev website - just swiping between three tabs with content in each.
All of the articles/posts/answers I've read seem to heavily favor the v4 support library. Now for my, albeit long-winded, question(s):
What's the best way to structure my application - using android.support.v4.app, and thereby using SupportFragments, or to use the Fragments provided in android.app - and why?
If Fragments from android.app are the way to go, what is the optimal way to approach ViewPagers?
If SupportFragments are best-suited to the task, I would estimate that they possess the same functionality as the other - so what's the purpose of having them at all inside android.app?
Hopefully someone with a clearer understanding can give me a bit of clarification because I'm boggled...
You can use ViewPager with native fragments from the android.app package with the adapters from the android.support.v13.app package. You have to use the v13 support jar for that.
There are two versions of the adapters that work with ViewPager, the ones in the v4 package are meant to be used with support fragments, the ones in v13 with native fragments.
The reason why there are now two fragment implementations is historical: Fragments in the android.app package were introduced with Android 3 for tablets only and the support library was created to bring fragments to phones running older versions. On Android 4 you have both.
From my own experience I would recommend using support fragments, even when developing for Android 4. Here are some reasons: Fragment or Support Fragment?
android.app.Fragment class is deprecated since Android P (link), so only android.support.v4.app.Fragment should be used everywhere.
If you're going to target API 11+, you won't need the support library [and your actual apk will be smaller, at least).
If you want to support anything before Android 3.x, you'll need the support library.
Is this what you're asking?

Fragment or Support Fragment?

I am developing an app that supports Android >= 4.0. It uses fragments from the android.app package. As I am facing problems with the older fragment implementation in 4.0, like this one, that are already fixed in the support library, I am considering switching back to the fragment implementation from the support library to get a more reliable and consistent implementation.
What is your opinion on this? Are you using fragments from the support library, even though they are already available, when developing for Android 4?
From my experience, using the same fragment implementation on all Android devices is a great advantage. I could not get rid of all NullPointerExceptions when state is saved on Android 4.0 using native fragments, with the support library they are all gone. Also I could not see any disadvantage so far with this approach.
So my answer to my own question is now: When developing for Android 4.x, using the fragments from the support library is a good idea. The support library has bugs fixed that are still present in older fragment implementations and is frequently updated with more bug fixes.
One big reason to stick with the SupportFragment for a while is that you do not have access to the ChildFragmentManager until API 17. The support library will give you a support version of the child fragment manager.
This becomes a big deal if you have fragments that contain other fragments. This is common in tablet applications with a good deal of complexity and/or your overall architecture is based on either a tabbed layout or uses the navigation drawer.
I was also getting frustrated at having to include the support libraries, despite targeting Android 4.0+ - but it seems it is officially recommended:
The Android Support Library package contains several libraries that
can be included in your application. Each of these libraries supports
a specific range of Android platform versions and set of features.
This guide explains the important features and version support
provided by the Support Libraries to help you decide which of them you
should include in your application. In general, we recommend including
the v4 support and v7 appcompat libraries, because they support a wide
range of Android versions and provide APIs for recommended user
interface patterns.
http://developer.android.com/tools/support-library/features.html
IMHO if you are planning to develop for 4.0 only, I would recommend going with the native libraries since the executable will get smaller. It is true that you might run into problems of bugs in early versions, but I think most of these should be fairly trivial to work around. Also the compatibility library is supposed to map to the native fragments in case you are running on 4.0 and higher anyway. So you might end up having to struggle with these kinds of problems anyway.
The problem with the support libraries is that you have a lot of the classes appear 2x (once in the support package structure and once in the "native" package structure) which makes development a bit more cumbersome.
However, if you want to also release your app pre 4.0 then there is no way around the support library. Also since there are about 38% of all users on 2.3 it might make business sense to include this OS version. In such a case you can use the support library in combination with Jake Wartons ActionBarSherlock (or with googles support ActionBar Library once it is finally released).
It seems that it is better to use Support Library now because I saw the statement here https://developer.android.com/reference/android/app/Fragment.html
This class was deprecated in API level P. Use the Support Library
Fragment for consistent behavior across all devices and access to
Lifecycle.

Always use v4 Fragments instead of the build-in android.app.Fragment?

I came across the ViewPager and the related FragmentPagerAdaptor which are not part of the regular Android packages, but only available in the V4 support package. It seems I cannot use the FragmentPagerAdaptor with a android.app.Fragment since the FragmentPagerAdaptor requires a v4 FragmentManager to instantiate. Reading Difference between Activity and FragmentActivity this seems to be aligned - use either v4 Fragments and related classes or the regular android.app.Fragments. Never mix.
Taking it further, I see no need to use the regular android.app.Fragments at all since they are less powerful than the v4 support packages. (Cite from another question: The Android Support package is not only for backports of newer APIs. It is also for other classes that, for whatever reason, are not being added to the SDK, such as ViewPager and its supporting classes.). The "only" downside I can think off is that the v4 support libraries is bundled with the APK which means my app will take up more space.
Am I correct to conclude that I should always use v4 support libraries for fragments since those include more functionality? (And they are backwards compatible, not to forget.)
I just realized that it is possible to use the android.app.Fragment and the android.support.v4.view.ViewPager together... If you use the android.support.v13.app.FragmentPagerAdapter... So it seems that the v13 support package solves/improves the compatibility issues between android.app.Fragment and android.support.v4.view.ViewPager. What a mess.
While this resolves the particular example I came up with, I am still wondering if the best option is to always use v4 classes when they are available instead of the build-in classes (e.g. android.app.Fragment) even if I am only worried about ICS and newer devices?
In terms of backwards compatibility, indeed using the v4 support package version is the best approach.
As the shift of devices moves towards the operating systems that have the functionality built in it will probably become easier to use the SDK version, as all of the functionality found in the support package will be included in the SDK.
For now, stick with v4 to offer support for 2.2/2.3 devices which still hold a large share of the Android device pie

"The type TabActivity is deprecated" For app tab

"The type TabActivity is deprecated"?
I am making the Tabs of app following tutorial book.
I've checked from the android developer.com website, but i have no ideas on the significance of the following message : This class is deprecated.
New applications should use Fragments instead of this class; to continue to run on older devices, you can use the v4 support library which provides a version of the Fragment API that is compatible down to DONUT."* (http://developer.android.com/reference/android/app/TabActivity.html)
What is v4 support library?
How to finish the tab functions?
You can still use a deprecated package. It is however recommended to use Fragments, and thus the support package. You can read more about it here. However, if you are a beginner at java and android development, I would recommend ignoring the deprecation for now and come back to this when you have completed the tutorial you are currently using if you find it educating.
If you want to watch a nice example of tabbed navigation using Fragments, then create a new project in Eclipse using android 4.0 or later. Make sure your android-plugin is updated. You will get the option to create a project with basic navigation already implemented.
"Deprecated" means that the api developers don't recommend using it anymore, probably because its not a good model, or inefficient, etc. Fragments were introduced in Honeycomb and can be used to provide a similar functionality as tabs and is more in-line with android's current design philosophy.
Since Fragment was introduced in Android 3.0 Honeycomb, you might think you cannot use that for pre-Honeycomb devices. Enter Support Libraries. They are libraries which you can include in your application which needs to run on pre-Honeycomb and still use this class.
So if you want to, you can finish the TabActivity as described in whatever tutorial you are following, it'll probably work on a few more upcoming android versions. But it is recommended that you start using Fragments.

ViewPager with indicator without Android's support library

Right now I'm using the ViewPagerIndicator for swipe-able fragments with an indicator in my program and it's working like a charm. But since Google is pushing more and more into the direction of Fragments without using the Android support library and e.g. PreferenceFragments aren't available in the support library, I'm wondering if there is something similar to the ViewPagerIndicator that's using the standard Android library.
Google is pushing more and more into the direction of Fragments without using the Android support library
And your proof of this is... what, exactly?
e.g. PreferenceFragments aren't available in the support library
It is not possible to backport PreferenceFragment very easily, as there are many other requirements to make that useful (e.g., backporting the new PreferenceActvity). I have personally looked into backporting the preference fragment system and concluded that it would be significantly more pain than it is worth to me.
I'm wondering if there is something similar to the ViewPageIndicator that's using the standard Android library
By definition, that is impossible, as ViewPager is in the Android Support package, which means any indicator for ViewPager must use the Android Support package.
However, there is nothing about ViewPager that requires you to use fragments. You are welcome to create your own PagerAdapter implementation that does not use any fragments, or uses native API Level 11 fragments, if you so choose.

Categories

Resources