Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-2908] iOS: Switch - Disable animation on init and allow developer to disable for setValue

GitHub Issuen/a
TypeBug
PriorityTrivial
StatusClosed
ResolutionFixed
Resolution Date2015-11-23T22:15:39.000+0000
Affected Version/sn/a
Fix Version/sRelease 5.2.0, Release 5.1.2
ComponentsiOS
Labelsapi, switch
ReporterAlan Leard
AssigneeChee Kiat Ng
Created2011-04-15T03:32:37.000+0000
Updated2015-11-26T03:47:56.000+0000

Description

When loading a switch with a value set to 'true' the switch shows an animation going from 'off' to 'on'. Users would like a property added to the switch object of 'animate' as a boolean value, to turn off the animation on-load if the value of the switch is preset to true. Reference ticket: http://developer.appcelerator.com/helpdesk/view/67301

Comments

  1. Malcolm Hollingsworth 2014-07-02

    Any movement on this? Seems like an oversight that it is still not resolved? Stock iOS apps do not exhibit this behaviour .
  2. Fokke Zandbergen 2014-07-02

    [~ingo], I say we even just set the initial animation off by default. It will then still animate when the users taps it but not when you set it programmatically. I've recorde 2 movies to show the difference. The next dropbox folder also includes a module that disabled the animation. * https://www.dropbox.com/sh/aq88p58jc3sfe63/AABUm5MHzobnqH16fiabYRrVa Otherwise I'd would indeed request for setValue(value, animated).
  3. Fokke Zandbergen 2015-01-06

    PR: https://github.com/appcelerator/titanium_mobile/pull/6539
  4. Malcolm Hollingsworth 2015-01-06

    Does this stop the creation animation [~fokke] or are you providing a toggle for the animation state? Ideally the animation should not exist on creation value of true. However toggling the state later in code could allow animation without issue. An option to toggle post creation animation is nice but not required. Just seeking clarification on the result of the PR.
  5. Fokke Zandbergen 2015-01-06

    it will disable the animation when you programmatically set the value. When the user toggles it will still animate.
  6. Malcolm Hollingsworth 2015-01-06

    I am not sure this is the correct direction. With ScrollableView you have the choice to animate from the current state to the chosen state or to simply arrive at the new state without animation. This logic occurs in many of the views with animation. The use of animation (which is ever increasing) is to show the user a change of state. During creation animation is rarely if ever required as the presented information 'simply is'. However if the developer makes a code change on behalf of the user (not setting a default value) then the idea IS to draw attention to the thing that changed. So I still believe that creation value should NOT animate, post creation SHOULD animate, although there is good logic to have that as an OPTION.
  7. Tim Poulsen 2015-11-10

    At creation, the switch should be rendered on screen already set to its starting value. This is not the case currently. If you create a switch with a starting value of true/on, you first see the switch in the false/off position, then a moment later it changes to true/on. Whether it animates that way or not is beside the point. A switch with a starting value of true/on should never be shown as false/off. For subsequent changes (after the initial rendering), yes, I'd like to have the flexibility to enable/disable animation when programmatically setting the value.
  8. Fokke Zandbergen 2015-11-10

    +1
  9. Malcolm Hollingsworth 2015-11-10

    How on earth is this still an outstanding item? Created April 2011, Bumped multiple times; including by myself almost 18 months ago. PR ready at the start of the year but still has a priority of "Trivial" and no schedule info. Why are core elements like this being so long forsaken.
  10. Ingo Muschenetz 2015-11-10

    FYI. We should take the PR into 5.1.1
  11. Chee Kiat Ng 2015-11-17

    Sample code: 
        var win = Ti.UI.createWindow({
      backgroundColor : "#fff"
    });
    
    var mySwitch = Ti.UI.createSwitch({
    	top: 40,
    	value: true,
    	animated: false
    });
    
    var myButton1 = Ti.UI.createButton({
    	top: 80,
    	title: 'toggle switch'
    });
    
    var myLabel = Ti.UI.createLabel({
    	top: 120,
    	text: typeof mySwitch.animated==='undefined'? 'animated is default true' : 'animated is ' + mySwitch.animated
    });
    
    var myButton2 = Ti.UI.createButton({
    	top: 160,
    	title: 'set animated'
    });
    
    myButton1.addEventListener('click', function(e) {
    	mySwitch.setValue(!mySwitch.value);
    });
    
    myButton2.addEventListener('click', function(e) {
    	mySwitch.setAnimated(!mySwitch.animated);
    	myLabel.setText('animated is ' + mySwitch.animated);
    });
    
    win.add(mySwitch);
    win.add(myButton1);
    win.add(myButton2);
    win.add(myLabel);
    win.open();

    Steps to test

    1. Set 'Slow Animations' on ios simulator (cmd-T) 2. build and run sample code 3. click 'toggle switch' 4. click 'set animated' 5. click 'toggle switch' 6. Repeat step 2 to 3, but changing sample code animated: true 7. Repeat step 2 to 3, but changing sample code to remove animated: ENTIRELY

    Expected results

    2. Switch value is 'true' with ZERO animation 3. Switch value will change with ZERO animation 5. Switch value will change WITH animation 6. This is the test case with animated property set to false during creation. there is still ZERO animation when launched, but clicking 'toggle switch' you can see values change WITH animation. 7. This is the test case whereby you don't set the animated property at all (default is TRUE). there is still ZERO animation when launched, but clicking 'toggle switch' you can see values change WITH animation.
  12. Chee Kiat Ng 2015-11-17

    Master PR: https://github.com/appcelerator/titanium_mobile/pull/7456 5_1_X backport PR: https://github.com/appcelerator/titanium_mobile/pull/7457 (Do not merge until 5.1.0.GA)
  13. Fokke Zandbergen 2015-11-17

    [~cng] and [~hansknoechel] (reviewing) I don't think the implementation is clear. Having a global animation property on the object doesn't make clear what exactly is (not) animated. You'd easily think that if the user toggles it the control it will not animate either, which is not correct (right?) - it will always animate when the user toggles it. It would find this a lot clearer and also more in line with other API's like: https://appcelerator.github.io/appc-docs/latest/#!/api/showParams-property-animated 
        var mySwitch = Ti.UI.createSwitch({
    
    	// initial value should NEVER be animated
    	value: true
    });
    
    // programmatically setting it should NOT animate by default (unlike now)
    mySwitch.value = false;
    mySwitch.setValue(false);
    
    // if you do want animation when setting it programmatically you should be able to do:
    mySwitch.setValue(false, {
    	animated: true
    });
  14. Chee Kiat Ng 2015-11-18

    After attempting to achieve the 2nd proposition, i realised it's not quite possible to code. We cannot do switch.setValue(Boolean, Dictionary). If you observe OptionDIalog.show carefully, we are actually intending to do: 
        switch.setValue({
        value: true,
        animated: true
    });
    And this would be a problem for UISwitch creation. because you are expecting people to do this now: 
        var mySwitch = Ti.UI.createSwitch({
    	top: 40,
    	value: {
                value: true,
                animated: true
           }
    });
    The reason why is because Titanium uses the same setValue method during creation. It is possible to do it such that value can either be a Boolean or Dictionary so that we can stick back to the old style for creation while maintaining the new style for post-setValue, but in the future, deprecating setValue(Boolean) will then be an issue. That would imply that we need people to createSwitch in the new style. Unless, we introduce a new method called setValueWithAnimation(Dictionary). and consider setValue(Boolean) inherently uses default animation = true. Or. Use my proposition for a global animated property.
  15. Fokke Zandbergen 2015-11-18

    Even if Titanium uses setValue on creation, how is it a problem if the second argument is optional?
  16. Malcolm Hollingsworth 2015-11-18

    I did not understand how the points 2-7 on expected results helps explain the situation. This needs to be really simple;

    Switch animations _should not_ occur if property 'value' is set to 'true' on creation

    Switch animations _should_ occur during any user interaction.

    It would be ideal if *setValue* gained an optional parameter of animated (where the default is true)

    *switch.setValue(true)* = animation if previous value was false

    *switch.setValue(false)* = animation if previous value was true

    *switch.setValue(true, true)* = animation if previous value was false

    *switch.setValue(false, true)* = animation if previous value was true

    *switch.setValue(true, false)* = no animation

    *switch.setValue(false, false)* = no animation

    Optional syntax; 
        switch.setValue(true, {
      animated: false
    });
    This would then use a similar property syntax as method *open* on *window*.
  17. Chee Kiat Ng 2015-11-19

    Maybe i can explain this another way. Value is a property. setValue() and getValue() is a property setter and getter. Not really a method that we can do the fancy stuff like setValue(Boolean, (optional){Dictionary}) or to better understand this, what can i expect to get for getValue() if i somehow implemented the above method? The closest way we can achieve this is to set the property to an array. Which we cannot do because of parity with other platforms. So only my global animated makes sense here. OR, we can make an exclusive ios method setValueWithAnimation(Bool, Dict).
  18. Chee Kiat Ng 2015-11-19

    [~core13], sorry if my test steps aren't clear. Rest assured, the most important part is already fixed in this PR: {quote} Switch animations should not occur if property 'value' is set to 'true' on creation Switch animations should occur during any user interaction. {quote} You can test out the PR if you want while we are still reviewing the latter: {quote} It would be ideal if setValue gained an optional parameter of animated (where the default is true) {quote}
  19. Fokke Zandbergen 2015-11-19

    [~cng] I found a proxy that does the exact same thing which we can copy from: * https://github.com/appcelerator/titanium_mobile/blob/master/iphone/Classes/TiUISlider.m#L235-L247 * https://appcelerator.github.io/appc-docs/latest/#!/api/Titanium.UI.Slider-method-setValue
  20. Chee Kiat Ng 2015-11-23

  21. Hans Knöchel 2015-11-23

    Discussed the issue with [~cng] and [~penrique] last week: It makes more sense to use the solution of Kiat, instead of configuring it using an options object. It is more flexible and internally much cleaner. Please review the approve and I will merge it after we agreed.
  22. Fokke Zandbergen 2015-11-23

    Well if there's no other solution I guess we better resolve it with what we can do. Maybe rename animated to something like setValueAnimated to make it clear it does *not* effect animation when user changes value?
  23. Malcolm Hollingsworth 2015-11-23

    So no solution for or wish to attend to the following? {quote} It would be ideal if setValue gained an optional parameter of animated (where the default is true) {quote}
  24. Fokke Zandbergen 2015-11-23

    Yes, it seems so :(
  25. Hans Knöchel 2015-11-23

    It is a architectural decision. You can make a switch non-animated by default: 
        var switch1 = Ti.UI.createSwitch({
      animated: false
    });
    or leave it animated (default): 
        var switch2 = Ti.UI.createSwitch();
    or change its animation behavior for manual cases: 
        switch2.setAnimated(false);
    switch2.setValue(false);
    This feature will be available in 5.1.1 and 5.2.0.
  26. Harry Bryant 2015-11-23

    Verified as fixed, ran the sample code & test cases provided by [~cng] and build with SDK: 5.1.1.v20151123142050. Toggling animation on switch functions correctly, and removing the animated property from the code sets the switch to be animated by default. Tested on: Devices: iPhones 6S (9.1) Simulators: (9.1) Mac OSX El Capitan 10.11 (15A284) Ti SDK: 5.1.1.v20151123142050 Appc Studio: 4.4.0.201511182122 Appc NPM: 4.2.2 Appc CLI: 5.1.0-60 Alloy: 1.7.26 Xcode 7.1(7B91b) Node v0.12.7 *Closing ticket.*
  27. Chee Kiat Ng 2015-11-26

    To Note: This ticket is marked 5.1.2 but PR was merged in 5.1.1GA

JSON Source