[TIMOB-17964] Android 5.0: Add support for Toolbar
GitHub Issue | n/a |
---|---|
Type | New Feature |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2017-08-24T21:34:30.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 6.2.0 |
Components | Android |
Labels | implementWithHyperloop, merge-6.2.0 |
Reporter | Ingo Muschenetz |
Assignee | Yordan Banev |
Created | 2014-11-05T18:43:27.000+0000 |
Updated | 2017-09-01T00:23:28.000+0000 |
Description
Android 5.0 introduces a new "Toolbar" widget.
"A Toolbar is a generalization of action bars for use within application layouts. While an action bar is traditionally part of an Activity's opaque window decor controlled by the framework, a Toolbar may be placed at any arbitrary level of nesting within a view hierarchy. An application may choose to designate a Toolbar as the action bar for an Activity using the setActionBar() method."
https://chris.banes.me/2014/10/17/appcompat-v21/
It suggests that in most cases we can use the Toolbar as the replacement for the ActionBar, though we may wish to provide the ActionBar for specific usages.
Specifics and usage suggestions as per Android Material Design
https://www.google.com/design/spec/layout/structure.html#structure-toolbars
Adding this link to the convo : http://android-developers.blogspot.com/2014/10/appcompat-v21-material-design-for-pre.html
I'm really looking forward to a progress update on this
Any update on this feature ? Would be great ! thanks.
I think the first step could be creating a view proxy for the toolbar as you should be able to add it to a window (unlike the actionbar). At the same time the BaseActivity must set the toolbar as its ActionBar and adopt the menu creation. I'd love to give it a try but I have too much stuff to do at the moment :(
Makes sense to me @manuelleehner. @ingo / @chee, what's the latest on this folks?
+1
Looking forward
+1
+1
+1
+1
+1
-Also requested on SO:- http://stackoverflow.com/questions/36941875/appcelerator-android-new-bottom-navigation-bar
[~fokkezb] The bottom navigation bar was just added to the design guide. This is not a Toolbar. It's a complete new component (and there's no native class for it, not yet).
[~manuellehner] o wait, I was rushing through SO questions to fast. This is the new iOS Tabgroup for Android! I really hope Android implement that.. don't like it, even though with larger screens bottom tabgroups do navigate better than top navigation or drawer layouts.
updates about this?
[~jquick], yes, that sounds reasonable. But I had another concept in my head. Toolbar is implemented as a new UI component that can be used as any other widget. With a layer of abstraction I made it accessible as a parameter for the setSupportActionBar() method from the UI module. My concern was that this method expects an instance of Toolbar. And Toolbar does not have borders by default. So the only way to have borders would be to extend the class and override it's doLayout method. Which is possible of course, but I am not sure if it is worth it for having borders (it does quite a lot of things). As for a concept of adding Toolbar support I went that way: Have it available as a separate widget, since we have it on iOS. Support what can be supported without much trouble on both platforms (translucency, color, etc...) and add Android only methods and properties. That way we could maximize code reusing for basic toolbars. Add the option to pass it as an ActionBar for Android activities. Since we support Theme.AppCompat.NoActionBar I decided we should use it if we want more customizable ActionBar. That's the most common way in Android IMO.That way you get a Toolbar instance which supports ActionBar's methods through the
activity.actionBar
reference from the docs. So I actually never thought about having both Toolbar and default ActionBar at the same time acting as an ActionBar, because the theme disables it. Now that I think about it, it may be too Android-ish approach.PR: https://github.com/appcelerator/titanium_mobile/pull/9147
A quick note that I've also discussed with [~ybanev]: We should definitely move the proposed
Ti.UI.Android.Toolbar
namespace toTi.UI.Toolbar
, so we can moveTi.UI.iOS.Toolbar
back to the old namespace and add Android parity on that one. It will give a huge bump in terms of a unified API, similar as we recently did for theTi.Media.AudioRecorder
and planning to do withTi.UI.iOS.NavigationWindow
as well.I have created TIMOB-25003 to bring a unified cross-platform API for Ti.UI.Toolbar together with iOS. So for this ticket, the existing PR must move from Ti.UI.Android to Ti.UI as well (basically just a few adjustments in the class-naming I guess). After that, we will do an Alloy-PR that will also be listed in TIMOB-25003 to remove the platform-specific handling.
6_2_X: https://github.com/appcelerator/titanium_mobile/pull/9329
Would it be possible to add scrollFlags (http://karthikraj.net/2016/12/24/scrolling-behavior-for-appbars-in-android/) to hide the Toolbar when scrolling content up?
FR Passed for both master & backport PR. PR's merged.
Verified the fix with SDK 6.2.0.v20170825165823 & 7.0.0.v20170825165854. Closing. Studio Ver: 4.9.1.201707200100 SDK Ver: 6.2.0.v20170825165823, 7.0.0.v20170825165854 OS Ver: 10.12.3 Xcode Ver: Xcode 8.3.3 Appc NPM: 4.2.9 Appc CLI: 6.2.3 Ti CLI Ver: 5.0.14 Alloy Ver: 1.9.13 Node Ver: 6.10.1 Java Ver: 1.8.0_101 Devices: ⇨ google Nexus 5 — Android 6.0.1 ⇨ google Pixel — Android 7.1.1