Being able to see the exact JSON going back and forth
gives precise insight into the root causes of many problems.

Adds the extra fields to the DTO that will be needed to
implement full support on the watch for the behavioral settings
defined on the phone.

The WearOS app now follows the phone's multitasking setting.

When multi-tasking is disabled, starting a new activity will stop
all other running activities.

When multi-tasking is enabled, starting/stopping an activity
affects only that activity's state.

closes thehale/SimpleTimeTracker-WearOS#18

The DomainAPI was removing stopped activity records without
saving them to the database.

Now, the DomainAPI persists completed records as expected :D

What's more, it also follows the settings for minimum durations
for activity records.

Components are more reusable when they have minimal state
and/or dependency on outside resources.

This commit raises the rpc calls to `ActivitiesScreen` which has
the responsibility for managing the data flow and interactions
between components.

This update also fixes a few bugs:
- Tapping an activity chip will start the activity if it doesn't have
any tags.
- The switches now update automatically after an activity is started or
stopped.

closes thehale/SimpleTimeTracker-WearOS#12
closes thehale/SimpleTimeTracker-WearOS#13

Sets the toggle overlay to a dark color if the activity is stopped,
and uses a light overlay when the activity is running.

Simplifies the usage of all other `remember` functions.

Additionally, it's now easier to obtain an `rpc` instance for direct
RPC requests.

Eventually, there might even be the option of supplying the
same RPC instance to all callers, enabling request
batching/pooling, etc.

Finally, a full cycle, MVP of the wear app!

This commit adds the ability to start activities
on the phone from the wear app. Choose an
activity and the associated tag, and the phone app
will update accordingly.

Of course, the app still has plenty of bugs and
rough edges, but this is a huge milestone!

closes thehale/SimpleTimeTracker-WearOS#5
closes thehale/SimpleTimeTracker-WearOS#8

According to MDN, `PUT` is the verb with the semantics for
replacing the set of resources at a specific path -- what we are
doing for `setCurrentActivities`. This rename reduces semantic
confusion even though it has no impacts on runtime behavior.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PUT

I was waiting for kantahrek's PR to go up to avoid creating
undue merge conflicts.

Now that we're both at the same version, the refactor can be
completed safely.

"affect" is too generic of a word that fails to
precisely describe the type of change it causes in
the system. "set" is more precise and better
matches the naming of the underlying WearRPCClient
method it eventually calls.

Also removed the unnecessary currying of the
callback.
Now it's (Array<Current>Activity>) -> Unit
instead of
(Array<Current>Activity>) -> (Array<Current>Activity>) -> Unit

Remove a blank line and use `isNotEmpty` instead of manually
checking size.

Apparently, in Kotlin, when the last parameter to a function is a
callback, you can instead specify the callback in a block following
the function call. 🤯

The result looks much cleaner.

Co-authored-by: kantahrek <152828461+kantahrek@users.noreply.github.com>

This is the last big commit for creating the initial, guiding
project structure.

Replaces the monolithic `MainActivity` with a variety of
narrowly focused Composables which assemble nicely into
a full application.

In particular, this commit shows off the ability to press an activity
which opens a new screen with chips for that activity's tags.

A major milestone towards #5

The test was failing erroneously due to an incorrectly written
Range in the expected output.

By making the expected output follow the same format as the
other tests, the failing test began passing once again.

The `name` parameter no longer exists on the DTO, so it was
breaking the tests.

Now all connected devices are listed, to help narrow down
why messages may not get through to the phone.

Includes showing the tags on the running activity chip.

There is certainly lots of design work to be done for showing
the tags on the watch, but for now functionality trumps beauty.

Still just a proof of concept, but tapping an Activity Chip will now
create a Toast listing the tags available for the activity.

makes progress on thehale/SimpleTimeTracker-WearOS#4

The chip for each activity will now render differently if the
activity is currently running.

closes thehale/SimpleTimeTracker-WearOS#6

This commit completes full, end-to-end implementations for
nearly all RPC methods.

The WearRPCClient and WearRPCServer are effectively complete
(all that's left is some error handling that might become needed).

As a result, all that's left is the DomainAPI

These hard-coded values were useful for the original
proof-of-concept, but now that we have a dynamic activity list,
they are no longer necessary.

Adds a dynamic list of activities to the Wear
app's main screen which pulls directly from the
phone.

Also includes a refresh button to trigger a manual
resync without needing to reboot the Wear app.

The UI leaves a few things to be lacking,
particularly support for built-in icons instead of
just emojis and text. Additionally, pressing an
activity doesn't yet do anything.

advances thehale/SimpleTimeTracker-WearOS#3

Needed for nicer rendering in the WearOS UI.

Added several comments explaining my vision for how the remaining communication layer methods should be implemented.

Intended to enable the other developers eager to contribute to work independently on advancing the state of this project.

Use `query` consistently instead of occasionally switching to `get`.

I will be initially licensing my contributions under the MPL-2.0 since I
consider it a fairer license than the GPL.
- See https://jhale.dev/posts/why-i-use-the-mpl/

Since the MPL is compatible with the GPL, this dual-licensing does not
create any licensing conflicts.

Any concerns about dual licensing can be sent to me privately. I am
happy to answer any questions and address any concerns.

Creates an MVP driver for querying live data from the Mobile phone.

The previous UI has been hidden, though not deleted since much of the code will likely be reused in the new implementation.

Implemented as a WearableListenerService so that messages can be
received and responded to whether or not the app is actively running.

Defines the `SimpleTimeTrackerAPI`, an interface outlining the methods
required for building a useful WearOS application.

Also provides a WearRPCClient and WearRPCServer as a useful wrapper
around the communication plumbing for WearOS <-> Mobile.

Incorporates the WearOS companion app developed by Joseph Hale into the
origin repository for SimpleTimeTracker by razeeman.

There is not yet any communication between this WearOS app and the main
app, but both compile and install correctly from the same Gradle
configuration!

Keeping both applications in the same repository will dramatically
simplify the communication between the Wear app and the main phone app.

A newly scaffolded WearOS module requires these minimums,
so upgrading the main app should help with compatibility.