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.
Related
So, in order to support ActionBar on Androids < 4, I had to include the appcompat-v7 library. This library adds quite a bit of overhead in form of code and images (~600KB).
So I was thinking I might change the project a bit and generate separate packages, one for androids < 4 and one for newer androids. This should not be hard since the appropriate imports and definitions are only in a few source files (<5)
Subquestion: is it even worth the bother given that the only perceived gain is reduced package size?
Anyway, since this requires a modification in build.gradle, is this even possible?
How can I make this work? Naturally, when debugging, Android Studio should "know" what flavor to build when deploying to appropriate emulator (even if it's always the one with appcompat). I don't want to have to work more because of this.
Sorry this is an older question, but I came across it while googling something similar. I found this great blog that answered a lot of my questions about flavors, and how to use them: http://blog.robustastudio.com/mobile-development/android/building-multiple-editions-of-android-app-gradle/#comment-940
In your circumstance, however, I wouldn't use flavors. I would instead use a support library: http://developer.android.com/tools/support-library/setup.html They will allow you to use cool new features of modern Android OSes without your users actually having that version. Good luck, and I hope this was still relevant!
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 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.
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 would like to add two versions of my app to the Android Market, one for a few cents, and one free version, with ads. That's a very common practice.
I'm currently building AdMod into my app, and it seems I'll have to change quite a few files, so it seems best to make a separate version of my app for this.
How do you achieve that? A branch? A different repository? Has anyone found a way to keep both apps in the same repository in a reasonable manner?
The title is not misspelled, I do mean "realise", i.e. how people manage the two versions, not how they add them to the Market.
This kind of thing is a complete nightmare - unfortunately the Android build system doesn't really support it in any good way.
We do it by having 99% of the code of our application in a library project. We then create one application project for each different version of the app, each of which use that library.
Where we need different versions of the app to behave differently, we currently achieve that by having different resources that are queried at runtime. We are in the process of moving to using Dependency Injection via RoboGuice, however.
There are elements of this that work reasonably well, and others that don't. It's necessary, for example, to duplicate the AndroidManifest.xml file, which can be error-prone (it's easy, for example, to add a new activity to one manifest and forget to do so in the others). It's a mess, unfortunately, but the least-bad solution we've found.
Personally speaking, I would strongly advise against using branches to achieve this effect. They can work well initially, but will rapidly become a maintenance nightmare.
One side benefit of using a library is that we've found that it makes testing considerably easier. For an example of how to set this up, see:
http://www.paulbutcher.com/2010/09/android-library-project-with-tests-step-by-step/
People usually upload them twice(like two different programs) and just modify the title for adding something like Ad-Free, Donate and things like that. And on the free version just add the Free label and also put on the description that it's Ad-Supported.
Here is an example with the SMS Popup application:
For the Android Market, they are considered different programs, but for us it's the same, but one is Ad-Supported and the other isn't.