Considering Android Design Guidelines announcement what is the best way to make apps which are compliant with them on Android 2.x phones? E.g. what is the best way to implement the ActionBar pattern?
ActionbarSherlock is a starting point. It includes the compatibility libraries from Google and comes provided as a project rather than JAR offering greater flexibility, should you need to alter anything. Version 4 is on the way which will also include ICS stuff.
As far as I am aware I believe ABS is backward compatible to 1.6, and makes use of the minSdkVersion and targetSdkVersion. It uses an extended version of the holo theme to create a light and dark version that includes the extra ActionBar goodness, which in turn you can extend to style your app.
I recorded a tutorial on YouTube to get people started.
I think it's better to use the compatibilty libraries directly, instead of another library based on those. Additionally, refer to the Google I/O App as stated at the bottom of the first link I gave. You can find the best practices about implementing a UI for several devices with compatibility libraries.
I found ActionBarSherlock to be pretty good. It will emulate ActionBar on older devices and use the native one on modern ones. It's an extension to Android compatibility library - so you will also get fragments and other ICS stuff.
Related
I want to use an ActionBar for Android 4.0+ (API 14 and above).
Do you recommend still use ActionBarSherlock, the support library or the native library?
What's the difference between ActionBarSherlock and native ActionBar in Android 4.0+?
Thanks
If you're not supporting older devices, there's no reason to use a compatibility surrogate.
I'd go for the native library.
So, not to add extra weight to my app and take advantage of what I already have.
In the other hand, if and external library would offer so many extra features, I could consider it.
Better if it's open source, so that I can cut off all the features I'm not interested in.
Reading through official documentation of Android made me little bit confused about this 2 libraries. When should I use one and when the other one?
As far as I'm understanding, it's the best to use Android Support library depending to the number of devices that will be able to run it and the look will stay always the same. No matter what might get in the future of the android, Support library will always be supported on any future Android API. But why is then DialogFragment for android.app? It is logic to me that android.app.DialogFragment has some benefits which that from support's doesn't because anyways it would be useless to have it, since it's not supported on so many devices.
Can you help me which I should prefer to use it and if my sayings were right?
If your app needs to be compatible with Android 2.x you should use the DialogFragment from the Support Library. Notice that adding the Support Library to your project makes your app bigger because the JAR of the Support Library will be included in your APK.
If you only support Android 3.x or higher you can stick with the DialogFragment built-in into the OS.
Both versions of the API offer (roughly) the same functionality.
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.
Google has a great resource for Android 4.0+ Design Guidelines. But there is still a large percentage of Android users running 2.3.x.
What is the easiest way to use the latest design guidelines while still maintaining backwards compatibility with older OS versions? There are a lot of special menus and navigation tools in the guidelines that are probably Android 4.0+ only. Do they gracefully fall back to basic elements for older versions of the OS? Do you have to create a whole separate view/template for each major Android version?
What is the best approach to adopting the newest guidelines with leaving a large percentage of users out in the cold?
Use ActionBarSherlock and the HoloEverywhere libraries, as well as the Android Support libraries.
There is a support library from google (link) that ports back many of the Android 4 UI Features. You may look at the feature list on their homepage for details.
Furthermore, there is Actionbar Sherlock by Jake Wharton. This a is an extension to the Compatibility Actionbar that offers more features than the original from google. (link)
"Do you have to create a whole separate view/template for each major Android version?"
The answer for this is No, All you need is a single apk for all the Android versions,
But the UI would be changed depending on the OS version and screen size.
Android provides a number of support libraries for doing this.
The latest design guidelines are compatible only for Android 3.X (Honeycomb) and higher.
For the earlier versions, the UI would behave accordingly.
Please go through Android documentation about support libraries, and there you can find some samples too.
But if you want the same look for all the versions of Android, then you have to go for third party libraries like Actionbar Sherlock.
What is an ideal approach when developing apps using android 4.0 and making it work in android 2.3, I have already imported compatibility library and Android Sherlock? on my project?
Should I use the coding practices of 4.0 until my app is in shape before I apply compatibility practices?
OR
I should apply the compatibility practices together with the project's progression (which is kinda hardcore.. for a beginner of the compatibility library like me )?
I would appreciate your opinions.
I may be a bit biased, but by using the Google support library, ActionBarSherlock, and NineOldAndroids you are afforded all of the major new features introduced in Honeycomb to 99% of all devices that have access to the Play Store.
Having easy access to fragments, loaders, the action bar, and the new animation API on Android 2.1+ allows for you to focus on the actual content of your application rather than any API differences.
Action Bar Sherlock is meant to replicate the Android 4.0 experience as closely as possible on legacy systems, so I suggest you use it in that spirit. Try to develop clean Ice Cream Sandwich code, just keep an eye on whether ABS supports it. Most of the time, it will. If it doesn't, find another way. Every time you finish coding up an Activity would probably be a good time to step back and do a quick Gingerbread sanity check.