Satscard Integration (Android) #1258
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Successfully builds
- Validates spend code input - Has an optional chain code field with validation - Needs to react to the onPressed event and perform the initialization
- Required due to a limitation of the nfc_manager v3 API - This will allow for Satscard events to work properly
- Required for certain Android devices to process the CKTapCard::Wait command
- Allows for various stages of Satscard operations to be communicated (e.g. NFC commands, waiting for authDelay to reduce, errors, success, etc) - Add a unique prompt when a Satscard is used up - Perform the Satscard::New() on unused slots
- Fixes issues with the listening method not transitioning after opening the Satscard operation dialog
- Makes it easier to communicate errors and allow the user to fix incorrect information such as the spend code
- Ensure logging is in line with new Breez standards
- Requires balance retrieval to be implemented, otherwise feature complete
- Also fix issue when tapping an option without an onSelect callback being registered
- Logic should be much clearer - Added the transaction ID - Auto-close on success
- Also report errors to the user
- Handle deposit conditions better - Remove error setState madness - Better order in the file
- Remove getMempoolRecommendedFees - Change getMempoolAddressInfo name - Pubkey scripts should now be retrieved from mempool.space
- Support sweeping unsealed slots - Fix refactoring errors
PeteClubSeven
force-pushed
the
feature/satscard-integration
branch
from
66b7522 to
867d53f
Compare
PeteClubSeven
force-pushed
the
feature/satscard-integration
branch
from
867d53f to
433cf04
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey, this is my implementation of Satscard slot initialization and sweeping. The logic for communicating with Satscards is handled by a separate Flutter plugin which I created. This plugin is relatively simple, it provides an FFI wrapper around Nunchuk's tap-protocol library. Maintenance should be minimal, I created a separate release/breez branch in the plugin repository, this will get updated as Nunchuk update their C++ library. I will do further work myself to support the Tapsigner however this won't be relevant for Breez which is why I created a release branch. You may wish to fork my plugin if you prefer control over the repository, I could then open PRs when I think there's a bugfix you might need. My plugin is built for NDK 21.4, it could work with NDK 22 but NDK 23+ and onwards are incompatible for now until a tap-protocol change. I tested almost exclusively with NDK 21.4 but it seems like NDK 19 (the version used by Breez) does compile. However it seems theres some plugins in the app that require NDK 21.4. What would be preferable?
This PR doesn't support viewing/sweeping unsealed slots however I wish to add that later and the current balance/sweep UI pages are built to support it already. Each UI page supports vertical scrolling for small displays. The initialize page has fully validated "Spend Code" and "Chain Code" fields. The new Satscard NFC dialog is quite reactive and communicates different success, pending and failure states to the user. Sweeping a Satscard clearly communicates the fees paid by the user including failure conditions such as not having enough balance to deposit, having too high a balance, not meeting the reserve, etc. The "Spend Code" field rejects previously entered incorrect codes, intentionally I chose not to persist these between pages. If a "Chain Code" is not entered then it will be generated by the tap-protocol library.
The PR depends these two other PRs: breez/Breez-Translations#26 & breez/breez#229
Here are a selection of images and videos demonstrating the implementation:
initialize.mp4
sweep.mp4
nfc_errors.mp4