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.
Related
Android documentation encourages to use Fragment Dialogs on older versions of ADT by adding the support library. It claims that just using Dialogs can issue some memory problems. However when I added support library to my project it increased my footprint from 400K to 700k, so my application is just same size as the support library. It was a price to just show one simple dialog.
So question is really I have to sacrifice my application footprint by adding the library because Dialog implementation has real problems, and in this case I had to do that, or I can live with standard dialogs implementation?
Attention to moderators, it isn't duplication of How Android Support Library work?
since I am asking of an impact not using fragment dialogs and the support library on an application stability.
I think if you are only running API 10 and lower, but nothing higher, you might not want to add the support library. Seeing as you won't be using anything else (I'm guessing here from what you are saying), the footprint might not be worth it. The support library is meant for backwards compatibility, and since your intent is not to do that, remove it and use plain old Dialogs. If they are not deprecated then I don't see why not. Just make sure there are no performance issues (which is my guess as to why the doc encourages the use of the DialogFragment).
That being said is there any reason you are designing an app like that (pre honeycomb only app)? You really should be using Fragments. If you really don't want to use the support library, then design your app for API 12 and up. Not supporting older versions is more viable solution nowadays (if the adoption metrics mean anything). Plus its tried and true, so you will encounter less problems with the support (no pun intended) around it.
I understand that for Android below 3.0 i need to use ActionBar from v7 support lib
My question is how v7 ActionBar behaves on phones above Android 3.0. Does is use native ActionBar or v7 ActionBar?
I am asking if v7 ActionBar on phones with Android 3.0 and above will be of less quality
(may be less features) than regular ActionBar
Thanks
If you decide to use ActionBarCompat - all your devices will get action bar from compat library. Of course you can have some really tricky API version checks and choose one over another in runtime, but efforts and code complexity just don't worth it. I wouldn't say it is going to be "less quality" since Google guys are really trying hard to make it look the same. Also Im pretty sure list of interfaces is exactly the same as native implementation.
From another hand, there is obviously a risk to hit some nasty bug which is not present (or already fixed) in native implementation, so it is all up to you to take this risk to the benefit of supporting older platforms.
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.
Is there a easy way to have our application look like ICS or JB?
Mainly the slider and the radio button. They look old when displayed in green.
Any hint about this?
There's a nice package available on github called HoloEverywhere.
One thing though, do not try pass it off as a ICS/JB Application, just because it "looks" like the user interface one would expect to see in a native ICS/JB Android set up.
Best that can be done with the project, is to target the latest SDK to guarantee your wide-market of Android usage, including GB.
Aim high, not low ;)
The best way is to use the Android Library 'Actionbar Sherlock'. This Library uses all native ICS Themes, etc for older devices.
ActionBarSherlock is an extension of the compatibility library designed to facilitate the use of the action bar design pattern across all versions of Android with a single API.
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.