Add barcode encoding support
- Add new barcodeencoding field to database
- Read barcode encoding from pkpass file
- On default, use zxing's GuessEncoding function in StringUtils (this should not use UTF-8 unless needed)
- Allow manually forcing ISO-8859-1 or UTF-8
TODO:
- [ ] Fix Catima import/export
- [ ] Test test test test test
- [ ] Re-read the code over and over, this feels like a mess, may contain bugs :(
- [ ] Do another release without this fix
@joserebelo Before I finish this, I have a question for the Gadgetbridge side of this:
The plan is to add a new barcodeEncoding field, which defaults to auto (null) if it is not set, unless a pkpass file explicitly sets it. When it is set to "auto", Catima will ask zxing to guess if it should use UTF-8 or not.
What would be the best behaviour for the ContentProvider update?
- I'm planning to bump the minor version, as adding a new field is not incompatible
- For the
barcodeEncodingfield in the ContentProvider, should it returnnull, just like it does in the database, or should it return the "guessed" encoding that Catima would use to display, so Gadgetbridge doesn't have to guess (but technically has "incorrect" data, as it's null in the database)?
Edit: With regards to 2, I think it makes most sense for the ContentProvider to give the simplest usable data to draw a card, instead of the exactly correct info. If full export-import compat is desired, the exporter seems more sensible to use anyway. So, barcodeEncoding would give whatever Catima would be using, guessed or not, but never null.
@TheLastProject apologies for the delay, I was away and just now catching up no a few notifications.
- A minor version bump would be the expectation for a new field.
- I believe it would indeed make sense for the field to contain the guessed value. The fact that we currently expose the database is an implementation detail that greatly simplified the implementation at the time, but I think the content provider should serve as a higher level interface, and indeed provide usable data.