If zxing is not explicitly told a barcode is UTF-8, it may render it
incorrectly. Which caused
https://github.com/CatimaLoyalty/Android/issues/2555.
However, when an encode hint is set, it will cause zxing to set an ECI
hint inside the barcode, which some scanners may trip over and cause
scanning failures, leading to
https://github.com/CatimaLoyalty/Android/issues/2921.
This change only passes the encoding in automatic mode if zxing
explicitly guesses it to be UTF-8, and otherwise doesn't pass anything,
to keep the ECI empty. This might need to be expanded for other types
like SJIS, but as nobody ever reported such a bug let's assume it's not
necessary for now.
This simplifies the codebase and new Compose implementation. If this
feature is really wanted by the community, it could possibly be
reimplemented in a much more flexible way (choosing the exact colour)
after all UIs are migrated to Compose, as Compose can generate a theme
based on just a primary colour.
* WIP
* test: Add test tags for compose components
* test: Add basic test for compose about screen
* refactor: Add defaults for `AboutScreenContent`
* refactor: Move compose tests to unit tests
* refactor: Make `showRateOnGooglePlay` default to `app/build.gradle.kts/defaultConfig` value
* refactor: Best practise to make previews private to reduce pollution
* refactor: Best practise apply theme as high as possible for most cases
* style: Format AboutActivity.kt
* test: Add more comprehensive tests for about screen
* test: Fix configuration of compose tests
* Fix Gradle setup
* Fix build issues
* Adjust text sizing
* Use full black OLED theme in Compose if chosen in settings
---------
Co-authored-by: LooKeR <iamlooker@proton.me>
- Add new barcodeencoding field to database
- Read barcode encoding from pkpass file
- Add barcodeencoding to import/export
- Add barcodeencoding to share URI
- 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
This swaps the currency and balance fields to reduce the risk of users
entering a decimal value (1,23) first and having to changed to 1 due to
the default currency (Points) having no decimals.
The changes in the LoyaltyCardEditActivity are purely cosmetic, just a
swap of function order to more closely stick to the order in the XML
layout file
Refactored `ImportExportActivity` and its corresponding test class from Java to Kotlin. The new implementation uses modern Kotlin idioms and syntax while preserving the original functionality.
* Rename .java to .kt
* Convert SettingsActivity to Kotlin
Refactored the `SettingsActivity` and its inner `SettingsFragment` from Java to Kotlin, adopting modern Kotlin idioms and syntax. The functionality remains unchanged.
* Address PR comment: by removing null safety with non-null asserted call operator
* Apply Android Studio suggested fixup
---------
Co-authored-by: Sylvia van Os <sylvia@hackerchick.me>
* Bump com.github.yalantis:ucrop from 2.2.10 to 2.2.11
Bumps [com.github.yalantis:ucrop](https://github.com/Yalantis/uCrop) from 2.2.10 to 2.2.11.
- [Release notes](https://github.com/Yalantis/uCrop/releases)
- [Commits](https://github.com/Yalantis/uCrop/compare/2.2.10...2.2.11)
---
updated-dependencies:
- dependency-name: com.github.yalantis:ucrop
dependency-version: 2.2.11
dependency-type: direct:production
update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>
* Fix build
While testing on Android 15, no difference was found in the status bar
colour on Android 15 with or without the setting
* Use non-native release
* Apply autogenerated ProGuard missing rules
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
An off-by-one error caused invalid colour info to sometimes be generated
if no header colour was set. Under normal conditions, a header colour
should always be set, but due to some bugs in the past in some cases
they may not be set.
Sadly this does change the card colours for cards which are not properly
initialized. But that's better than a crash at least.
With the release of targetSdk 36, the Android platform will no longer
always apply rotation. To lower the chance of user confusion, this
support is being removed completely.
I know some of you really love this, but I can't do anything about this.
This is Google's decision and my opinion doesn't matter.
