feat: track firebase events from explore dash portal and info screens - #915
Merged
HashEngineering merged 2 commits intoMar 22, 2022
Merged
Conversation
HashEngineering
self-requested a review
March 21, 2022 02:29
Comment on lines
+105
to
+108
| const val WHERE_TO_SPEND = "portal_where_to_spend" | ||
| const val PORTAL_ATM = "portal_atm" | ||
| const val LEARN_MORE = "info_learn_more" | ||
| const val CONTINUE = "info_continue" |
Collaborator
There was a problem hiding this comment.
We should have an "explore_dash_" prefix on these event names, otherwise they will not be sorted as a group. Check previously created event names which have prefixes that note the screen, function or service that they apply to.
HashEngineering
requested changes
Mar 21, 2022
HashEngineering
left a comment
HashEngineering
left a comment
Collaborator
There was a problem hiding this comment.
Let's add a prefix to the names.
3 tasks
HashEngineering
approved these changes
Mar 22, 2022
HashEngineering
left a comment
HashEngineering
left a comment
Collaborator
There was a problem hiding this comment.
Excellent work.
HashEngineering
deleted the
feature-explore-dash-firebase-portal-merchant-info
branch
July 20, 2022 23:19
HashEngineering
added a commit
that referenced
this pull request
Aug 4, 2026
Four on-device findings from the testnet round: - The credits explainer re-appeared on every visit: its "seen" flag was written from the sheet's own lifecycle scope, so dismissing it immediately cancelled the write. It now persists from the ViewModel scope with NonCancellable, which outlives both the sheet and the screen. (Day-one bug from PR #1338 — the write only ever ran on the button path, never on swipe/back/outside-tap.) - The Send button's spinner was gated on the worker's "handed to the SDK" marker, which fires ~20ms after the tap while the purchase takes seconds, so it flashed invisibly. It now holds for the whole purchase, the button is disabled while busy (standard disabled styling), the balance observer can no longer re-enable it mid-flight, and on success it stays disabled through to the screen closing. - Whole-balance ("Max") top-ups are refused with an explanation instead of approximated: the SDK's top-up call takes an exact amount and its send-all mode is not reachable through the FFI yet (rust-dashcore #915 + the key-wallet flag, MO-998). Tapping MAX explains immediately — before the PIN prompt and without changing the amount, via a new opt-in EnterAmountFragment.onMaxVetoed hook — typing the full balance shows the same text inline, and the purchase path refuses as a backstop. - The pre-existing silent minimum now explains itself: below 0.0005 DASH the Continue button greyed out with no message. One constant drives both the button rule and the text so they cannot drift. Also keeps the null-fee guard on the confirmation screen: post-cutover the dry run does not complete the tx, so tx.fee is null and Max crashed after the PIN prompt. MO-998 / #1520 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
HashEngineering
added a commit
that referenced
this pull request
Aug 7, 2026
Four on-device findings from the testnet round: - The credits explainer re-appeared on every visit: its "seen" flag was written from the sheet's own lifecycle scope, so dismissing it immediately cancelled the write. It now persists from the ViewModel scope with NonCancellable, which outlives both the sheet and the screen. (Day-one bug from PR #1338 — the write only ever ran on the button path, never on swipe/back/outside-tap.) - The Send button's spinner was gated on the worker's "handed to the SDK" marker, which fires ~20ms after the tap while the purchase takes seconds, so it flashed invisibly. It now holds for the whole purchase, the button is disabled while busy (standard disabled styling), the balance observer can no longer re-enable it mid-flight, and on success it stays disabled through to the screen closing. - Whole-balance ("Max") top-ups are refused with an explanation instead of approximated: the SDK's top-up call takes an exact amount and its send-all mode is not reachable through the FFI yet (rust-dashcore #915 + the key-wallet flag, MO-998). Tapping MAX explains immediately — before the PIN prompt and without changing the amount, via a new opt-in EnterAmountFragment.onMaxVetoed hook — typing the full balance shows the same text inline, and the purchase path refuses as a backstop. - The pre-existing silent minimum now explains itself: below 0.0005 DASH the Continue button greyed out with no message. One constant drives both the button rule and the text so they cannot drift. Also keeps the null-fee guard on the confirmation screen: post-cutover the dry run does not complete the tx, so tx.fee is null and Max crashed after the PIN prompt. MO-998 / #1520 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
HashEngineering
added a commit
that referenced
this pull request
Aug 10, 2026
Four on-device findings from the testnet round: - The credits explainer re-appeared on every visit: its "seen" flag was written from the sheet's own lifecycle scope, so dismissing it immediately cancelled the write. It now persists from the ViewModel scope with NonCancellable, which outlives both the sheet and the screen. (Day-one bug from PR #1338 — the write only ever ran on the button path, never on swipe/back/outside-tap.) - The Send button's spinner was gated on the worker's "handed to the SDK" marker, which fires ~20ms after the tap while the purchase takes seconds, so it flashed invisibly. It now holds for the whole purchase, the button is disabled while busy (standard disabled styling), the balance observer can no longer re-enable it mid-flight, and on success it stays disabled through to the screen closing. - Whole-balance ("Max") top-ups are refused with an explanation instead of approximated: the SDK's top-up call takes an exact amount and its send-all mode is not reachable through the FFI yet (rust-dashcore #915 + the key-wallet flag, MO-998). Tapping MAX explains immediately — before the PIN prompt and without changing the amount, via a new opt-in EnterAmountFragment.onMaxVetoed hook — typing the full balance shows the same text inline, and the purchase path refuses as a backstop. - The pre-existing silent minimum now explains itself: below 0.0005 DASH the Continue button greyed out with no message. One constant drives both the button rule and the text so they cannot drift. Also keeps the null-fee guard on the confirmation screen: post-cutover the dry run does not complete the tx, so tx.fee is null and Max crashed after the PIN prompt. MO-998 / #1520 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
bfoss765
added a commit
that referenced
this pull request
Aug 11, 2026
…oled surface dash-sdk-android 0.1.0-v41int18 -> v41int19 (platform#4329 pooled funding on rust-dashcore 8f26456b: ALL_SPENDABLE account type through Rust/FFI/JNI/Kotlin, sendToAddresses/buildSignedPayment defaults flipped; carries #931 dedup, #915, #925 add_funding, #929 contact-account funding, #918 AddressState). CoreSendAllNative migrates off the v1 split surface (#4323 deprecated setFunding$sdk_release/buildSigned$sdk_release — the split is not concurrency-safe): the drain now runs new -> addOutput -> setSelectionStrategy(ALL) -> finalizeAtomic$sdk_release (atomic select+reserve+sign under the wallet-manager lock) -> ManagedCoreWallet .broadcastTransaction(FinalizedCoreTransaction). The user-facing send-all now drains the pooled ALL_SPENDABLE set (BIP44 + BIP32 + every DashPay receival account in ONE transaction); the CoinJoin drain stays pinned to the COIN_JOIN account — de-mixing remains a separate, explicit flow. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Issue being fixed or feature implemented
Track with Firebase click events from Explore Dash Portal and Dialog Info screens
Related PR's and Dependencies
Screenshots / Videos
How Has This Been Tested?
Checklist: