Android Picker Not Consistently Firing onValueChange

Issue Description

Since Picker uses RN’s Picker under the hood for Android, all issues from RN’s Picker is inherited by NativeBase Picker. This issue is only created for the record because I could not figure out this bug quickly, but there is indeed an related issue in RN’s repo.

Steps to Reproduce

The STR requires using redux state to keep track of selected values, specifically redux-form in my case:

render () {
  const {
      input: { value, onChange, ...inputProps },
  } = this.props
  return (
       <Picker
          selectedValue={value}
          onValueChange={onChange}
          {...inputProps}
        >
  );
}

Pick a value thats not the selected value, then repeat a few times.

Expected behaviour

onValueChange should be fired every single time the value is different from the previous. (EDITED) The value is selected and the picker shows the new value, however, some of the times onValueChange is not fired.

Actual behaviour

The value is selected and the picker shows the new value, however, some of the times onValueChange is not fired. (EDITED) onValueChange should be fired every single time the value is different from the previous.

Environment

• React version: 16.0.0
• NativeBase version: 2.3.6
• React Native version: 0.50.3
• Platform(s) (iOS, Android, or both?): Android
• Device info (Simulator/Device? OS version? Debug/Release?): Simulator / Android 6 / Debug

Is the bug present in both ios and android or in any one of them?

Android only.

[leoskyrocker]

I mentioned that it’s not a direct issue here and I’ve referenced the issue in my original post. However, I opened an issue here because it is a problem from the perspective of native-base users.

However, you guys can handle this however you want:

• close upon the issue is actually fixed to reflect the actual status;
• or close right now as there’s no plan to actively fix this problem in native-base.

I’m fine either way as long as there’s a record here which could save people hours.

[toussa]

Indeed, nothing to do with native-base: see react-native issue here, and its workaround for now