Add bitcoin unit options in personalisation settings#288
Add bitcoin unit options in personalisation settings#288yashrajd wants to merge 6 commits intocygnet3:devfrom
Conversation
- Update macOS deployment target from 10.14 to 10.15 (3 locations) - Enable GPU validation mode in Xcode scheme - Add secure restorable state support to AppDelegate - Add .build/ and .swiftpm/ to .gitignore - Pin Android NDK version to 29.0.13113456 - Update meta and test_api dependencies
Add Bitcoin unit preference setting with 3 display options: - BTC: '0.00 123 456 BTC' (8 decimals with space separators) - Satoshis: '123 456 sats' (integer with space separators) - Bitcoin Symbol: '₿ 123 456' (integer with ₿ prefix and space separators) The default unit is BTC. Users can change it from Personalisation settings. The preference applies everywhere Bitcoin amounts are displayed (wallet balance, transaction history, send flow, fees, etc.) Backend: - Add BitcoinUnit enum in Rust with display_name() and format_amount() - Add format_with_unit() method to ApiAmount - Use space separators for all Bitcoin unit formatting Storage: - Add setBitcoinUnit() and getBitcoinUnit() to SettingsRepository - Persist preference via SharedPreferences State Management: - Extend FiatExchangeRateState with bitcoinUnit field - Add updateBitcoinUnit() and displayBitcoin() methods UI: - Add Bitcoin unit list item in Personalisation settings - Create ChangeBitcoinUnitScreen with radio button selection - Update all display locations to use preference Display updates in: - Main wallet balance and transaction list - Send flow (amount, fee, confirmation) - Contact transaction details - Fee selection screens
Update amount selection screen to respect Bitcoin unit preference: - Dynamic suffix text: Shows 'BTC', 'sats', or '₿' based on user preference - Decimal keyboard: Enabled for BTC unit to allow decimal input - BTC conversion: Parse decimal BTC input and convert to satoshis - Truncation logic: Use floor() to prevent fractional satoshis - Hint text: Show 'Extra decimals removed - satoshis are the smallest unit' when BTC unit is selected to inform users about truncation - Dust limit error: Format minimum amount in user's preferred unit Input parsing: - BTC: Parse as double, multiply by 100,000,000, floor to whole sats - Sats/₿: Parse as integer, use directly as satoshis All validation (positive amount, within balance, above dust limit) maintained while supporting unit conversion.
Add FilteringTextInputFormatter to BTC unit input field:
- Block typing beyond 8 decimal places (9th digit ignored)
- Silently truncate pastes with >8 decimals to 8 decimals
- Use regex pattern ^\d*\.?\d{0,8}$
- Allow leading decimals (e.g., .5)
- Allow empty input (rely on validation at submit)
Silent, clean UX with no hint text:
- Typing limit: Implicit feedback (cursor stops)
- Paste truncation: No visual feedback needed
Only applies to BTC unit - sats/₿ units unchanged.
Remove the truncation hint text that was displaying for BTC unit. The hint is no longer needed because FilteringTextInputFormatter now blocks typing beyond 8 decimals and paste events are silently truncated. Cleaner UX without unnecessary visual elements.
Replace FilteringTextInputFormatter.allow() with custom _DecimalLimitFormatter to fix input deletion bug. Previous behavior: - Typing 9th decimal would delete entire input New behavior: - Typing beyond 8 decimals: silently ignored/truncated - Pasting >8 decimals: truncated to 8 decimals - Cursor positioned at end after truncation Custom formatter provides precise control over truncation instead of regex rejection, preventing input loss.
|
Had a nice long chat with sosthene about this today, where he highlighted various flaws and related aspects of the way AI is coding things. This was super-useful and the actual intention behind this draft PR. It would be nice to have more meta-feedback, so I can add it to its agent.md file equivalent. |
|
screenshots
|
|
I'm thinking this feature is probably too big for a first-time PR. It involves a bunch of screens, the rust component of the app, and also persistent storage. I think we should start a bit smaller to get a merge-able PR. How about a PR for having a 'max' button on the send screen? This should be limited to a single screen. The Figma designs have a slider that says 'send all funds'. If a user ticks that slider, the amount input field should probably be disabled/greyed out. When the user presses 'proceed', it will simply continue by filling in the maximum balance (the amount that is currently also being used to display the available balance). Maybe that's a good thing to try as a first PR? |
|
@cygnet3 we discussed that at length yesterday, that PR could indeed be a lot smaller (first commit has nothing to do with the topic, at least 2 other commits are pretty much useless/could be squashed away). Beside I think that a feature like that shouldn't even need to touch the rust part. We also discussed the opportunity of Yashraj focusing on some kind of prototyping directly in app, basically, vibe coding new screens and UX without even bothering about the actual implementation, asking AI to mock the data when needed. The point would be to be able to iterate fast on UX issues, and when we all agree on what we want the experience to be for the end user we pick the PR from there and actually implement what goes behind the screen. Of course that's just an experimentation but it seems that actually vibe coding whole features is still out of reach so that may be the best way to optimize everyone's time. Anyway maybe implementing the max feature in send workflow is indeed a lower hanging fruit for trying that. |
3 participants
As my first PR to this project, this is in draft stage to for detailed review. This PR