I've been thinking about the pros and cons of using Android's Support Package when targeting the latest API and setting the min SDK to 7, for example.
The Android documentation states "The goal is to simplify your development by offering more APIs that you can bundle with your application so you can worry less about platform versions"; however, I'm having some doubt on whether it will make it simpler.
Consider the TabActivity, which has been deprecated. The alternative to using TabActivity is through Fragments and by looking at the example to get a tabular view working, it doesn't look simpler. Besides, I have to use reflection anyways when deciding on to use the Fragments class versus the FragmentActivity class, so why not just use TabActivity. I was hoping to get your opinion on this. I'm leaning towards not using it, but I would like to know if I'm missing out on any benefits.
The alternative to using TabActivity is through Fragments
An alternative to using TabActivity is through Fragments, using the icky stuff in the example you cite. The better alternative to using TabActivity is to put your tabs in the action bar, perhaps using ActionBarSherlock's fork of the Android support library that offers a backwards-compatible action bar.
by looking at the example to get a tabular view working, it doesn't look simpler
It's not.
Besides, I have to use reflection anyways when deciding on to use the Fragments class versus the FragmentActivity class
If you are using the Android support library, you should not need this, as you always extend FragmentActivity.
I'm leaning towards not using it, but I would like to know if I'm missing out on any benefits.
If you plan on supporting tablets and/or TVs, you want to be using fragments. Fragments are useful even in phone-only apps, but not quite as visibly.
Related
"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.
This is not a duplicate of How can I use fragments, now that TabActivity is deprecated?
After some research the conclussion is that TabActivity is deprecated because we now have to use fragments. And the reason for that, as far I read, is that fragments work better with the action bar, and with the support compatibility library it's also possible to implement starting at Android 2.1
But I still don't really understand the reason why it's deprecated. Why not just make that the action bar also works with activities? Why are fragments prefered?
I also read fragments have better performance... is that the reason?
Activities at least are cleary separated entities which is something positive. I don't have enough insight in fragments now to understand why they are better.
Thanks in advance...
TabActivity has been deprecated, cause it is subclass of ActivityGroup, which also has been deprecated.
ActityGroup has been deprecated, and instead Fragment has been introduced and suggested. As using Fragments is easier and more flexible than ActivityGroup. It also enable android components to have a homogeneous pattern.
The main reason for which Google deprecate some methods / objects is to enforce best-practices and get the most homogeneous patterns accross applications.
Marking TabActivities as deprecated will make developpers use the ActionBar system for new applications, but you still can use TabActivities, although it's not encouraged.
Sometimes, They will mark something as deprecated for performance or because the behavior is not up to date with the latest API (for example the Clipboard system, changing from a "text only clipboard" to a "copy and paste anything".
I'm looking to create a cross-version compatible android tabbed layout.
The problem I'm running into is when implementing Google's example of TabActivity, I get a depreciation notice. The app I'm writing needs to be compatible down to 2.1, and I'm not finding a clear cut way to make it compatible.
I am aware of the versioning by folder (/layout-v4, /layout-v14, etc) but if possible I want to avoid this.
Are fragments the answer here and if so, does the Android Compatibility Layer V4 become the key to solving this problem?
I'd suggest the best approach might be to use the excellent (and free) ActionBarSherlock, so you can add Android 3+ action bar (including tabs) to apps going all the way back to v2.x versions.
I've used it on a few apps and it's pretty easy. I think it's the right approach to use the proper Action Bar interface across platform versions, and they include tabs and replace the whole TabActivity thing, which was pretty horrible anyway.
http://actionbarsherlock.com/
I just started developing on Android. I'm practicing with a Tablayout tutorial in API 15 when I see TabActivities are deprecated.
Would I be better off just forgetting about Fragments for now and keep developing with TabActivities?
Would I be better off just forgetting about Fragments for now and keep developing with TabActivities?
IMHO, no.
Get yourself a copy of ActionBarSherlock and implement tabs in the action bar. That is the tab pattern going forward with Honeycomb and Ice Cream Sandwich, and ActionBarSherlock lets you use the same approach for Android 2.x devices as well. You are better served aiming for the future, not the past.
Note that you do not have to use fragments with action bar tabs, though you can.
I suggest you learn Fragments. There's no point in using TabActivities any more, there's a static support libary (you can see it available for download in Android SDK Manager) that will allow you to use fragments on older APIs - that's the way it's meant to be done now.
Go with Fragments and action bar pattern, new is always better :)
Also, be ready to dump any other deprecated piece of API or obsolete UI approach. Mobile development evolves pretty quickly.
No, just follow the example here for how to Tabs with Fragments: http://developer.android.com/reference/android/app/TabActivity.html
Normally, I would say that using a deprecated API is a bad idea. However, since you are just practicing and presumably do not need to release this application on a wide range of devices, then just carry on with the tutorial and happy learning.
Hope that helps and enjoy Android.
I have to write an app for both phones and tablets and I would like to use the same project for both. It seems the use of compatibility library is good to write reusable code.
Is possible to share the same Fragment class for both?
I'm thinking about a starting activity that "forks" the app in pre-honeycomb activities and post-honeycomb, reusing the same Fragment classes. The fact is if I include android.app.Fragment, the fragment will not be usable from a FragmentActivity and viceversa.
I could use only FragmentActivities, but this would prevent the use of the actionbar.
How to do this?
The solution in the example here does not seem to be appropriate.
For contacts the problem is that there is a class that is deprecated but you can still compile it.
With fragment if you refer to android.app.Fragment you can't compile that class with the sdk < 3.0 while if use import android.support.v4.app.Fragment you can't compile for honeycomb (you can only if you keep using the support lib even on honeycomb that does not seem to be the best thing to do).
I managed to do it only by having two different projects that expose two different implementations of a proxy. Than I use the right implementation for each sdk. It is not as simple as it looks because you will have to make a proxy for FragmentTransaction, FragmentManager etc.
It worked for me but it did not work for settings with fragment. In that case the xml files that use fragment can't be compiled with pre honeycomb sdk.
Yes you can share the same Fragment class for both. You don't want to be touching actionbar code on the phone (pre-honeycomb) so an easy way is to simply hide your actionbar code in an adapter class that you only make use of in your Fragment for honeycomb+, see answer here.
One thing that you can then do is make use of version/size specific resoures such as menu, menu-v11 etc to add say menu items to either your action bar on a tablet or the standard menu pop-up on a phone.
You could use ActionBarSherlock which is a compatibility library that integrates and builds on Google's own compatibility library but provides backwards-compatibility for the Action Bar as well as fragments and all that other good stuff.
It uses the native ActionBar classes provided by API 13+ so the code should be re-usable for your "forks" (or you may not have to fork as much/at all).
Worth having a browse of the website...