Difference between ActionBarSherlock and ActionBar Compatibility

What is the difference between ActionBarSherlock and Action Bar Compatibility

Fews days ago Google just released the ActionBar Compatibility that make me so confused. Is that the Action Bar Compatibility works same as the ActionBarSherlock and is the coding same?

Example : Does app icon to navigate "up" or ActionBar.Tab supported in Action Bar Compatibility ?

ActionBarSherlock vs ActionBarCompat:

I Just want to put few code difference between ActionBarSherlock vs ActionBarCompat Lib

We can migrate some apps from ActionBarSherlock to ActionBarCompat:

steps:

1. Import AppCompat project.

2. Replace SherlockFragmentActivity with ActionBarActivity.

3. Replace SherlockFragment with Fragment.

4. Change Menu, MenuItem and getSupportMenuInflater() references. Modify the way you get Action Views.

   mSearchView = (SearchView)MenuItemCompat.getActionView(mSearchItem)

5. Modify your Themes and Styles.

For more info, please refer this slides by +NickButcher (Google)

>

Thanks to Sources: http://gmariotti.blogspot.in/2013/07/actionbarsherlock-vs-actionbarcompat.html http://antonioleiva.com/actionbarcompat-migrating-actionbarsherlock/

Don't forget to read this developer.android for more about ABC!

Note: Setting it up for unit tests the same way as ABS is unfortunately not possible with the support library.

Output: >

Credits: Gabriele Mariotti

ActionBarSherlock gives your application an action bar regardless* of what version of the android API your app is being run on. Action Bar Compatibility gives you the action bar only if the device that you're running on is API level 3.0 or above.

*Note that if the device you're running on isn't 3.0 or above, ActionBarSherlock is going to use it's own custom implementation of the action bar, not a native one.

--EDIT--

It appears things have changed and there is actually no difference between ActionBarSherlock and the Action Bar Compatibility anymore. Please read the comments below for details.

--EDIT--

After having used both now, I can say that I actually prefer ActionBarSherlock to Action Bar Compatibility. ActionBarSherlock is really easy and nice to use.

--EDIT-- As LOG_TAG mentioned, there is now support for the action bar in the Android Support Library. I haven't had a chance to use it yet, but I would imagine that's the best one to use.

Just completing what @Kurtis Nusbaum with a pratical example.

UPDATE: as @rudy-s said, with newest android support library (api 18), I saw they already have built-in support for actionbar (called ActionBarCompat class).

I built two simple applications to show the visual difference between ActionBarSherlock and ActionBar Compatibility. See the comparatives images:

Now the appearance when the menu button is pressed:

---

As you can see, the images just enforce what was said. Action Bar Compatibility gives you the action bar only if the device that you're running on is API level 3.0 or above. While Sherlock is more general.

Below you can see the application source.

The menu xml file is the same:

<menu xmlns:android="http://schemas.android.com/apk/res/android" >

<item
    android:id="@+id/action_1"
    android:orderInCategory="100"
    android:showAsAction="always"
    android:title="@string/action1"/>

<item
    android:id="@+id/action_2"
    android:orderInCategory="100"
    android:showAsAction="ifRoom"
    android:title="@string/action2"/>

<item
    android:id="@+id/action_3"
    android:orderInCategory="100"
    android:showAsAction="ifRoom"
    android:title="@string/action3"/>

<item
    android:id="@+id/action_settings"
    android:orderInCategory="100"
    android:showAsAction="never"
    android:title="@string/action_settings"/>

</menu>

Compatibility's activity:

public class MainActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
         super.onCreate(savedInstanceState);
	     setContentView(R.layout.activity_main);
     }

     @Override
     public boolean onCreateOptionsMenu(Menu menu) {
	    getMenuInflater().inflate(R.menu.main, menu);
	    return true;
     }
}

Sherlock's activity:

public class MainActivity extends SherlockActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
	    super.onCreate(savedInstanceState);
	    setContentView(R.layout.activity_main);
    }

    @Override
    public boolean onCreateOptionsMenu(com.actionbarsherlock.view.Menu menu) {
	    getSupportMenuInflater().inflate(R.menu.main, menu);
	    return super.onCreateOptionsMenu(menu);
    }

}

An additional config was necessary on sherlock app:

<style name="AppBaseTheme" parent="Theme.Sherlock.Light.DarkActionBar">

UPDATE: as @rudy-s said, with newest android support library (api 18), I saw they already have built-in support for actionbar (called ActionBarCompat class).

Actionbar Sherlock is far more advanced and far more ambitious than the simple Actionbar compatibility project.

The Action bar compatibility can be considered a "sample" or a good starting point if you only want to smack an Action Bar on top of your app.

ActionBarSherlock builds on the compatibility library, and gives you (like the action bar compatibility sample) an Action Bar on pre-3.0 devices. In addition it has extra features not present in the ActionBar Compat code. This includes features like, but not limited to

• setNavigationMode (for Tabs and spinners in the action bar)
• Dialog Fragments
• Contextual Action Bar (CAB) a menu that takes over the action bar, used for example for multi select (http://developer.android.com/design/patterns/new-4-0.html) This is a ICS feature (!) For this, an implementation of the ActionMode class (introduced in API level 11) had to be introduced into the ActionbarSherlock library
• Fragment and FragmentActivity implementations - because fragments can implement the onCreateOptions menu, we need to make sure that the SupportMenuInflater is used.
• Two themes not very unlike Holo.Dark and Holo.Light (Theme.Sherlock, Theme.Sherlock.Light)
• The ICS feature "split action bar"

The only downside I see in using ActionbarSherlock is that you lock yourself in to that library. If for some reason it will die out in the near future, you'll have to maintain it youself (for example if no Jellybean implementation comes along). This is a hassle (not a huge problem) since all your fragments extends SherlockFragemnt and all your Activities. SherlockActivity.

Well @Jake implementation goes way further than what the Actionbar compat, to be more precise Actionbar Compat is just a basic example on how can you support all aplication with a pseudo-actionbar for releases prior from Honeycomb (API 13). Although their target is the same cross compatible actionbar, they have diferent approach.

ActionbarCompat Aproach

This implementation make no use of the Compatibility Android support library instead it create a base class called ActionBarActivity create a single instance of a Helper this helper act as factory itself that returns diferent implementation for the three segment of APIS, it returns

• ActionbarBaseHelper: for prior to HoneyComb.
• ActionBarHoneyComb: for HoneyComb
• ActionBarHelperICS: for ICS base devices.

The most interesting part is in the ActionbarBaseHelper, because it has the most important code, I suggest you understand this class and you will get the whole example.

Action Bar Sherlock

Well this is tricky firstable because, I'm not the author maybe Jake can explained further this, but I'll give it a try.

Just as the compat Sherlock make diferent implementation but one is for "Compat" and the other is Native. It force you to extends either from SherlockActivity or from SherlockFragmentActivity, because this two base classes have the method for dispatching the ActionBar.

This is a large and complex project, that cannot be explained in a single post. Suggest you dig around Sherlock Github repo grab a look and as Jeff Atwood says

• I strongly believe that you should use ActionBarCompat for all new projects that want to support older devices.

• It also might make sense to migrate existing projects. So read on to learn why you should migrate or use ActionBarCompat right away and how to migrate existing projects.

Why you should prefer ActionBarCompat over ActionBarSherlock?

There are many reasons why you should prefer ActionbarCompat over ActionbarSherlock.

1. First of all this project is by Google, is part of the Support Library and thus likely will support new Action Bar related stuff at the same time Google releases them with stock Android.

2. Another good reason is that it supports the Navigation Drawer pattern right out of the box, while ActionBarSherlock does not. Thus if you want to add this drawer to an existing project/app you should migrate.

3. The last and Important is, that the creator of ActionBarSherlock, Jake Wharton, announced on Google+ that further development of ActionBarSherlock has been stopped. ActionBarSherlock 4.4 is the last release and might get bug fixes – but there won’t be any new features: So if new functionality is included in actionbar you may not keep up to it with actionbarsherlock.

Maybe we should update the answer because google published offical Actionbar support since API18?

block below is from offical blog about these two libraries:

> If you’re using a third-party solution (such as ActionBarSherlock), there are a few reasons to consider upgrading: > > - Can be kept updated as the Action Bar API evolves. > - Integrated Ancestral Navigation support. > - Use of framework Menu and MenuItem classes. > - Continue to use the Support Library's Fragment class. > - Integrated support for ActionBarDrawerToggle for use with DrawerLayout. > - Backport of PopupMenu. > >ActionBarSherlock is a solid and well-tested library which has served developers very well for a long time. If you are already using it and do not currently require any of the above then there is no need to migrate.