Repository navigation
Old ApplicationSettings.getNumber() cannot be returned due to type mismatch #10139
Description
Issue Description
After updating @nativescript/core from 8.3.5 to 8.4.1 (or even 8.4.0) my app breaks due to pull request #10094.
I've stored float values in ApplicationSettings and it worked like a charm. After updating the core, the app tries to return these values but it fails, because they can't be cast to long values.
There should be at least a check or TRY-CATCH-Block to prevent crashes. An even better solution would be an auto-migration to convert these wrong values before returning these values.
Reproduction
- Create an app with version 8.3.5
- Store any float value in App Settings via .setNumber()
- Update core to 8.4.0 or 8.4.1
- try to .getNumber()
Relevant log output (if applicable)
java.lang.ClassCastException: java.lang.Float cannot be cast to java.lang.Long
getNumber(file:///data/data/de.XXX.android/files/app/vendor.js:5578:68)
at
...Environment
No response
Please accept these terms
- I have searched the existing issues as well as StackOverflow and this has not been posted before
- This is a bug report
- I agree to follow this project's Code of Conduct
Activity
CatchABus commentedon Dec 20, 2022
@Semurak Hello. I think your problem occurs because new getter is not compatible with your old values inside storage.
If you use
setNumberagain and callgetNumber, then problem will be gone.In few words, you have to store all your data anew in order to retrieve them using the new format.
I'll see if we can add a try-catch to use
getFloatas a fallback migration but keep in mind what I mentioned above so that you use new number storage properly.Semurak commentedon Dec 20, 2022
Jup, it seems not compatible. In my use case its not possible to just re-set them without a user action or a data-loss. In both cases its bad design.
It would be great to support the old format just for the getter. Updated values will be stored in the new format and it should be fine.
Thanks for your fast reply and attempt to fix it!
CatchABus commentedon Dec 20, 2022
I see, your use case makes perfect sense and we should do something about it.
If it's not a bother, I'd like you to revert this specific patch from your node modules until next release.
Thanks a lot for the explanation!
Semurak commentedon Dec 20, 2022
Thank you!