refactor: simplify home view

[rubensmachion]

Description

This PR simplify HomeView by separating the Activity Header on side component

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I have formatted my code with swift-format per .swift-format file

New Features:

• I've added tests for the new feature
• I've added docs for the new feature
• UI changes tested on small, medium, and large devices to ensure layout consistency

Bugfixes:

• This pull request breaks the existing API
• I've added tests to reproduce the issue which are now passing
• I'm linking the issue being fixed by this PR

[reez]

Concept ACK

I mean this is totally good as-is, the only thing im noodling on is the datasource part in ActivityHomeHeaderView. Typically in the codebase I inject either a view model or just the properties, here you created a datasource struct to pass/inject. I dont actually think there's anything wrong with that at all, but I'm just trying to think of how to best keep it consistent with what the codebase does right now.

I think you're datasource struct makes sense, it encapsulates those 5 properties, but also at the call-site it still requires being explicit about those 5 properties. I'm not sure how well adding a corresponding view model for ActivityHomeHeaderView would work in the case that we need the functions like fullScanWithProgress to still be in the WalletViewModel (the ideal state is if they were just able to be in a ActivityHomeHeaderViewModel but I dont know that that's possible or not, I haven't fully walked down that road).

Let me keep thinking on this, and if you have an additional comments/thoughts/ideas let me know.

But if I haven't thought of any better way to do things in the next day or two I'll merge this because its definitely a nice refactor!

[rubensmachion]

Hi @reez, this evening I will study a better way to handle those five attributes to try to decouple these components.

[reez]

Hi @reez, this evening I will study a better way to handle those five attributes to try to decouple these components.

Sounds good. Dont spend too much time on it, this PR is mergeable as is, but if something better happens to come to us in the next day or so we can chat about it here and see what we think.

[rubensmachion]

In this last commit, I moved the role logic to WalletViewModel, and in ActivityHomeHeaderView, I created an enum to represent the view state.

[reez]

After looking at the State enum approach, I think we can achieve a cleaner separation by sticking closer to direct property injection, which keeps the view simpler and avoids mixing presentation logic into the WalletViewModel.

Here's why the direct property approach (with a small tweak to WalletViewModel) feels better to me:

• Simpler View: ActivityHomeHeaderView just takes the raw data it needs (progress, state, etc.). The State enum made the view more complex internally, needing extra logic to unpack the state.
• Cleaner ViewModel: WalletViewModel provides simple data. Adding a needsFullScan computed property hides the internal bdkClient detail from the caller (WalletView). The State enum approach mixed view-specific presentation logic into the WalletViewModel.
• Less Coupled: The view stays dumb and reusable, only needing basic data types. The State enum created unnecessary coupling between the view's internal structure and the ViewModel.

I'll add code suggestions right now too

[reez]

can add this to WalletViewModel too to make the call-site for ActivityHomeHeaderView cleaner w my proposed changes:

    // Add computed property for needsFullScan
    var needsFullScan: Bool {
        bdkClient.needsFullScan()
    }
    ```

[rubensmachion]

Good calls, @reez.

I just applied all your suggestions. To keep the var body: some View shorter, I created a new function to encapsulate the indicator image construction.

see in ActivityHomeHeaderView.syncImageIndicator()

[reez]

perfect! thanks for working on+thru this!