After learning some basic rules to work with ActionBarCompat, you will probably need to migrate some apps from ActionBarSherlock to ActionBarCompat, because it provides better integration with some other functionalities such as Navigation Drawer, and there are some issues that you must know to make it easy. I’ll be replacing Bandhook Action Bar while writing this post, so there may be some points I won’t cover if I’m not using them. Please feel free to explain in comments section and I will add it.
< ActionBarCompat (Part 2): Action Views
Import AppCompat project
As I explained on a previous post, an apklib project is required to use ActionBarCompat. Gradle allows some easier integrations in Android Studio, but I can imagine most of us still use Eclipse or IntelliJ, so the easiest way will be to import as a project or module. Remember you can find it at sdk\extras\android\support\v7\appcompat. Adding both jars under libs into the main project may also be necessary.
Replace SherlockFragmentActivity with ActionBarActivity
ActionBarActivity is the new activity to be used with ActionBarCompat, and it allows the use of fragments. If you have any other kind of Sherlock Activities, replace them too. There shouldn’t be any problems even if you are not using fragments.
Replace SherlockFragment with Fragment
Use support-v4 fragments instead of the ones in ActionBarSherlock.
Change Menu, MenuItem and getSupportMenuInflater() references
AppCompat will use native ones instead. ActionBar package reference must also be modified. Modify menu xml resources as explained in previous post.
Modify the way you get Action Views
If you read part 2 of this series, I explained there’s a compatibility class to do this task. It won’t fail on new versions if you don’t change it, but old versions will crash.
mSearchView = (SearchView)MenuItemCompat.getActionView(mSearchItem)
Modify your Themes and Styles
Make your theme extend some of the AppCompat ones. For instance, you can use: Theme.AppCompat.Light.DarkActionBar. Replace every Sherlock appearance in styles with AppCompat. Alternatively you can use Action Bar Style Generator, which is already optimized to work with AppCompat.
And that’s all! I got ActionBarCompat working on Bandhook easier than I expected. Jake Wharton did a great job, as he explained in its own blog, when creating its library to be easily replaced.
15 thoughts on “ActionBarCompat (Part 3): Migrating from ActionBarSherlock”
Can you elaborate on what reasons there might be to switch from ActionBarSherlock to ActionBarCompat? If I already have an application using ABS and it’s functioning properly, when would it be worth converting from ABS to ABC (the implication being that it would be at the expense of working on other parts of the app)?
This is definitely a really great blog series about ABC and I’ll definitely use it in the future, I’m just a bit confused about ABS vs ABC.
Nowadays it isn’t necessary at all apart from the easier integration with NavigationDrawer, and it’s possible that we never find this need because the use of 14 as min sdk is not so far. But future support library updates may include more incompatibilities. Anyway, I can’t see many reasons why you need to update your code if it’s already using ABS and everything works properly.
If you want to use the MediaRouter from the support libraries (v7), e.g. to implement ChromeCast support into you app, you must use the ActionBarCompat v7 – the opposite to loose coupling and a good design. ActionBarCompat looks like a badly copied ABS with less support (PreferenceActivity for example).
A while ago you also published a post about unit testing with Robolectric. I was wondering if you have gotten ActionBarCompat to work with Robolectric. Setting it up for unit tests the same way as ABS is unfortunately not possible with the support library.
I haven’t yet tried anything like that, sorry.
I believe this is bug of robolectric. I have filed this problem https://github.com/robolectric/robolectric/issues/1166
How do I integrate the ABC in a PreferenceActivity?
I didn’t deal with it yet, sorry. I’m not sure even if there’s a way. If you find something, please let me know.
Integrating PreferenceActivity with ABC is not possible, at least for me. I tried the two posiibilities I could find but none worked:
Option 1: ActionBarPreferenceActivity extends PreferenceActivity. When you do this you get restricted by ActionBarActivityDelegate.createDelegate(ActionBarActivity activity). Also you need to implement ActionBar.Callbacks which is not accessible
Option 2: ActionBarPreferenceActivity extends ActionBarActivity. This approach requires rewriting a whole new PreferenceActivity, PreferenceManager and may be PreferenceFragment which means you need access to hidden classes like com.android.internal.util.XmlUtils
The solution to this can only come from google devs implementing an ActionBarWrapper that can be added to any activity.
If you really need a preference activity, my advice for now is ActionBarSherlock
I didn’t need to create a Preference section yet so I haven’t tried, but I think you can use this library, and use a fragment instead of activity:
I cant find the sources and javaDocs for ABC. How can i include them in eclipse?
There is a small thing I have encountered with the actionbar compact which didn’t occure with the actionbar sherlock.
It seems like there is a small divider from the actionbar and the screen layouiot when using a custom view for the actionbar, I have posted a question on stackoverflow regarding that issue:
I use ABS in my apps and don’t want to change unless the support lib would give me an advantage, such as conserving space. Will the support library save me space?
Do you mean reduce APK size? I don’t think so, if that’s your only reason, then don’t migrate.
Great thanks. Took me less than an hour to make the change. Appreciate the article.
Comments are closed.