Add 'dw_' prefix for UIImage+Utils methods, remove 'imageWithTintColo… - #11
Merged
Merged
Conversation
…r:' (it is available in DashSync)
QuantumExplorer
approved these changes
Nov 25, 2018
llbartekll
added a commit
that referenced
this pull request
Apr 8, 2026
Milestone 2 of the SPV chain sync migration (DASHSYNC_MIGRATION.md row #11). Introduces the consumer-owned SPV lifecycle coordinator that dashwallet-ios will use to drive SwiftDashSDK's SPVClient, replacing DashSync's DSChainManager / DSPeerManager / DSSyncState in subsequent milestones. The coordinator: - Is a @objc-bridged singleton (`DWSwiftDashSDKSPVCoordinator`) that exposes `startIfReady` / `stop` class methods to Obj-C call sites and `@Published` state to Swift/SwiftUI consumers via Combine. - Owns the SPVClient lifecycle on a dedicated background queue. Never blocks main. All published-state mutations are marshalled to main before delivery. - Polls `swiftSDKKeyMigration.v1.done` (the seed migrator's done flag) with a bounded backoff before constructing SPVClient — avoids racing the migrator on first launch after upgrade. - Reads the migrated HDWallet record from SwiftData via ModelContainerHelper.createContainer(), imports the serialized wallet bytes into the SPV client's wallet manager via `WalletManager.importWallet(from:)`, and kicks off `SPVClient.startSync()` in a Task. - Cold-syncs from birth height (730_000 on mainnet, 0 otherwise) into a fresh per-network data directory `Documents/SwiftDashSDK/SPV/<network>/`, separate from any other SDK consumer. - Owns its own 5 event handler classes (progress, sync, network, wallet, error) and wires them directly into the coordinator's `@Published` state. Deliberately bypasses WalletService.swift (the SDK's internal SPV consumer with 12 empty stub bodies) — the gap inventory is documented in the planned SWIFT_SDK_SPV_GAPS.md (milestone 12). Published surface: - progress (0.0-1.0), state (SPVSyncState), tipHeight, bestPeerHeight, connectedPeerCount, lastError, isComplete, and the full SPVSyncProgress snapshot with per-phase detail (headers, filterHeaders, filters, blocks, masternodes, chainLocks, instantSend). Hard invariants match the seed migrator's discipline: no force-unwraps, no `try!`, no `as!`, no throwing from public methods, no main-thread blocking, no touching of DashSync. Registered in project.pbxproj for both dashwallet and dashpay targets in the Infrastructure/SwiftDashSDK PBXGroup (A5D5DD0000000000000000F4), UUID family FB/FC/FD. Built clean on both targets; plutil -lint OK. Depends on the platform-repo visibility patches in 400b4b2c9 + f663e9809 that made SPVClient and the 5 event handler protocols public. **Dead code at this point** — nothing calls `startIfReady` yet. That's milestone 4 (AppDelegate.m wiring). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
llbartekll
added a commit
that referenced
this pull request
Apr 9, 2026
Brings DASHSYNC_MIGRATION.md in line with what's actually shipped: - Add "Where we are" entries for #5 wallet balance (commits 2b447fc, f1b481b, 7c00be4) and #11 SPV chain sync via M5 + M6 (3cf5962 + 86ed727). - Update #14 wipe entry to mention the post-#5 SPV stop + clearBalance calls. - Flip Status column for rows #5 and #11 from `—` to `🌗 Flipped`. - Update file paths and storage notes in rows #5/#6/#7/#11 to reflect the actual code locations and migration story. - Drop the Core Data → SwiftData migrator from Hard Blockers. After the #5 work landed, the migrator turned out unnecessary: chain-derived data (UTXOs, tx history, masternode list, sync state) is re-derivable via SPV resync from SwiftDashSDK's own on-disk chain data. User-entered metadata (tx categories, tax categories, gift card receipts, address labels) was never in DashSync's Core Data — it lives in dashwallet's own SQLite via TransactionMetadataDAOImpl and AddressUserInfo, keyed by txHash / address, so it stays attached after resync automatically. - Rewrite the "Storage migration" section with the corrected picture (no migrator required). - Rework the "Recommended order" wave structure: the chain + balance push (Wave 2 now) ran ahead of DashPay/Platform work because the storage groundwork was unblocked. Tx history (Wave 4 now) is the next big wave and follows the same shape as #5. No code changes — doc only. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
llbartekll
added a commit
that referenced
this pull request
Jul 2, 2026
…audit A 4-agent DashSync-SPV removal audit found the migration doc understated the residual coupling. Corrections (doc-only): - #11 "Where we are": the "setupDashSyncOnce remains because ... a handful of read APIs" line was wrong on two counts. setupDashSyncOnce is not the sync starter (jailbreak detection + DSEventManager + optional price fetch); the load-bearing launch dependency is DWEnvironment building the DSChainManager graph. And the residual coupling is broad: coin-control send broadcast, ~127 files reading live currentChain/currentAccount, 8 satellite DSWallet.allTransactions readers (silent data loss without a synced chain), and masternode/quorum display reads. - Record two hazards: SyncingActivityMonitor re-emits DSChainManagerSync* names from SwiftDashSDK-sourced state (false positives when auditing DashSync usage); ChainLock/InstantSend moved from local BLS quorum-signature verification to trusting the SDK's opaque context byte (security-posture change worth a conscious sign-off). - Row #11 + the coexistence note: flag that the pod stays linked well beyond Wave 5, gated on the removal blockers above (+ invitation/contacts on the dashpay target). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
llbartekll
added a commit
that referenced
this pull request
Jul 6, 2026
New "Where we are" entry for the five reader groups moved off DSWallet.allTransactions (tax CSV, ZenLedger, gift-card details, CrowdNode withdrawal limits + online-account scans, request-amount receive); #6-satellites deferred list and the #11 audit-correction reader inventory updated — the deprecated DSTransaction filter adapter is gone and the only remaining allTransactions consumers are the DashPay profile data source (#18) and the onboarding stub. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
llbartekll
added a commit
that referenced
this pull request
Jul 6, 2026
SyncingActivityMonitor.postLegacyNotifications re-posted the three DSChainManagerSync* names from SwiftDashSDK-sourced state, so observers and grep audits saw "DashSync sync running" when it wasn't (the architecture-guardrail-#5 violation recorded in the row #11 audit). The re-emitter, its dedup state, and the three legacy name constants are deleted; the three consumers move to the typed surface: - HomeViewModel reloads txs/shortcuts from its existing syncModel.$state sink on the transition into .syncing (removeDuplicates keeps it one reload per transition; a model created mid-sync does one extra reload). - DWPhoneWCSessionManager adopts SyncingActivityMonitorObserver and sends the watch application context on .syncDone/.syncFailed. The monitor's strong observers array is safe here — the class is a process-lifetime singleton. - DWAboutViewController observes the new ObjC-visible SyncingActivityMonitor.syncStateChangedNotificationName (NC observation rather than protocol adoption — the strong observers array would retain a pushed VC forever). Its old name, DSChainManagerSyncStateDidChange, was never re-emitted by the monitor at all. grep DSChainManagerSync is a clean audit signal again: any remaining hit is a genuine residual DashSync poster (e.g. the Settings-rescan hole, removed separately). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
llbartekll
added a commit
that referenced
this pull request
Jul 6, 2026
…e the ledger DWUserProfileDataSourceObject's MOCK_DASHPAY block scanned DSWallet.allTransactions for a faucet-address match — the list is empty post-M6, so the loop never found anything and the existing nil-transaction date fallback already rendered. Behavior-identical deletion; the app now enumerates DashSync's tx store nowhere (the onboarding StubTransactionSource fake is the only remaining allTransactions surface). The file's DWEnvironment import went with it. Ledger: rows #6/#11/satellite and the Notes blocker list still claimed the satellite readers (tax CSV, ZenLedger, gift card, CrowdNode limits, request-amount receive) were on DashSync — all five ported to SDK rows earlier today (4723a7b → 421cff3). Also records the sync-notification re-emit removal (dae5239) under row #11's migration hazard (a). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
llbartekll
added a commit
that referenced
this pull request
Jul 6, 2026
Research companion to DASHSYNC_MIGRATION.md scoped to unlinking the DashSync pod (ledger item #11's long tail): 11 coupling clusters with per-cluster shapes/efforts, 10 additional surfaces from a coverage sweep, 7 live bugs, verified-vs-refuted upstream gaps, owner decisions, and the Wave A/B/C sequence. Wave A statuses folded in (7 commits landed 2026-07-06; A7 deferred by owner decision). 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
2 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.
…r:' (it is available in DashSync)
depends on dashpay/dashsync-iOS#51
The issue with QR code was because we had a method with the same name in DashSync UIImage+DSUtils category:
imageWithQRCodeData:color:color:it overrides DashWallet's implementation which sets the value for theinputCorrectionLeveltoMbut DashSync sets it toL:https://github.com/dashevo/dashsync-iOS/pull/51/files#diff-add55ae4071b53a47193eaf0f922dba0L45