[TIMOB-20406] ProgressBar: Width should default to Ti.UI.FILL

GitHub Issue	n/a
Type	Improvement
Priority	High
Status	Closed
Resolution	Fixed
Resolution Date	2016-03-28T21:31:16.000+0000
Affected Version/s	Release 5.2.0
Fix Version/s	Release 5.4.0
Components	iOS
Labels	AL-5.4.0, autolayout, progressbar, qe-5.4.0
Reporter	Fokke Zandbergen
Assignee	Hans Knöchel
Created	2016-02-15T14:34:36.000+0000
Updated	2016-07-19T23:01:29.000+0000

Description

It makes no sense to me that the width of a ProgressBar defaults to Ti.UI.SIZE. In particular without a message it's of no use that way. And since that means everyone who uses it has manually set it to Ti.UI.FILL or an absolute/relative value, we can change this to be Ti.UI.FILL without likely breaking any app at all.

var win = Ti.UI.createWindow({
  backgroundColor: 'white'
});

win.add(Ti.UI.createProgressBar({
  top: 50,
  value: 0.5,
  backgroundColor: '#eee'
}));

win.add(Ti.UI.createProgressBar({
  top: 100,
  width: Ti.UI.FILL,
  value: 0.5,
  backgroundColor: '#eee'
}));

win.add(Ti.UI.createProgressBar({
  top: 150,
  value: 0.5,
  message: 'Half way there',
  backgroundColor: '#eee'
}));

win.add(Ti.UI.createProgressBar({
  top: 200,
  width: Ti.UI.FILL,
  value: 0.5,
  message: 'Half way there',
  backgroundColor: '#eee'
}));

win.open();

Attachments

File	Date	Size
Simulator Screen Shot 15 Feb 2016 15.31.24.png	2016-02-15T14:34:28.000+0000	22123

Comments

Malcolm Hollingsworth 2016-02-15

The reason it does not default to *Ti.UI.FILL* is simple; it fails both rules that would have required it. * It is not a container view (like Window or View) or a view that gains containers like (TabView or ScrollableView) * The OS default behaviour on all platforms is not consistently the native equivalent of Ti.UI.FILL These were the rules when Ti.UI.SIZE and Ti.UI.FILL were introduced back in Ti SDK 1.8.x.
Fokke Zandbergen 2016-02-16

Thanks Malcolm. I like rules for a consistent API, but exceptions can sometimes make an API more predictable as well. That's probably why we did the same for Slider (See Mixed Behavior column): http://docs.appcelerator.com/platform/latest/#!/guide/Layouts,_Positioning,_and_the_View_Hierarchy-section-29004895_Layouts,Positioning,andtheViewHierarchy-AutoSizeBehaviors And that's why I think we should do the same for ProgressBar (and probably TextField as well, btw)
Malcolm Hollingsworth 2016-02-16
Hans Knöchel 2016-03-25

Thank you Malcom, happy to have fans on the platform. To come back to topic: Tested this issue with and without autolayout enabled. Autolayout makes it FILL, current layouting makes it SIZE. If we decide to make it FILL (which I would recommend). If we take a look at the native example, creating a UIProgressView without specifying a frame does not draw the view. [~fokke] Please decide here.
Hans Knöchel 2016-03-25

As you already suggested above, we are good with marking it in the release notes, but nothing will break (since SIZE didn't even show the view). Solution incoming: PR: https://github.com/appcelerator/titanium_mobile/pull/7886
Fokke Zandbergen 2016-03-28

[~hansknoechel] what do you think about textfield?
Hans Knöchel 2016-03-28

Yes, we should do the same there. Do we have a ticket for that?
Fokke Zandbergen 2016-03-29

We do now: TIMOB-23119
Harry Bryant 2016-07-19

Verified as fixed, given the demo code, all progress bars are set to Ti.UI.FILL as default. This occurs both with Autolayout set to true & false. Tested On: iPhone 6S (9.3.2) Device Mac OSX El Capitan 10.11.5 Ti SDK: 5.4.0.v20160713141635 Appc Studio: 4.7.0.201607111053 Appc NPM: 4.2.7 App CLI: 5.4.0-33 Xcode 7.3 Node v4.4.7 *Closing ticket.*

JSON Source