jakewharton / actionbarsherlock Goto Github PK

Google IO 2011 App

Evaluate how difficult emulating a PreferenceFragment will be since PreferenceActivity can not be used.

http://stackoverflow.com/questions/6080094/use-of-onprepareoptionsmenu-on-android-3-0

Currently it only checks the library.

As per the ActionBar documentation:

If you added the menu item from a fragment, then the respective onOptionsItemSelected() method is called for that fragment. However the activity gets a chance to handle it first, so the system calls onOptionsItemSelected() on the activity before calling the fragment.

Overflow on pre-3.0 devices is currently placed in the options menu. Add flag/feature/something to enable it to appear on the actual action bar widget just as 3.0+ does.

Release 3.0.2

When inflating a menu defined as XML resource, using android.support.v4.view.MenuInflater, the XML tags "actionLayout" and "actionViewClass" are ignored.

Don't know if this is still unsupported cause the code is commented in android.support.v4.view.MenuInflater:383 and android.support.v4.view.MenuInflater:394

On http://actionbarsherlock.com/theming.html no mention is made of the titleTextStyle attribute, which must have the android: prefix dropped for actionBarSherlock to recognise and use.

'nuff said?

From Google Code and style Android-ActionBar to match closely.

This will provide a good example of how to customize the look of both 3.0+ and pre-3.0 action bars.

And a python script to automatically initialize them properly.

So that they are automatically built during the release of the library (and pushed to the maven repository?)

Just use a debug key rather than the production keystore.

Hello.

This is my custom Theme:

    <style name="CustomTheme" parent="Theme.Sherlock.Light"> 
            <item name="android:textColor">@color/darkblue</item> 
    </style> 

If I use in my project: android:theme="@style/Theme.Sherlock.Light", everything works fine.
If I use: android:theme="@style/CustomTheme", getSupportActionBar() return null with Honeycomb devices.

Change the interfaces to follow the HasXxx style. This comes in response to #12 which provides the implementing activity access to the handler instance, access which had previously been kept abstracted from the "front-end" (in relation to the library).

Methods in these new-style interfaces should be actionable rather than declarative. That is, receive input rather than just setting a value behind the scenes. For example, the HasLogo interface, the new-style equivalent of what is currently LogoHandler, will expose useLogo(boolean) instead of simply useLogo(). With this change, activities can now interact asynchronously with the action bar rather than only in their own handler implementation's callbacks. If you need further justification as to why this change is necessary, see the styled-action-bar example project.

All features, even the common ones (e.g., setTitle(CharSequence)), will be abstracted into these interfaces. The end result should be an ActionBarHandler<?> base class which exposes no methods other than those inherited from Object. This will force the implementing activity and the user authoring it to be more aware of each handler's capabilities.

Though this will not alter the current exposed API for attaching, the handler API will change significantly. Since we follow semantic versioning, this will bump the version to 3.0.

android:title="what's up, doc?" does not work. Only resources are currently supported.

Release 3.0.2

I use the following entry in my values/styles.xml file for the ActionBar:

<style name="App_ActionBar.HomeIcon">      
   <item name="icon">@drawable/ic_title_home</item>
</style>

In com.actionbarsherlock.internal.widget.ActionBarWatson:107 the icon resource will be loaded and set correctly.

   //Try to load the icon from the theme
   final Drawable homeIcon = attrsActionBar.getDrawable(R.styleable.SherlockActionBar_icon);
   mHome.setIcon(homeIcon);

But in com.actionbarsherlock.internal.app.ActionBarHandlerWatson.performAttach():78 the previously set icon gets set to null again during homeWrapper.initialize(). Here the icon will be overwritten by the null icon from the homeMenuItem instance.

   final MenuItemImpl homeMenuItem = getHomeMenuItem();
   final ActionBarWatson.Item homeItem = mActionBar.getHomeItem();
   final WatsonItemViewWrapper homeWrapper = new WatsonItemViewWrapper(homeItem);
   homeWrapper.initialize(homeMenuItem, MenuBuilder.TYPE_WATSON);

Get maven to compile the project to a standalone JAR file. This will allow for easy inclusion in projects which do not want to use it as a library project.

Deploy compiled JAR to either the Maven central repository or my hosted repository (http://repository.jakewharton.com), or both.

Blocked by #5.

Based off of something like cssgrid that can work on any screen size down to mobile phones. Also a new color scheme and background that will work with the new logo.

Release 3.0.2

A call to android.support.v4.app.FragmentActivity.onCreate(Bundle) creates the options menu in the same call by calling invalidateOptionsMenu(). See line 327.

In my case this causes problems cause I create my options menu depending on the fragment configuration, which is created during FragmentActivity.onCreate() of my concrete type. Either from the stored instance state or a default configuration. But I have to call through super.onCreate() which calls invalidateOptionsMenu() which synchronously calls onCreateOptionsMenu() before I had a chance to create my configuration.

One suggestion: Wouldn't it be better if invalidateOptionsMenu() calls onCreateOptionsMenu() asynchronous by scheduling a message to the Handler?

According to the Javadoc and to the default Android behavior, the methods com.actionbarsherlock.internal.view.menu.MenuBuilder.findItem(int) and com.actionbarsherlock.internal.view.menu.MenuBuilder.removeItem(int) do not throw.

com.actionbarsherlock.internal.view.menu.MenuBuilder.findItem(int) returns null if no item found for the given ID and com.actionbarsherlock.internal.view.menu.MenuBuilder.removeItem(int) does nothing if the given ID is invalid.

Utilized directly by native and implemented by handler via interface.

This has two benefits:

• Centralize handler location so that multiple samples aren't all including the same java file nor would we have to worry about keeping all of them synchronized with each other's changes.
• Provide .jar downloads of handlers which can be dropped directly in a project (along with our library and the associated action bar library) and used out of the box.

The native 3.0 action bar supports a contexual action bar which is wholly different from the activity action bar and is tied to a specific piece of content. This needs its own abstraction though a HasXxx interface.

Have the attach() method return the handler instance.

This way, if the activity needs to interact with the action bar it can do so by extending both the native and custom handlers to implement an interface. The returned handler instance can then be cast and stored as an instance of the interface and interacted with by simple method calls anywhere in the activity.

ADT layout editor throws a StackOverflowException when using Theme.Sherlock or Theme.Sherlock.Light.

The complexity of the library in both functionality and display is far too complicated to rely on manual checking of features.

As the topic says.

Create a SubMenu with exclusive checkable items. setChecked(true) on an item does not work.
The last item of the list remains always checked. It works on Honeycomb.

I'm not sure, which update broke the build system, and I'm not sure, if this is a bug related to this project, or to the android SDK:

Since the update to latest Android API / SDK tools and eclipse plugin, I can not build the project, as some references to the platform's resources are unknown. Even when leaving the referenced API untouched (E.g. to API-11 or 12).

I can reproduce the problem on both systems here.
One of it was building the project yesterday without the updates.

The marked resources are:
android:actionModePopupWindowStyle
android:actionModeStyle

with the four lines

?actionModePopupWindowStyle
?actionModeStyle

Release: 3.1.3

The hidden state of a Fragment instance is not saved during, e.g. device orientation change. If I have created a Fragment and hide it by calling the following code it becomes invisible:

final Fragment fragment = getMyFragment();
final FragmentTransaction transaction = getSupportFragmentManager().beginTransaction();

transaction.hide( fragment );

transaction.commit();

After a orientation change it is visible again. The hidden state seems not to be saved and during recreation of the hidden Fragment, it becomes visible again.

Don't know if this is a bug or it behaves the same in the native 3.0+ world.

If getParent() != null then operate as a normal activity. Even though using TabActivity is not supported or recommended this is a trivial fix.

Natively, the function and implementation should be obvious. As for how to handle on pre-3.0 devices the implementation becomes less clear.

For now, instead of forcing any implementing handlers and applications into a single tab implementation this will simple marshal calls from the action bar back to the activity.

I have a small problem regarding creating SubMenus. See the following code:

@Override
public void onCreateOptionsMenu( android.support.v4.view.Menu menu, MenuInflater inflater )
{
   int groupId = 1;

   android.support.v4.view.MenuItem item = menu.add( groupId, ... );

   // This is a com.actionbarsherlock.internal.view.menu.SubMenuBuilder instance
   android.view.SubMenu subMenu          = menu.addSubMenu( groupId, ... );

   // This is a com.actionbarsherlock.internal.view.menu.MenuItemImpl instance
   android.view.MenuItem subMenuItem   = subMenu.getItem();

   // Since API level 11
   subMenuItem.setShowAsAction( ... );
}

The last call subMenuItem.setShowAsAction( ... ) is available since API level 11. To use ActionBarSherlock, the project has to be compiled using API level 11. But subMenu.getItem() returns the type android.view.MenuItem, even if it is implemented with com.actionbarsherlock.internal.view.menu.MenuItemImpl. When executing the App on a device with API level < 11, the call to subMenuItem.setShowAsAction( ... ) throws an exception, cause the method is not available.

ActionBarSherlock's implementation handles the backward compatibility. So the interface returned by subMenu.getItem() should also reflect this by returning something like android.support.v4.view.MenuItem.

http://stackoverflow.com/questions/6105504/load-activity-and-or-application-logo-programmatically-from-manifest

Release 3.0.2

A call to com.actionbarsherlock.internal.view.menu.MenuItemImpl.setVisible( false ) seems to be without effect. If the MenuItem was shown in the ActionBar, it is still visible after a call to setVisible( false ) and a call to android.support.v4.app.FragmentActivity.invalidateOptionsMenu().

Release 3.1.0:

Currently android.support.v4.view.MenuItem.getSubMenu() returns the type android.view.SubMenu. This may lead to a MethodNotFoundException on devices with API level < 11 if android.view.SubMenu gets extended in the future.

Related to issue #36

showing the indeterminate progress bar in action bar does work only in >API11.

calling setProgressBarIndeterminateVisibility(true) on <=API10 does nothing at all.

Release 3.0.2

In the compatibility ActionBar implementation, menu items will be added to the ActonBar either if they are forced by MenuItem.SHOW_AS_ACTION_ALWAYS or if there is space and they have set MenuItem.SHOW_AS_ACTION_IF_ROOM. But the implementation does not respect their set category. So SHOW_AS_ACTION_IF_ROOM menu items with a low category like Menu.CATEGORY_ALTERNATIVE are added before menu items with category Menu.NONE.

I don't know how this is handled in the native implementation, but the normal menu arranges it's items also by the category.

I would suggest to add SHOW_AS_ACTION_ALWAYS always as long as there is space and then SHOW_AS_ACTION_IF_ROOM depending on their category and order inside the category.

Utilized directly by native and implemented by handler via interface.

See sample-styled/ for an example.

If one is specified for the activity.

The methods select() and getPosition() are currently not possible.

Custom tab views will not be supported at this time.

Title says it all. Worked in the official compat lib but not here. Code is exactly the same and no noticeable changes would affect in FragmentActivity, FragmentManager, or Fragment.

I ran into two problems which I suspect are reasonably common, but for which I could not find docs regarding.

existing styles need to not use @+id, but must be ported to use @id, with the ID declared in the ids.xml file. This was causing unparsable resource errors in aapt.

Also, it should be mentioned that ABS replaces the compat library, and will not work alongside it in a project.

Release 3.1.0:

I have a problem with Fragments and Loaders. Sometimes the Activity comes into a state where changes to the underlying data do not trigger a Loader reload. In these cases I get the following exception and these stack trace:

Stacktrace:

07-24 16:44:13.594: WARN/LoaderManager(24751): java.lang.RuntimeException: here
07-24 16:44:13.594: WARN/LoaderManager(24751):     at android.support.v4.app.LoaderManagerImpl.doRetain(LoaderManager.java:719)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at android.support.v4.app.FragmentActivity.onReallyStop(FragmentActivity.java:963)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at android.support.v4.app.FragmentActivity.doReallyStop(FragmentActivity.java:945)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at android.support.v4.app.FragmentActivity.onRetainNonConfigurationInstance(FragmentActivity.java:785)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:3617)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:3673)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at android.app.ActivityThread.handleRelaunchActivity(ActivityThread.java:3789)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at android.app.ActivityThread.access$2400(ActivityThread.java:125)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2037)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at android.os.Handler.dispatchMessage(Handler.java:99)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at android.os.Looper.loop(Looper.java:123)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at android.app.ActivityThread.main(ActivityThread.java:4627)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at java.lang.reflect.Method.invokeNative(Native Method)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at java.lang.reflect.Method.invoke(Method.java:521)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
07-24 16:44:13.594: WARN/LoaderManager(24751):     at dalvik.system.NativeStart.main(Native Method)

The Activity runs further but the data is stale. As mentioned, it happens not always but more often after an orientation change.

When using Fragments inside the ViewPager, every Fragment that is partially visible (left page, right page and visible page) and has called setHasOptionsMenu(true) will have onCreateOptionsMenu called, causing the items to appear in the action bar.

The correct (implied?) behavior would be to only have the currently displayed Fragment show its menu items.

The issue comes down to how ViewPager operates, it holds up to three Fragments in its ViewGroup at a time, and they are all added to the FragmentManager. So when FragmentManager.dispatchCreateOptionsMenu is called, all of the menu items are created as-if all the Fragments were visible (because they technically are).

So far I've been unable to successfully prevent this behavior (using the public class methods) because of the order ViewPager.onPageSelected is called in. Since it is called before the next Fragment is added to the ViewGroup, I can't disable the fragments menu. My temporary solution was to modify ViewPager, but I doubt you want to go this route since ViewPager will likely change in future releases of the ACL.

I'm not sure how you want to handle this one, the issue is outside ActionBarSherlock but within the ACL. I guess filing a bug to source.android.com?

Currently handleNative(Class<? extends NativeActionBarHandler>) requires that any native handler extend NativeActionBarHandler. Unfortunately, almost everything in NativeActionBarHandler is declared final so its functionality can't be overridden.

I'd like to propose changing handleNative to handleNative(Class<? extends ActionBarHandler<android.app.ActionBar>>) to allow for custom native handlers.

Submenus on action items should popup a list dialog.

Replicate 3.0's MenuInflator class so that we have access to newer attributes that still can have implications on pre-3.0.

e.g., if an items showAsAction attribute is SHOW_AS_ACTION_NEVER then bump the action into the context menu.

In Java5, @OverRide is only used for overriding methods in classes, not for interfaces.

Thus, Eclipse 3.6 shows errors all over the place. And I have not found another workaround than setting the whole project to Java6, which it surely isn't.