Pull tag colors from the phone and render them on the TagScreen.

Comparable to how it's done on the ActivityScreen.

Currently the app hard-codes a set of tags (specifically what I used a few months ago).

We want the app to update live alongside changes to tags in Razeeman's app. See #3 for a list of strategies for accomplishing this.

Currently, the WearOS app uses the default Android icon.

We want it to install with the same icon as the phone app.

Razeeman's app has a setting which enables starting an activity immediately after the first tag is selected (even if the activity has multiple tags available).

If that setting is enabled on the phone, the watch app should behave accordingly.

Some notes:

• The user can still opt to choose "no tags" when starting the activity.
• At the time of writing, this is the only supported behavior in the watch app. This issue thus focuses on tying that behavior to the appropriate setting from Razeeman's app instead of applying it as a global default.

A shortcoming of the implementation for #3 is that the SVG icons for activities do not render on the WearOS app.

We'd like activity icons on the Watch to match the Phone app as closely as possible.

• SVG Icons
• Emojis
• Text Icons ~ shows the first few characters. Doesn't wrap like on the phone.

HH:MM is preferred over HH:MM:SS for battery saving purposes, though I'd welcome a setting to allow users to choose.

If the user is multi-tasking, the complication will list the number of active activities -- without naming them or their durations.

It would be great to add instruction how to install this app on wear os and connect it with android application

Razeeman's app has a setting which allows users to multi-task, i.e. have zero to multiple activities running simultaneously.

When that setting is enabled on the phone, the following behaviors are expected from the watch app:

• Pressing a running activity on the ActivitiesScreen stops that activity, and that activity alone.
• Pressing a stopped activity on the ActivitiesScreen starts that activity alone, leaving other running activities continuing to run.

Note that when starting an activity, the behavior must still respect the settings described in #15, #16, and #17.

After starting a new activity and choosing its tag, a user can "swipe back" on the activity list to return to the previous tag list.

This happens because the navigation pushes a new navigation stack frame when returning to the activities list. Thus, the "swipe back" clears that stack frame to return to the previous tag list.

The expected behavior of the "swipe back" gesture on the activity list is that the app closes (goes back to the previous screen offered by the operating system).

I presume the solution is to clear/reset that navigation stack when moving from the TagScreen to the ActivitiesScreen.

This is a top-level ticket tracking progress towards full implementation of the SimpleTimeTrackerAPI on both the WearOS and Mobile apps.

Background

Communication between the WearOS app and the Mobile app occurs via an RPC Client/Server implemented using Google's MessageClient and its related APIs.

The plumbing of the communication is already complete: the wear app has an RPC client that sends messages to the phones's RPC server (implemented as a Service so it can respond even when the app is in the background or the phone is sleeping).

sequenceDiagram
    actor User
    
    box green WearOS
    participant UI (Wear)
    participant WearRPCClient
    participant Messenger
    end

    box blue Phone
    participant WearService
    participant WearRPCServer
    participant DomainAPI
    end

    User->>UI (Wear): Interact with Wear app
    UI (Wear)->>WearRPCClient: Request needed data
    WearRPCClient->>WearRPCClient: Serialize message to BytesArray
    WearRPCClient->>Messenger: Request message delivery
    Messenger->>Messenger: Find nearest node
    Messenger->>WearService: Send message to phone
    WearService->>WearService: Wake up from sleep/background
    WearService->>WearRPCServer: Delegate message to RPC Server
    WearRPCServer->>WearRPCServer: Parse the message
    WearRPCServer->>DomainAPI: Request needed data
    DomainAPI->>DomainAPI: Query/update the Database
    DomainAPI->>WearRPCServer: Return data from database
    WearRPCServer->>WearService: Serialize response to BytesArray
    WearService->>Messenger: Return response
    Messenger->>Messenger: Run validation checks/error handling
    Messenger->>WearRPCClient: Forward response
    WearRPCClient->>WearRPCClient: Parse response
    WearRPCClient->>UI (Wear): Return requested data
    UI (Wear)->>User: Render UI update

Both the WearRPCClient and the DomainAPI implement the SimpleTimeTrackerAPI interface which defines all the methods believed to be necessary for the WearOS MVP.

Remaining Work

The following list of tickets track each method in WearRPCClient and DomainAPI not yet implemented. Once all the following are complete, this ticket can be closed as complete.

WearOS app

• Implement WearRPCClient.ping
• Implement WearRPCClient.queryActivities
• Implement WearRPCClient.queryCurrentActivities
• Implement WearRPCClient.setCurrentActivities
• Implement WearRPCClient.queryTagsForActivity
• Implement WearRPCClient.querySettings

Mobile app

• Implement WearRPCServer.onRequest
• Implement WearRPCServer.onPing
• Implement WearRPCServer.onQueryActivities
• Implement WearRPCServer.onQueryCurrentActivities
• Implement WearRPCServer.onSetCurrentActivities
• Implement WearRPCServer.onQueryTagsForActivity
• Implement WearRPCServer.onQuerySettings
• Implement DomainAPI.ping
• Implement DomainAPI.queryActivities
• Implement DomainAPI.queryCurrentActivities
• Implement DomainAPI.setCurrentActivities
• Implement DomainAPI.queryTagsForActivity
• Implement DomainAPI.querySettings

• Remove my custom header stuff
• Add screenshots for WearOS
• Add a licensing note regarding the MPL license for the WearOS code

In DTO.kt > Activity there is a color attribute which takes a String as a value.

Instead, we want to pass the native Long value used by Android. That way we can remove the conversion code in the DomainAPI, ActivityChip and theme/Color

Razeeman's app has a setting which enables picking zero to many tags after choosing an activity.

When that setting is enabled on the phone, the watch should behave accordingly.

Similar to #13 , but focuses on reading the corresponding setting from the phone.

Currently, the app hard-codes the list -- specifically what I used several months ago --, meaning any customization requires a complete re-build/install of the app.

Good: Allow the companion app to add/remove activities visible to the watch
- Pros: No need to modify Razeeman's app.
- Cons: Users would need to manually mirror activities/tags between the WearOS version and the official app.

Better: Add an Intent API to Razeeman's app for querying all available activities (+ colors)
- Pros: Keeps the watch's set of activities and tags automatically in sync with the official app
- Cons: Requires modifying Razeeman's app.

✅ Best: Integrate the WearOS app directly into Razeeman's app, and build a MessageClient there instead of an Intent API

• Pros: The best long-term experience for developers and users.
• Cons: Requires modifying Razeeman's app. Possibly the hardest option on the list.

Remaining steps after 9614a5c for a full MVP:

• Add support on Wear for all icons supported by mobile (tracked by #11)

Work on the actual functionality for tapping an activity chip and having it start the activity on the phone will be tracked in #5

Will make it possible for Razeeman to create separate builds with and without WearOS

Since the TagScreen only runs the logic to start an activity when a tag chip is pressed, activities with no tags cannot be started.

If an activity has no tags, then it should start automatically.

HH:MM is preferred over HH:MM:SS for battery saving purposes, though I'd welcome a setting to allow users to choose.

If the user is multi-tasking, the complication will list the number of active activities -- without naming them or their durations.

Equivalent to #7, but for the rectangle-sized complication instead of the small round complication.

Will increase users' confidence that their activity changes have been recorded as expected.

Will require adding an Intent API to Razeeman's app to query the current activities (e.g. ReadRunningRecords or ReadActiveRecords based on his preferred nomenclature in the app).

Will also require adding an Intent API to query user preferences, particularly multitasking (e.g. ReadPreferences)

UPDATE: With the new communication layer in place (see #8), all that's needed for the Wear app to access the current activities and their durations is to implement DomainAPI.queryCurrentActivities and WearRPCClient.queryCurrentActivities. From there, the UI can be designed as desired.

Currently, the watch shows a list of activities and tag pairs. That works fine for the subset of users who only ever attach a maximum of one tag to an activity, but many users (myself included) often want to attach more than one tag to an activity.

The best solution here would be to split the single list of activity/tag pairs in two to better mirror the experience in the Android app. The user would first see the list of activities. After selecting one, the user would be shown a checklist of possible tags. After choosing zero or more tags, the user could "save" his/her choice and the selected activity/tag(s) would be sent to the Android app like normal.

NOTE: Not yet in scope is supporting simultaneous activities ("multitasking" as Razeeman calls it).

Razeeman's phone app has a setting where tapping an activity will always start it immediately without prompting for the selection of tags.

If that setting is enabled, the watch app should behave the same way.

To start an activity, currently one MUST choose a tag. That's not a requirement on the phone app.

When an activity has one or more tags available as options, starting the activity with zero associated tags should still be possible.

This feature request is subtly different from the bug reported in #12. That bug applies when zero tags are available for association with the chosen activity. This feature request is for the ability to elect to choose zero out of a set of available tags when starting an activity.