[TIMOB-2371] Android: Action bar

Description

Attachments

Comments

1. Justin Ferrell 2011-12-27 Any word on this ever going anywhere? With the impending release of so many ice cream sandwich devices, this seems like a pretty big issue.
2. Christopher Oehmig 2012-02-17 In my opinion, this is very important!
3. kazuaki konno 2012-02-17 Agree! It really is.
4. Asim Siddiqui 2012-02-22 BUMP
5. Shannon Hicks 2012-03-19 Google is insisting that with Android 4, we start using the Action Bar instead of depending on the Menu button. This *needs* to get bumped to a higher priority than "trivial" if Titanium is to continue being the leader with true native UI elements.
6. Jon Whitter 2012-04-03 Just started designing an app for iPhone, iPad, Android phones and Android tablets. The lack of the action bar is very disappointing as it would of been very desirable to build an Android tablet/phone app that targeted the latest OS to take advantage of the new look and feel of Android apps.
7. Tony Lukasavage 2012-04-03 My 2 cents: I want the Action Bar in the Titanium core as much as you guys, but I don't know that it makes sense as a core component right now. I think a module would be more fitting. I say this because the Action Bar isn't natively supported by Android until version 3.0 (API 11), and Titanium now needs to support as far back as 2.2. Integrating version-specific components into the core will undoubtedly cause confusion for developers unaware of the version requirements, not to mention extend the installation requirements for Android.
8. Jon Whitter 2012-04-03 When targeting API 11+ how are we to handle menus seeing as in 3.0 the "Menu button is deprecated" (http://developer.android.com/guide/topics/ui/menus.html)?
9. Shannon Hicks 2012-04-03 I concur with Jon's concern, but now I have a much bigger one... If its Appcelerator's stance that new features won't be implemented in Titanium till they are potentially years old, that's a recipe for disaster. That would cause me to seriously reconsider using Titanium, if the latest features aren't available in a reasonable timeframe. I don't, of course, expect new features to be available at 0-day, and I understand why Android 3.0 was pretty much ignored by Appcelerator... because it was pretty much ignored by *everyone*. But your reply is still troubling, Tony. After getting the far more important issue off my chest, I believe that, if I read the documentation correctly, the Action Bar support degrades gracefully on older devices. You're right, the Action Bar doesn't exist pre-3.0, but it looks like buttons end up in the Menu on 2.x.
10. Tony Lukasavage 2012-04-03 Didn't mean to sound like we were planning to ignore new features. That's definitely not the case. I see exactly what you mean Shannon. My cursory look at the Action bar API was admittedly not as close as it should have been. If it does degrade gracefully, it seems like a good fit for the core.
11. Jon Whitter 2012-04-03 You have read the documentation right, Shannon. Done a quick little native test and creating a basic app that simply creates a menu. It results in the menu button appearing in the action bar when installed on 3.0+ on tablets and under the menu button on the phones (the action bar was still present on the phone) (the action bar was automatically created when not specifying a layout), on 2.x there was no action bar and the menu button showed the menu. We then added more code to check the API version was 11+ and if it was started to interact with the action bar (promoting menu items to action bar buttons, changing the title etc...)
12. Shannon Hicks 2012-04-03 Thanks for that, Jon. I wish I had a little more free time on my hands, so I could get more into native Android stuffs.
13. Paul Hamilton 2012-05-08 I have to agree. Especially since this should already be backwards compatible. I was surprised that this approach was initially take by Google / manufacturers but the apps need to be future thinking and not to support this would be a mistake.
14. Tony Lukasavage 2012-05-14 You guys can take a look at my first crack at ActionBars on my fork of titanium_mobile at: [https://github.com/tonylukasavage/titanium_mobile/tree/ActionBar](https://github.com/tonylukasavage/titanium_mobile/tree/ActionBar). Check the commits, my work will be the commit at the top with the message "initial changes for actionbar". In its current state the ActionBar, with logo and title appears, it has the menu button in it, and I've also implemented basic action buttons (the buttons that show up in the bar if there's enough room). You can see all the changes in the commit, but the one that stands out is in SConstruct, the build script for the titanium_mobile project. In order to make use of the ActionBar, you must compile/build your Android app against API level 11 or higher (3.0+). Since Titanium needs to support all the way back to 2.2, this could potentially introduce runtime issues if APIs later than API level 8 are executed on devices that do no support them. By no means should this be an impassable roadblock, but it does introduce a new wrinkle to the build process that did not exist before, as the API level in SContruct has always been set to that of the minimum supported version. Since the priority has been pushed to "high" I'll leave this to the platform engineers. Be aware that you must have a title bar showing to see the ActionBar. Setting navBarHidden to true will hide the ActionBar. The other thing to note that took me forever to find is that the ActionBar will appear only for a second if the following code is executed:

        this.requestWindowFeature(Window.FEATURE_LEFT_ICON); 
        this.requestWindowFeature(Window.FEATURE_RIGHT_ICON); 
        

    You can't set those icons or the ActionBar disappears. Also, these will automatically make the activity indicator show up in the ActionBar, which in 99.99% of the cases is not desired:

        this.requestWindowFeature(Window.FEATURE_PROGRESS);
        this.requestWindowFeature(Window.FEATURE_INDETERMINATE_PROGRESS);
        

    Also, you'll be required to set up a custom AndroidManifest.xml to make sure that you are using one of the themes (Holo themes) that supports the ActionBar. The easiest way to do this is likely to remove the theme from the main activity and set the theme at the application level. Also, you'll need to set the targetSdkVersion to at least level 11. kinda like this:

        <?xml version="1.0" ?><manifest android:versionCode="1" android:versionName="1" package="com.appc.actionbar" xmlns:android="http://schemas.android.com/apk/res/android">
        	<uses-sdk android:minSdkVersion="8"/>
        	<uses-sdk android:targetSdkVersion="11"/>
        
        	<!-- TI_MANIFEST -->
        
        	<application android:debuggable="false" android:icon="@drawable/appicon" android:label="ActionBar" android:name="ActionbarApplication" 
        		android:theme="@android:style/Theme.Holo.Light" uiOptions="splitActionBarWhenNarrow">
        
        		<!-- TI_APPLICATION -->
        
        		<activity android:configChanges="keyboardHidden|orientation" android:label="ActionBar" android:name=".ActionbarActivity">
        			<intent-filter>
        				<action android:name="android.intent.action.MAIN"/>
        				<category android:name="android.intent.category.LAUNCHER"/>
        			</intent-filter>
        		</activity>
        
        <!-- the rest of your manifest... -->
        
                </application>
        </manifest>
        

    Finally, here's a super basic example of how I was using it. The camera.png image has been attached to the ticket for reference:

        var win = Ti.UI.createWindow({
        	navBarHidden: false,
        	fullscreen: false,
        	actionBar: true,
        	activity: {
        		onCreateOptionsMenu: function(e) {
        			var menu = e.menu;
        			for (var i = 0; i < 6; i++) {
        				var menuItem = menu.add({ title: "Item " + (i+1) });
        				menuItem.setTitle('Item ' + (i+1));
        				menuItem.setShowAsActionFlags(
        					Ti.UI.Android.SHOW_AS_ACTION_IF_ROOM | Ti.UI.Android.SHOW_AS_ACTION_WITH_TEXT
        				);
        		    		menuItem.setIcon("camera.png");
        			} 
        		}	
        	},	
        	exitOnClose: true
        });
        var label = Ti.UI.createLabel({
        	text: 'Window',
        	font: {
        		fontSize: '40dp',
        		fontWeight: 'bold'	
        	}
        });
        label.addEventListener('click', function(e) {
        	Ti.UI.createWindow({
        		backgroundColor: '#a00',
        		//actionBar: true,
        		//navBarHidden: false
        	}).open();
        });
        
        win.add(label);
        win.open();
        
        

15. Ivan Skugor 2012-05-14 I think that everyone wants to use new features ASAP, but don't want to ignore devices that do not support new features. Because of that, setting minimum API level probably is not the best solution (the most Android devices are < 3.0 API). It would be awesome if we could detect what device supports, like:

        if (typeof Ti.UI.createActionBar == 'function') {
            //use ActionBar
        }
        else {
            //provide fallback, ActionBar emulation, whatever
        }
        

    This is something that is already present on the web. Don't know is this technically posible to implement, but it seems nice solution for me.
16. Tony Lukasavage 2012-05-14 ivan, the actionbar isn't a create-able UI component per se. It is the result of having a title bar, paired with the Android theme that has been selected for your app/activity. It's appeareance is determined based on the Android Theme, the Android menu that you associate with it, and the additional APIs for that menu that correspond to the ActionBar. You'll notice in my sample code that no UI component is created for it, it's look and behavior are determined by the menu I specify in my window's activity. The beauty of the ActionBar, Ivan, is that is gracefully degrades. On devices that do not support the ActionBar, the attached menu will apear as it always, accessible through the Android menu button. On ActionBar supporting devices, the ActionBar will appear with the same code. Again, all this behavior is determined by the device API level, the Android theme, and the menu attached to the current activity.
17. Ivan Skugor 2012-05-14 OK, I see, thanks Tony.
18. Stephen Feather 2012-05-14 Ivan, Until worked out in code, a solution to the min-sdk problem is to submit two active binaries to Google Play. One for older devices and one for the newer devices.
19. Tony Lukasavage 2012-05-14 Guys, notice that the min-sdk I'm using is level 8, meaning Android 2.2, the lowest version supported by Titanium. ActionBar code, implemented correctly, can exist on devices that don't yet support it. The target-sdk is the important value.
20. Alberto Berti 2012-05-14 Tony, as a suggestion have you had a look at this sample where seems to be possible to partially support actionBar also on older android releases like gingerbread? http://developer.android.com/resources/samples/ActionBarCompat/index.html
21. Tony Lukasavage 2012-05-14 Yep Alberto, I've seen that. We need to get a solid implementation of the basic ActionBar in, though, before we worry about Android's compat version for older devices. Also, that compat version is part of the samples collection for Android, it's not actually an API, it's custom code.
22. Jon Whitter 2012-05-15 Great work Tony! On note on the backward compatibility. When its time to look into it take a loot at this first http://actionbarsherlock.com/. It a cool tool set that wraps up the Android compatibility package and a few other bits and pieces to create a fully functional action bar on older devices. It's usage is really simple just need to change a few imports in a project and bang you have an action bar on Gingerbread. Don't know if its helpful but definitely worth a look.
23. Karl Åström 2012-06-04 Tony, The compat version is specifically intended to use the new ActionBar on newer devices and a fairly compatible implementation of ActionBars on older APIs. Why not use that starting point to get a solid implementation of ActionBar without throwing away older devices unnecessarily?
24. Paul Hamilton 2012-06-04 the compat version is just custom code, not an API call. The way ActionBar is, currenly allows for the use of older devices (which is still over 90% of them) if set up correctly. They would need to get the ActionBar API in place before they could do the custom code part.
25. Josh Roesslein 2012-07-05 Seems we just need to document how to adjust the "target" API level to enable the new ActionBar menu items. This should be compatible with previous API levels and not require any platform changes on our part. To expose some of the new MenuItem properties (ex: actionView) and adding a ActionBar proxy requires some core planning and refactoring. We currently don't have a good way to expose newer Android APIs in core while remaining backwards compatible. As Tony pointed out the current way to do this is by creating external modules.
26. Matthew Delmarter 2012-09-04 Any progress on this? I am just starting on Android Dev using Titanium, and this was one of the first Ui widgets I went looking for as I am trying to follow the Google UI guidelines for Android.
27. Josh Roesslein 2012-09-19 @Matthew We have extended the Menu API (Ti.Android module) to support some of the new APIs introduced for Action Bar menu items ("action items"). These new methods are documented in the master branch API documents. We also added support for action bar style tab groups. The tab group API has no changes, but if you set the "targetSdkVersion" in your android manifest to 11 or higher you get this new style automatically. As this feature approaches our release more guides and documentation for these new Android features should appear.
28. Josh Roesslein 2012-09-19 All sub-tasks have been completed. Resolving this task.
29. Henry Belmont 2012-10-08 Was this shipped in the last release (v2.1.3)?
30. Shannon Hicks 2012-10-08 Henry - You can see what version any ticket [will be/was] fixed in. Look at the "Fix Version" field. In the case of this ticket, it's set for 3.0
31. Igor Santos 2012-11-06 -I've managed to download the 3.0.0 Build and installed successfully, and also added the targetSdkVersion to >11.- -I've tested it into the sample code and I still got the old/ugly tabs and old UI. How do I exactly implement this?- -I couldn't find any doc on that either.- -Here's the Manifest.xml if you want to take a look at it.- Not sure what was happening but I managed to get it working.
32. Shyam Bhadauria 2012-11-19 The action bar is visible on newer android sdks and older sdk is not getting any error/exception because of it. Checked it on following devices: Samsung Galaxy Nexus - Android 4.0.2 LG-P970 - Android 2.2.2 Titanium SDK:3.0.0.v20121113170203 Titanium  Studio:3.0.0.201211131839 Now the updates and bugs would do the work,if required.
33. Igor Santos 2012-11-21 Not sure if I'm missing something, but {modal:true} creates a new window with the old, gray title bar, and not with the ActioBar.

JSON Source