Full ICS Action Bar Backport and Android 4.0 Support about actionbarsherlock HOT 18 CLOSED

Does this include all of the methods marked as API level 14? Are any of these being added piecemeal to 3.x, or will they be exclusive to the 4.x branch?

from actionbarsherlock.

Yes it will. I'm not sure exactly what I want to do when run on 3.0 through 3.2 in regards to those new features, however. Luckily I have a few weeks until the ICS source is released to ponder what to do.

I've had some suggestions of just using the ICS version on all platforms rather than trying to switch between the two. Perhaps I'll do that from 3.2 back and only do native on 4.0+.

from actionbarsherlock.

Considering that ICS is most likely coming to most, if not all, HC tablets, and the fact that the number of HC devices is pretty limited, I don't think you should make any extra effort to support the native implementation on HC.

from actionbarsherlock.

Is this only in the master branch? Having an issue with the application running on devices running Android 3.2 and Android 4.0 at this point. For whatever reason the onCreate method is not being called properly when you have an abstract fragment that you extend.

from actionbarsherlock.

Android 4.0 is being developer in the 4.0-wip branch but is not yet ready for public consumption. The master branch is the latest stable release, 3.4.2, which will work on Android 4.0 fine but still requires that you compile with Android 3.2. If you have a specific issue with your app, please ask on the forum: http://abs.io/

from actionbarsherlock.

Just a heads up, as I stumbled over it already: http://developer.android.com/reference/android/app/ActionBar.html#setHomeButtonEnabled(boolean)

TLDR: The home button has to be explicitly enabled to react to home/up events on API level 14+.

from actionbarsherlock.

I have downloaded your 4.0wip but i is not working. I have users that have Android 4.0, they are all complaining. Pleaseeee

When I tried to add as a library, It gives errors about Animator classes. Furthermore, there are no support packages available in the zip

from actionbarsherlock.

An app written using ActionBarSherlock v3.x will work perfectly fine on Android 4.0 since it uses the native action bar on Android 3.0+.

There is no reason that you are required to compile against Android 4.0 unless you are specifically using APIs from Ice Cream Sandwich. If you absolutely must compile against Android 4.0 all you should have to do is add a few default implementations to the MenuItemImpl and MenuItemWrapper classes for the new menu interface methods.

The 4.0-wip branch is very much a work in progress and represents a significant change in the library. The core is no longer dependent on the compatibility classes. A plugin will be provided to provide an action bar-enhanced version of FragmentActivity.

from actionbarsherlock.

oh ok. I just need to compile with Android 3.2
Thank you very much. I just donated you 10 bucks for your great effort.
On Dec 15, 2011 2:11 PM, "Jake Wharton" <
[email protected]>
wrote:

An app written using ActionBarSherlock v3.x will work perfectly fine on
Android 4.0 since it uses the native action bar on Android 3.0+.

There is no reason that you are required to compile against Android 4.0
unless you are specifically using APIs from Ice Cream Sandwich. If you
absolutely must compile against Android 4.0 all you should have to do is
add a few default implementations to the MenuItemImpl and
MenuItemWrapper classes for the new menu interface methods.

The 4.0-wip branch is very much a work in progress and represents a
significant change in the library. The core is no longer dependent on the
compatibility classes. A plugin will be provided to provide an action
bar-enhanced version of FragmentActivity.

---

Reply to this email directly or view it on GitHub:

#23 (comment)

from actionbarsherlock.

Hey @JakeWharton I noticed that in ABS at the moment there some discrepancies with the way a crowded actionbar will be handled, as compared to ICS:

1. In ICS, overflow items will go into the '3 dot' menu, but in ABS on pre-honeycomb devices, if you add too many actionbar items they continue presenting in the actionbar, and end up overlapping the home icon on the left-hand-side.
2. In ICS the 'text' part of the menu item won't be displayed if room is tight, but in ABS it seems the text is always presented in the actionbar, even if the menu item attribute is simply android:showAsAction="ifRoom", ie without even the withText modifier present.

....do you think those differences will be removed with ABS 4.0?

from actionbarsherlock.

Yes, both the forthcoming v3.5 and v4.0 use ICS's menu and action item logic so you should see identical functionality between the native behavior and ABS's implementation.

The dev branch should be stable enough to try provided that you do not use the maps or preference activity base classes or sub menus (they just won't show up). I haven't fully documented the changes yet so tread lightly. It should solve all of the described problems though (and feedback is always welcome during development).

from actionbarsherlock.

Ah, looks like the dev branch currently (as of fc1ffa7) has a compilation failure on IcsLinearLayout.java...

$ mvn clean install
...
[ERROR] /Users/roberto/development/ActionBarSherlock/library/src/com/actionbarsherlock/internal/widget/IcsLinearLayout.java:[106,8] illegal start of expression

from actionbarsherlock.

ah comma on end of the equals = Gravity.FILL, name = "FILL") was causing a problem :)

from actionbarsherlock.

Having another go on the dev branch as of f435db0 - looks like the behaviour on an overcrowded actionbar is better, excess items now go into the standard gingerbread menu, rather than swamp the actionbar.

Apologies for being greedy, but do you anticipate being able to support the ICS-style automatic 3-dot-button overflow menu in ABS, in preference to the standard gingerbread menu?

from actionbarsherlock.

I considered this for 4.0. It certainly will already support the on-action bar overflow button but it is only enabled for devices that do not contain a hardware menu key (decision logic). Perhaps it would be beneficial to allow users to force it being enabled and then just have the menu key trigger its opening...

from actionbarsherlock.

That makes sense... The problem with the physical menu button is that there's no visual cue to indicate that it's actually worth pressing - the user doesn't know that there are any further options available to explore.

The ICS behaviour - displaying the overflow button - is definitely awesomer, I'd much rather enable it for all devices regardless of whether they have the hardware menu key.

from actionbarsherlock.

I totally agree. While I will likely leave the logic there since its from the SDK, I like the idea of being able to force the overflow. I'll add a theme attribute, absForceOverflow boolean, to control it.

I'm trying to ship v3.5 ASAP and hammer out a beta of 4.0 so people can get started porting their apps. I'll file a separate ticket for the forced overflow.

from actionbarsherlock.

Alright folks, the ball is rolling on version 4.

Bugs: http://abs.io/4
Betas: http://beta.abs.io/

No support or questions until I announce (and explain) the betas on my blog.

from actionbarsherlock.