Future of ActionBarSherlock.

[Prakash]

As new devices are coming out with ICS and older devices might start
receiving ICS updates, just wondered what would be the future of ABS?

There is no doubt that ABS has solved a huge problem for me, it looks
like ABS uses native ActionBar for ICS and support version for GB and
below.

if ABS is going to use AB of ICS, then probably there is less scope of
innovation, because ABS will be limited in feature provided by native
AB.

My thoughts are that, ABS should not use native AB on ICS as well so
that, ABS can do more than what native AB can provide in whatever way
that is left to imagination. If not, then ABS might end up becoming an
empty wrapper over native AB.

Thoughts?

[Macarse]

What would you add?

[Jake Wharton]

The goal in the long term is that the library will become less and less useful to the point where people will no longer need to use it.

The whole point of proxying to the native implementation is that you should be using the platform action bar and not a custom version. As adoption for Android 3.0 and newer increases the need for the library will decrease. I've been dropping support for platforms once they reach 1% market share so once every platform prior to Android 3.0 is at that point there will theoretically be no need to use it anymore.

There will always exist platform differences between API levels, however, so perhaps it will still exist in some form to mitigate those differences. Hopefully there will be a Google support library to take care of those and ABS can become obsolete!

---
Jake Wharton
http://about.me/jakewharton

[Prakash Nadar]

What would you add?

Things left to imagination, there is always room for innovation. 

-prakash

[Prakash Nadar]

Thats fair. 

regards, 

-prakash

[Andrew Toulouse]

For example:
Being able to force a tab bar (the one that shows on space-constrained devices)
Having a differently-styled tab bar (the same sort as above) with respect to height
Being able to have two nested levels of tabs
Letting tabs loop around

The last one is probably more of a ViewPager-related issue more than an ActionBar one.

--Andy

[Mark Murphy]

On Fri, Jun 1, 2012 at 2:51 PM, Andrew Toulouse
<toul...@crunchyroll.com> wrote:
> Being able to force a tab bar (the one that shows on space-constrained devices)
> Having a differently-styled tab bar (the same sort as above) with respect to height
> Being able to have two nested levels of tabs
> Letting tabs loop around
>
> The last one is probably more of a ViewPager-related issue more than an ActionBar one.

The primary point behind the action bar pattern is to provide a
consistent navigation experience, across apps, for the user. In this
respect, Google is taking the "carrot" approach, in contrast with
Apple's "stick" (i.e., you violate their human interface guidelines
and you cannot distribute your app).

Android developers have a well-earned reputation of caring not a whit
about a consistent navigation experience, or much of a consistent
*anything* when it comes to UI/UX. As a result, Android developers are
ridiculed by users and the media for writing "lousy" apps. It's not so
much that the apps themselves are lousy, but that they do not look
like they belong with the other apps on the device, and "different"
tends to be perceived as "lousy" unless the UI is truly excellent.

Is Google's action bar implementation perfect? Far from it. That being
said, developers really need to either go with the action bar as
implemented (and as backported in ABS) or do something sufficiently
visually different that users are not comparing it to a regular action
bar. Developers who fall in the "uncanny valley" of something that
kinda looks like an action bar but behaves differently are at greater
risk of having their apps perceived as "lousy".

Hence, I am a big fan of Jake's approach of keeping ABS as a pure
backport, functionality-wise.

This is not to say that innovation is bad. However, for every
developer who is innovating on the action bar, there needs to be 100,
maybe even 1,000, who are sticking with the standard one, to help lift
Android's app reputation out of the hole that it is in. Android
developers need to learn discipline: stick to standards where users
expect standards, and innovate where users expect innovation. And, for
better or for worse, Google has moved its implementation of the action
bar into the "where users expect standards" category.

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

_The Busy Coder's Guide to Android Development_ Version 3.7 Available!

[Andrew Toulouse]

I agree; I was just offering suggestions for possible features one might desire. ABS as a ActionBar backport is ideal.

--Andy

[Prakash Nadar]

I did not suggest to break the pattern of actionbar, ABS keeping the same look and feel and behavior as the native one can also add additional features. 

I understand the goal of ABS and it's purpose, but the library is in a good position to repurpose itself when it is about to be absolute. But then anyone can fork and do the future dev that Andrew and I were thinking of. 

-prakash

On Friday, June 1, 2012 at 12:15 PM, Mark Murphy wrote:

[Andrew Toulouse]

I think what you're talking about is forking or starting a new project dedicated to an ActionBar-like abstraction that offers developers additional choice to customize their UI.

[soapbox]
Mark seems to be suggesting that Android developers often don't put effort into making a quality app, and find it easy to (unknowingly?) abuse flexibility they're given. While this can be taken to be a somewhat dim view of Android developers as a whole, it's unfortunately a point of view I understand deeply.

I think the bigger problem with Android as a whole is that the platform has too many abstractions, the advantages and gotchas of each (and when they apply) aren't often clearly explained or documented, and improvements to them are unavailable on older platforms, and as such are used poorly. ABS addresses backporting excellently, whereas creating another method to do the same thing slightly differently runs a high risk of worsening the Android ecosystem rather than improving it, if it can't be strictly better in all respects (a tall order, despite Android being half-baked in some areas).
[/soapbox]

I don't think there's much merit in continuing this discussion around the "future of ABS" on the ABS list, since Jake has made it clear that its express purpose is to serve as a compatibility library, which is a reasonable and logical position.

--Andy

[Prakash Nadar]

Not to harp on this topic too much (just final words for being the thread starter :) ), just want to clarify on the point of UI Standards. I have worked on UX standisation for a big phone company so I know what it means exactly both working for it and enforcing the standard for other apps. 

but there is a thin line on standard and non-standard UX, do it slightly different and if people like its a innovation and if people did not like it is a breaking the pattern. 

Backporting of Actionbar is excellent thing, but form google's perspective (as of now of what they think of various actionbarsupport libs by a reliable source in google), they don't want apps in GB using action bar because it is breaking the pattern. If google wanted a support package for action bar, they would have done that long back like they did it for activity&fragments. I know, google play and other google apps do it, but they don't want others to do the same. :)

-prakash

On Friday, June 1, 2012 at 12:15 PM, Mark Murphy wrote:

[Ted Murphy]

Is it just a different path within the same svn directory?  Let me try some things, and i will confirm,

Ted

Connected by DROID on Verizon Wireless

-----Original message-----

[Jonathan Steele]

They already have http://developer.android.com/resources/samples/ActionBarCompat/index.html for pre-3.0

[Prakash Nadar]

You sho

-prakash

[Prakash Nadar]

You should try that.  it is almost nothing. That is not what is called "support".

-prakash

On Jun 2, 2012, at 12:06 PM, Jonathan Steele <xfsu...@gmail.com> wrote:

[Jake Wharton]

ActionBarCompat is a sample of how you can write your own back port of an action bar. It's not a full-fledged library which a lot of developers mistake it for. Google doesn't provide an action bar because the number of compromises and technical limitations of the older versions of the platform are too great. There's no way for them to provide a quality library. ActionBarSherlock manages to just be useful enough so that you tolerate its lengthy requirements.

I ranted in blog-post form about it here: http://abs.io/square

[Prakash Nadar]

yes that is true, ActionBarCompat is a sample only and few bits of information how someone can write their own. btw, action bar is more or less is like a widget, there is absolutely no limit what you can do with a widget, view and action bar is not really a complicated widget, just time consuming to implement it. The challenge is giving a consistent api interface. If the interface is moved away from the Menu interface, i.e. onOptionxxxx then it becomes lot easier to write platform independent "widget" that conforms to google UX interface. Anyway, that is all architecture discussion, we can go really deep and long if we want to. 

Btw, I want to stand corrected on actionbar, google does not like the up-action in the action bar ports for GB, because most of the GB devices have hardware back key. Also in the future versions of Android, the back nav key which is now a virtual will entirely go away because the up-nav in the action bar entirely replaces it and having duplicate back key is not a good UX.

I also realized that you work at square, it is one of the product I cite as an example for my discussion related to why they (square) can do and why we are not able to. Thanks for the great product, and hopefully I see more use of ABS in the future beyond ICS. :)

-prakash

[b0b]

On Friday, 1 June 2012 21:15:42 UTC+2, Mark Murphy (a Commons Guy) wrote:

Android developers have a well-earned reputation of caring not a whit
about a consistent navigation experience, or much of a consistent
*anything* when it comes to UI/UX. As a result, Android developers are
ridiculed by users and the media for writing "lousy" apps. It's not so
much that the apps themselves are lousy, but that they do not look
like they belong with the other apps on the device, and "different"
tends to be perceived as "lousy" unless the UI is truly excellent.

 
yes, but as more and more apps use the action bar and look samey,
now apps will be flagged as "boring". That has already begun.
So you have the choice between "lousy", "boring" and "alien".
In other works, at least someone will hate your UI/UX no matter what.

And comes the inevitable point when Google replaces the Action Bar pattern with another one,
and we will all collectively lol at actions bars retrospectively. A bit like when you encounter a carousel now.
These were so hot in 2009-2010!

It is a bit easy to blame developpers for inconsistency since until now Google has been very inconsitent itself
(hardware vs software back button, large screen bucket not precise enough to handle all cases, long-click on item
behaviour different pre and post ICS, etc).

And I'm not even talking about sometimes lousy API design, as if 20 unrelated developpers added their own pet API functions to the same class without any communication

[Jake Wharton]

You can easily theme the action bar so that your app doesn't look exactly the same as the default to provide a cohesive look and feel (potentially to align it with a brand identity). In fact, I'd argue that if you are not theming that action bar you are using it incorrectly.

---
Jake Wharton
http://about.me/jakewharton

[Josh Brown]

If Google didn't want homeAsUp on GB then why did they add the NavUtils class to the support library (which goes back to Donut)?  The ActionBar pattern has been around much longer than Honeycomb.  They were pushing it at I/O back in 2010.  At the time the pattern was that the icon/logo would take you back to the dashboard or home of the app (and many apps still implement it this way even using the API supported ActionBar) but other than that it was very similar to what we have now.

The back button is not going away either (it's still there even on the GNex).  Up and back behave differently.  Sometimes they point to the same thing, but there are plenty of times where they don't.  Consider the case where a user is in the Gallery app.  They decide to share a photo via email.  This in turn opens the Gmail app to the compose screen.  Back would take them back to the Gallery (where they came from), whereas up would take them to their Gmail inbox.  Back will also usually perform various functions within an activity when multiple FragmentTransactions have occurred, whereas Up usually leaves the Activity.  I'm curious where you think you heard a Googler saying they're depricating the back button.  I've seen no such thing.