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...
Related
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.
"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.
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.
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'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.