Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Presets Annotations #4

Closed
ShunitP opened this issue Nov 10, 2020 · 5 comments
Closed

Presets Annotations #4

ShunitP opened this issue Nov 10, 2020 · 5 comments
Labels
enhancement New feature or request

Comments

@ShunitP
Copy link
Collaborator

ShunitP commented Nov 10, 2020

Current behavior

  • We have the option to define 12 different presets.
  • Each preset is saved onto the controller of the hand and when the user opens the preset panel, the app reads the content from the hand controller and presents it to the user.
  • We allow the user to add a name for each preset, but these names are saved only on the phone and not on the hand controller (due to lack of memory space). Hence if the user used different phones or different hands the names of each preset will no longer match the preset content (for instance a preset named OPEN can result all finger to be closed).

Requested behavior

There is a need for a new method to add a simple and clear annotation for each preset according to its content.
ideas: a GIF that is generated according to the preset content), user account that sync the changes in the presets names, ...

@ShunitP ShunitP added the enhancement New feature or request label Nov 10, 2020
@georg-jung
Copy link
Member

georg-jung commented Nov 10, 2020

Hence if the user used different phones or different hands the names of each preset will no longer matches the preset content (for instance a preset named OPEN can result all finger to be closed).

Actually this is only half true. The phone does remember different hands and will only show the preset names for the same hand again. Matching is done by BLE hardware address. See PresetDao.kt.

So, when working with multiple hands with one phone everything works as one would assume. When working with one hand with multiple phones, what you described applies. I like your idea to visualize the presets in some way.

I guess this is something @asafazar92 and Niv will look into so I'll not do anything further in this regard for now (drop me a short note otherwise).

(If you actually tried multiple hands with your phone and it did not work as expected, then thats probably a bug. Please open a second issue then and I'll look into it.)

@ShunitP
Copy link
Collaborator Author

ShunitP commented Nov 11, 2020

You're right. The app does remember the presets names for different hands.
So indeed my issue is relevant only if someone uses multiple phones to work with the same hand

@mikimn
Copy link

mikimn commented Nov 15, 2020

I like both the idea of an interactive animation for displaying the hand gesture dynamically based on the information, and storing user information in the cloud. I've opened a new issue for cloud integration since this is an important feature as well: #10

@georg-jung
Copy link
Member

I like the cloud idea and think it would be a nice option for the users to have. Actually when I typed my above comment I thought about that too and already had the suggestion in my text too 😅. However, I decided to leave it out:

• Maybe that's my EU-way of thinking but I immediately thought of the GDPR stuff. I guess saving "medical data", what you probably could say this is, has some privacy law consequences I didn't want to think too much about.
• It introduces a dependency on one more account to manage, with access rights, API keys etc.

Some other thoughts regarding cloud sync apply to the visualization feature too:
I think that would be a - maybe not huge but rather large - addition to the codebase, while I'd consider it rather "nice to have" (do we really know users want to use more than one device in parallel when we don't really have users yet?). In my experience in software development until now, I'd say for this app, in the long term, it's crucial to be very easy to maintain to be successful. Given that, I wasn't sure if it would be a good idea to add "nice to have" features that aren't trivial.

Nevertheless I like the idea in general and I'm sure it's a great thing to implement to learn about android development. I'm just not sure if it's a good addition to our long-term code base. I'm not saying we shouldn't do it, I just wanted to bring this point up so that we can discuss. And if we decide to do it I guess it might be a good idea to have it as modular as possible with little coupling to the rest of the codebase (obviously that would be a good idea either way but I think in this case it's a bit more of a "requirement" than for other stuff).

@georg-jung
Copy link
Member

Ah I just re-read #10 and you're obviously right that there's more about this than just multi-smartphone-usage. It's worth noting that we are already prepared for the "migrate to new hand" use case with or without cloud storage: The app does already use room to store the preset names and known hands. That db contains the presets deployed to the controller too, that's already live. If we'd build a migration feature we could look into the possibilities of this too, hmm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants