supercaly/handmonitor

An Android Wear application to monitor the user's hand-washing and hand-rubbing activity ⌚️🙌

Hi there 👋

• 🔭 I’m currently working on some random projects
• 🌱 I’m currently getting a PhD in computer sience
• 🧑‍💻 I’m looking to collaborate on open source projects
• ⚡ Fun fact: The First Gigabyte Drive Cost $40,000.

Top Langs

Github Stats

handmonitor's Issues

Wear: Add methods to query the last event and all the events after a particular date.

Lint: Mark all warnings as errors

Set schema export directory for room

At the moment android studio gives this warning:

Values of variant API AnnotationProcessorOptions.arguments are queried and may return non final values, this is unsupported
/Users/lorenzo/AndroidStudioProjects/HandMonitor/wear/build/tmp/kapt3/stubs/release/com/handmonitor/wear/database/AppDatabase.java:22: warning: Schema export directory is not provided to the annotation processor so we cannot export the schema. You can either provide `room.schemaLocation` annotation processor argument OR set exportSchema to false.
public abstract class AppDatabase extends androidx.room.RoomDatabase {

Investigate if we need to export the schema or set exportSchema to false

Wear: Using runBlocking will stop current thread waiting for the repository

to call addNewEvent on a coroutine. This could be a valid solution since we are

not on the main thread, but remember that the current thread will not ask for new

data until this call is finished (that can take more than 2 seconds).

Wear: Figure out all HandEvent parameters needed

Rename `sensorslib` to `sensorlib`

Rename the module sensorslib to sensorlib for better readability and clarity.

Dataset Recording wear app

This issue is a proposal for a wear os application aimed at collecting the data from the device's accelerometer and gyroscope sensors with the purpose to create a custom dataset similar to the one we already have, but better.

The application will be used by some trusted users and should have a simple UI:

1. the user selects from a modal button the action is about to record
2. the app starts the recording process until the user stops it
   • wait for 60s to remove the vibrations induced by the button press
   • remove the last few samples to remove the vibrations induced by the button press
3. the app asks the user for confirmation before saving the data
4. the collected data is stored in a database or a file
5. the app schedules a collection of other events later (30/40m after the end of this measure)

UI

idle state

The app is not recording any data and is ready for the user to start collecting some.
Display one button for each action. Each button has the time remaining for completion of that action (ex: 5/10min)

recording state

The app is recording some action data. Display a timer to let the user know how much time is passed and a button to stop the recording.

Show a dialog asking the user for confirmation before saving the data to a file.

App flow

1. The app is in idle mode so no data is recorded; a task is scheduled to run every 30/40 minutes in the background to automatically collect events marked as other
2. The user starts recording some action data
   • if we are currently recording data in the background we need to stop and discard those samples
   • switch the app to recording mode
   • remove the schedule for background data recording
3. The user stops recording some data
   • ask for confirmation to save the data
   • switch back to idle mode
   • schedule the background data recording for the next 30/40 minutes

Actions

The hand-related actions that the app records are:

• hand-wash
• hand-rub
• eat
• brush teeth
• face-washing
• write
• type on the keyboard
• housework

Repetition

To obtain a balanced dataset each activity must be recorded for the same duration, 10 minutes a day is a good balance.
The app shows the remaining time for each activity for that day inside the action button; when the time is exceeded the user can still record that activity, but it UI will highlight the text so he knows it's done. At the end of the day, all the times are reset to 0. Some activities will be completed in one session, and others my not be completed, but it's accepted and it's the responsibility of the user to complete all the recordings for that day.

Save to a file

The recorded data can be stored inside a plain text file in .csv format; each line will have the form of:

timestamp, label, acc_x, acc_y, acc_z, gyr_x, gyr_y, gyr_z

Create `testUtils` module

Create a module called testUtils where the code shared by all the modules' test lives.
This may be a good solution.

Sensorlib: `onSensorChanged` should do less work

The documentation states:

If your application requires you to do any data filtering or reduction of sensor data, you should perform that work outside of the onSensorChanged(SensorEvent) method.

At the moment inside SensorWindowProducer's onSensorChanged we call SensorSampleFilter, SensorWindowBuffer, and onNewWindow; this can be considered enough work.

A solution should be to pass each sensor event to a channel to a coroutine without filtering it or adding it to the buffer; the other coroutine then will perform those actions and at the end call onNewWindow. The channel could have capacity of Channel.UNLIMITED and use the method offer to post data to it.

This is a good solution especially in the case we use SensorWindowProducer without the asFlow extension; in this case all the hard work done in onNewWindow callback will be ultimately performed inside the HandlerThread responsible of collecting sensor events.

Sensorlib: Mark non-API classes as `internal`

At thew moment some classes like SensorWindowBuffer and SensorSampleFilter are accessible from outside the package, but needs to be marked as internal since are intended to be used only inside the package and not in the API.

Wear: UI features redesign of wear app

This issue is part of a large redesign of all the UI features of the wear's app.

App

The main access point of the application, allows the user to perform complex functions; it allows richer interactions and adjusts the features. The main features are:

• show daily wash/rub count
• show daily mean wash/rub times
• show the mean time for washing/rubbing
• show daily goals
• show last 5 events wash or rub
• settings
  • set daily goals
• "open in app" button

Tile

Tiles provide easy access to the information and actions users need in order to get things done.

• Tile 1. show daily wash/rub count
• Tile 2. show daily wash/rub goal and a progress bar

Complication

A feature displayed inside the watch face alongside the time.

• Comp 1. show daily wash/rub count
• Comp 2. show daily goals