ActionBarCompat (Part 3): Migrating from ActionBarSherlock

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.

[java]
mSearchView = (SearchView)MenuItemCompat.getActionView(mSearchItem)
[/java]

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.

ActionBarCompat from ActionBarSherlock

15 thoughts on “ActionBarCompat (Part 3): Migrating from ActionBarSherlock”

  1. 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.

    1. Antonio Leiva

      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.

    2. 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).

  2. Thorsten Schillo

    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.

    1. Antonio Leiva

      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.

      1. 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

  3. 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?

    1. Antonio Leiva

      Do you mean reduce APK size? I don’t think so, if that’s your only reason, then don’t migrate.

Comments are closed.