[TIMOB-28274] Android: Rewrite Ti.UI.TabbedBar with "MaterialButtonToggleGroup" API
GitHub Issue | n/a |
---|---|
Type | Improvement |
Priority | Medium |
Status | Closed |
Resolution | Duplicate |
Resolution Date | 2021-01-16T03:19:46.000+0000 |
Affected Version/s | Release 9.3.0 |
Fix Version/s | n/a |
Components | Android |
Labels | android, tabbedbar |
Reporter | Hans Knöchel |
Assignee | Joshua Quick |
Created | 2020-12-08T18:57:09.000+0000 |
Updated | 2021-01-17T18:40:54.000+0000 |
Description
Starting in 9.3.0, we have the full power of material components, laying the base for a modern Android UI. During our migration, we noticed that there's an awesome UI component for segmented buttons, similar to the
UISegmentedControl
API on iOS - the MaterialButtonToggleGroup
API.
See the following image on how a button group looks like:
!Bildschirmfoto 2020-12-08 um 19.54.27.png|thumbnail!
There is a nearly 100 % parity possible with iOS and it has the HUGE advantage to size properly, different to the TabLayout
thats currently used. The latter is usually used for full-width activities, but not meant for inline controls. Instead, the MaterialButtonToggleGroup
has a flexible with and also handles icons, tinting and long text better.
More links and references:
- https://material.io/develop/android/components/buttons
- https://medium.com/over-engineering/hands-on-with-material-components-for-android-buttons-76fa1a92ec0a
Attachments
File | Date | Size |
---|---|---|
Bildschirmfoto 2020-12-08 um 19.54.27.png | 2020-12-08T18:54:36.000+0000 | 91106 |
Couldn't wait for this to be realized ~ https://github.com/hansemannn/titanium-android-tabbed-bar
I'm thinking
Ti.UI.TabbedBar
on Android should remain as-is and continue to use the native JavaTabLayout
andBottomNavigationView
since they are literal tab widgets. _(Most people would expect a A view namedTabbedBar
to show tabs.)_ Instead, we should create a newTi.UI.OptionBar
which can be set up to use either Android'sMaterialToggleButtonGroup
,ChipGroup
to show material choice chips, orRadioGroup
to show radio buttons. We've received requests to support radio buttons and this is a good place to put it. And theOptionBar
name pairs well with our existingTi.UI.OptionDialog
which also shows radio buttons on Android. I think the newTi.UI.OptionBar
should default to usingMaterialToggleButtonGroup
since it looks similar to the old iOS segmented control.Closing in favor of: [TIMOB-28317]
I have to disagree strongly here - and am a bit surprised there isn't even a discussion before closing this - with multiple people watching this ticket and dozens of other developers already using my workaround-module. {quote} Most people would expect a A view named TabbedBar to show tabs. {quote} Thats the most critical sentence to discuss. They do not. The Ti.UI.TabbedBar was iOS only for 10+ years and once they had parity on Android, they (including me and developers I talked with) wondered about the completely different UI compared to iOS *which they expected*. Now, after a few more years of having a
TabbedBar
API on Android, which doesn't actually work for most designs and has critical/unresolved bugs like not being able to be displayed in a list-view (!), there finally is an API that can help with all those open issues and also provides 90 % parity with iOS. The down sides of an own option bar is obvious: - No parity with iOS (and copying the tabbed bar on iOS to this one is bad design and requires changes that make no sense) - Issues with the already hardly-maintained Alloy (new bindings, wrapper,labels
-tags, ...) - Not being required (one could just expose astyle
property to the tabbed-bar, just like done for the switches and other APIs already) This is a sad decision and I hope the insights help to understand how developers that use Titanium on a daily base position themselves regarding this topic.Also find it a bit confusing to have Ti.UI.TabbedBar, Ti.UI.OptionBar and Ti.UI.ButtonBar at the end that look very similar. I would keep the TabbedBar and use/style it the same as iOS (like mentioned in the first commend/fork by Hans). Having the Chips is really nice but looking at the things you can do with them (eg. selecting multiple options, making it editable, having it slideable, different states...) would make a Ti.UI.OptionBar for radio AND chips very hard to handle and it doesn't have a ireal iOS parity. So it would be very hard to add those options later on. Why not add it as a Ti.UI.Android.Chip and something like RadioGroup/Radio? Makes it easier to find if you know the Material element your are looking for. And if there is no parity for iOS I wouldn't force it to use a TabbedBar.