[TIMOB-11601] Android: Expose ActionBar methods
| GitHub Issue | n/a |
|---|---|
| Type | New Feature |
| Priority | High |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2012-11-13T22:05:02.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Release 3.0.0, Release 3.1.0, 2012 Sprint 23 Core, 2012 Sprint 23 |
| Components | Android |
| Labels | 3.0.0beta2, actionbar, qe-testadded, triage |
| Reporter | Arthur Evans |
| Assignee | Allen Yeung |
| Created | 2012-10-29T19:52:32.000+0000 |
| Updated | 2013-03-21T10:37:05.000+0000 |
Description
3.0 has added support for adding action items to the action bar, and displaying tabs on the action bar. However, we don't expose any direct way to interact with the action bar, the way the android.app.ActionBar class does.
In particular, ActionBar allows you to:
- Change the background drawable for an action bar.
- Show and hide the action bar.
- Set the title and subtitle of an action bar.
- Change the app icon/app logo.
- Display the "Up" affordance on the app icon/app logo.
- Register for click events when the user clicks the app icon/app logo.
- Change the display options (show or hide title, subtitle, icon/logo).
We may need to break this out into separate subtasks, but I think we should support all of these.
Some of these things could possibly be exposed thought existing APIs (such as navBarHidden to show/hide the action bar). However, there are enough specific things here that it probably makes sense to expose ActionBar directly.
I would recommend exposing ActionBar directly, since 4.0 brings the new split view action bar... navBarHidden sounds appropriate now, but what will JB bring?
In terms of priority, I think these are all pretty important but I think I'd prioritize them something like: 1) Register for click events when the user clicks the app icon/app logo. 2) Display the "Up" affordance on the app icon/app logo. 3) Change the background drawable for an action bar. 4) Set the title (and subtitle?) of an action bar. 5) Show and hide the action bar. 6) Change other display options (show/hide title, logo, etc.) 7) Change the app icon/app logo.
I would say that #1-4 are required for release. #4 because if you use a tabbed application, there's no title on the tabs screen. #7 is already partially take care of, because you can specify android:logo in the manifest. That, of course, doesn't let you change it per-Activity, but at least it's a start.
PR: https://github.com/appcelerator/titanium_mobile/pull/3387
Stupid question from a newbie developer: how can I add action buttons instead of menu options? Is this implemented already in the CI builds?
@Igor you should find notes on how to use it here: http://docs.appcelerator.com/titanium/release-notes/?version=3.0.0.B#action_bar This has not been merged to the CI build yet. Please look at the PR associated with this ticket to see when this has been merged.
Backport PR: https://github.com/appcelerator/titanium_mobile/pull/3419
It seems like it would make sense that, by default, the ActionBar title would be the Window title, right? I just had to write this code, which just seems silly:
if (Ti.Android) { myWindow.activity.actionBar.title = myWindow.title; }Thanks for the quick answer, Allen! It was very helpful. And I'm already following the pull requests. Maybe I'll switch to the branch code if I need this running before the merge, but looks like it will happen quickly. Thanks again =)
Very nice. I was starting to work on this. You did it ten times better! A few remarks: - we can set a backgroundImage, would be nice to be able to set backgroundColor (easily done with ColorDrawable) - how do you make the actionbar "visible", right I do it by overriding titanium themes. is there a better way? - when is "actionBar" available? is it on proxy creation or do i have to wait for the "open" event? Thanks
Martin, If setting backgroundColor is easy, I would highly recommend forking TIMOB, making the change, and submitting a pull request. That is better for everyone! All you need to do for the ActionBar to work is set the correct target-sdk in your manifest, and run the app on a 3.x+ device. actionBar is part of the "activity" object, so it's only available when the Activity is available... so on or after the 'open' event.
That s actually already done in my branch. Sorry i didnt mean to ask "for you to do it!" Ok about the target-sdk. Actually i didnt use it because i want my app to be compatible with older version. I will try the target-sdk, but it seems that without it you get the gray status bar. Thanks for the explanation on actionBar creation. I was asking because in the implementation i had made of it i was settings actionBar properties (home icon selection and actionbar color) at the window creation time. Then i put the value of those properties in the activity creation intent. The idea was to make sure that everything is correctly set right on window appearance. And that s why i was asking thanks a lot
target-sdk is not min-sdk ActionBar is designed to be seamlessly backwards-compatible with older devices, which is why it uses the onCreateMenu interface. Other things, like the title/logo/etc just don't show on those old devices, and Tabs revert back to the old tab UI. If you have patched the SDK so we can set backgroundColor, please submit a PR! https://wiki.appcelerator.org/display/guides/How+to+Contribute+Code Just (digitally) sign the contributor agreement and submit that PR. I'll make sure It gets fast-tracked.
To Martin's point, it would be nice if we could set action bar properties when we create the window (and hence before the action bar already exists). We do this currently for activities, although the situation may be complicated somewhat by the fact that an action bar can be shared by multiple windows (for example, in a tab group). I don't know. I will open a feature request for this, although it's probably not top priority.
Opened feature request (TIMOB-11798) to allow setting of action bar properties before the window is opened. Also, note that there's a bug originally identified by Igor where activity.actionBar is not being set correctly for Tab windows, so you can NOT use these methods on a tab group yet. This is filed as (TIMOB-11796).
And I second Shannon's request, although I would point you to the newer, somewhat more streamlined version of the "contributing" docs: http://docs.appcelerator.com/titanium/3.0/#!/guide/Pull_Request_Guide Just updated these recently, so please let me know if you see any problems.
As with the Holo UI the behavior of tabs has changed, the [documentation|(http://docs.appcelerator.com/titanium/3.0/#!/api/Titanium.UI.Tab] of it should be edited too. The windows opened inside a tab are not heavyweight anymore, and share the same activity. I'm trying to work on a workaround to have different menus for each tab, but it's kinda hacky... but my interface needs this for now.
The workaround is done, but it only works for menus. You can see in [those](https://bitbucket.org/santos_dal/marketshare/src/47a8694e931842d49f04efd93310adfaca4f1536/Resources/ui/common/windows/main/home.js?at=master) [three](https://bitbucket.org/santos_dal/marketshare/src/47a8694e9318/Resources/ui/common/windows/main/lists.js?at=master) [files](https://bitbucket.org/santos_dal/marketshare/src/47a8694e9318/Resources/ui/common/windows/main/groups.js?at=master) what I did. Looks like the main reason for this to not work with the ActionBar buttons is onPrepareOptionsMenu not being fired when the tab changes - it does happen with normal menus. I gave up on tabs, I'm going to rethink my UI and remove them. But I think this difference should be noted in some place in the documentation, and maybe could be useful for you too.
Ok so first i must apologize for not knowing about target-sdk :s I think i lost a few working around it (at least now i know themes and titanium actvities like the back of my hand!) @Arthur yes i think it would be great to be able to set those properties upon window creation. On simple reason for this is that you dont have to "write code" to enable those features. If you were using titanium redux for example, you could do it in a rjss file. That s also why in my implementation of the "home button" event, it wasn't a event listener but just a property "home button goes back" why? to mimick in a way a simple implementation of the ios part. I will submit a PL for backgroundColor as soon as i have the time. Thanks
Sorry for the flood, but I'm quite new here and I'm afraid of opening new issues for now. I'm working with the ActionBar buttons, and I notice two strange things: 1. I'm using another method to simplify adding items to menu, and thus the Ti.Android.SHOW_AS_ACTION_X constants are being evaluated before getting into the menu.add() argument. This is making the property not being set. The only way to change the Action state of a menu item is using the constant directly. You can understand better how my code works seeing [the helper](https://bitbucket.org/santos_dal/marketshare/src/da503f7076e7/Resources/ui/common/components/windows.js?at=master#cl-48) and [a sample window](https://bitbucket.org/santos_dal/marketshare/src/da503f7076e78839c60b43525a933e005fbb5b63/Resources/ui/common/windows/main/settings.js?at=master). -2. I'm not able to add items directly to the Action Overflow menu (that "three dots" button); I was thinking that SHOW_AS_ACTION_NEVER would do this, but it place the items in the old menu, and SHOW_AS_ACTION_COLLAPSE_ACTION_VIEW does nothing that I've noticed. My targetSdk is 14. Also, add many buttons with SHOW_AS_ACTION_IF_ROOM simply place the overflown items back in the old menu.- Reading the [Android docs](http://developer.android.com/design/patterns/actionbar.html) I've noticed that this is, actually, the right behavior when there's a hardware menu button.
Verified and closed all functionality mentioned in all sub task. Hence Closing the bug.