I see there is support for ActionBar in the Google Supplied SupportLibrary (SL_AB) - added with API 11.
http://developer.android.com/reference/android/app/ActionBar.html
I am wondering if I should use this instead of ActionBarSherlock (ABS).
Is the functionality in SL_AB comparable to ABS?
I would love to remove the external library dependency (ABS) from my project, and it seems to me this is a good approach (but not one followed by many people, and I am wondering why).
The original Support Library simply isn't that good for ActionBar usage, giving ActionBarSherlock a right to exist. Google will soon (Or is it here already?) come with a new version of this ActionBar support, as announced recently on the Google I/O 2013.
I think you're still looking at the original, not so good, library and thus you should use ActionBarSherlock.
Transferring your question to the near future, asking if you should use the new ActionBarCompat Library, or ActionBarSherlock: I would say It's more a matter of personal preference.
(Of course...) Google advises people to use this new library instead of ActionBarSherlock. However, they do bring this with the message that there is nothing wrong with ActionBarSherlock and that you shouldn't go through the trouble of replacing it in existing projects.
If you want to invest learning this new support library, it is the advised way to go. However, personally i think its a waste of time. Lots of people are already familiar with ActionBarSherlock, at lot of help, tutorials and questions about using it are on the internet to get you going and using the new lib. Probably won't even give you any real advantages.
Probably, by the time the new library is as easy to find help for, as ActionBarSherlock, people hardly need it anymore since more and more developers will drop supporting older versions that don't have an ActionBar by themselves.
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 have question about graphic design of android application. On this link you can see my ActionBar in my application using SherlockActionBar. But I want something like on this link. Where can I learn how to do something like that or where can I edit my ActionBar.
I would recommend against using SherlockActionBar for this. I've tried and it just seems so messy and difficult to implement.
In May 2013, Google released a new support library for this kind of Drawer Layout which uses fragments. It's very easy to implement and there are many examples showing how.
Edit:
i see now that on the link you provided, they were using the support library I referred to. However, I do suggest you take a look at the support library, specifivally v7, which will allow you to use the Action Bar in previous version of android, rather than relying on a 3rd-party software package like ABS.
Action Bar Sherlock, while being a neat library, as you might know, has two to three pretty invasive elements:
It forces you to inherit your Fragments and Activities from SherlockFragments and SherlockActivities. This is a sparse resource which you can't use for another handy library that might require you to do the same. Luckily the compat library isn't one of them (actually it is, but Sherlock builds on it).
It uses an Android library project. Since the tooling for these can't quite be called very stable yet, you might run into problems sooner. In fact, I have run into Eclipse bugs.
It's yet another library that makes Proguard's job harder and adds to your apk's size. Apk sizes are still a huge limitation for some users, among which Google TV users.
As such, what other possible (future) libraries, including 3rd party ones, would I be excluding if I choose to use Action Bar Sherlock? Any other limitations I'm missing?
As such, what other possible (future) libraries, including 3rd party
ones, would I be excluding if I choose to use Action Bar Sherlock? Any
other limitations I'm missing?
Frankly, I don't know of any. Most libraries which are making the use of a custom implementation of Activity(like ActionBarSherlock is doing as well) will most likely extend SherlockActivity(since almost everybody uses ABS) or if not then you could just modify it yourself. So no, as far as I can tell there won't be any limitations.
As #Jake Wharton himself pointed out this is just not true. Using the existing code and examples, it is a simple and fairly quick implementation for creating custom ABS activities and fragments.
I use library projects extensively, including having library project references that go multiple levels deep. I've run into a few issues, but nothing that was a deal breaker. Eclipse gets confused sometimes on rebuilds, but usually cleaning all the projects gets everything sorted out. Library projects are getting more stable all the time.
This is actually two points, but with a similar theme -- for any library, not just ABS, you have to tradeoff the value you get from including the library's features against the cost of doing so. I feel the value of the interface right now is worth the extra effort and apk size. This is a value decision that needs to be made on a per app basis.
#Ahmad is correct, ABS poses obvious no limitations on 3rd party libraries. It might take some coding to integrate, but they should work together. Furthermore, ABS use will fade naturally in the future. It is a compatibility library, so as the device distribution shifts more and more to Android 3+ devices, the need to support action bar UIs on 2.X devices will be less of an issue.
I'm writing an Android App and I'm trying to choose which compatibility library to choose to implement the ActionBar functionality.
I'm trying to choose between two libraries:
GreenDroid : https://github.com/cyrilmottier/GreenDroid
Android-Actionbar: https://github.com/johannilsson/android-actionbar
From what I could gather, AA(Android-Actionbar) seems to be simpler, and easier to style. But GreenDroid has additional features which make it the more powerful solution in general(not just for an Actionbar).
I left out ActionBarSherlock because it also supports fragments, is more complicated.
IF there are others that I missed, please share!
Use ActionBarSherlock.
It is based on ICS code, is actively developed, and will use the native actionbar when run on ICS. It also plays nicely with the compatibility library and will let your use ICS features such as the split action bar and share providers. Probably the biggest plus is that it uses exactly the same API as ICS. If you don't need fragmetns, you certainly don't have to use them.
Green Droid offers a custom look and feel, not exactly consistent with Android UI design guide lines. Android-Actiobnar is based on custom layouts and only offers basic features.
Here's a discussion (might be biased, since it's by the ABS author): http://corner.squareup.com/2012/05/actionbarsherlock-as-a-base.html
The Android-Actionbar is better, for sure.
Couldn't think of any other ones but I am sure there are.
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.