Closed AndrewR8 closed 6 years ago
What bugs are you addressing here? The formatting of your code isn’t ready for a PR and the string change actually makes less sense.
Please explain the purpose of these proposed changes.
You updated the description, thank you. The string needs to be reworded nonetheless, I believe some of this is being lost in translation.
There are other standards that need to be addressed before this, but this is good for the proposed UI overhaul and following proper design standards. (Your link is to a private page of a paid course site, please reference those directly using Google developer resources:
https://developer.android.com/guide/practices/ui_guidelines/index.html
Thanks for your help.
The string is unused, changing it has nil imapact. UI feedback is adequate so far in users onboarding the decibel levels: “Make some noise” is an engaging phrase to let the user know it’s time to interact. Feedback latency is negligible compared to the motion preview and the dB levels are well explained.
A full on UI overhaul is proposed in the issues, have a look at the clean work done in #218.
You could help out #275 where the values are much more ambiguous than the audio sensor you’re working on here. Keep after it 👍
is everything okey with my commits? or i need to change something else?
Sorry for the delay on reviewing this... taking a look now!
Regarding the string name, the naming was done through automated externalization using Android Studio. I agree it shouldn't be the key for the strong shouldn't be the english sentence with an underscore.
That said, at this point changing keys for strings causes more problems than it solves, since we need to change them for all translations, etc, and push the updates strings and translations to Transifex.
new project templates in Android Studio now use ConstraintLayout as default
the string name and the string itself are the same, and this is at least not beautiful, and it is not convenient for reading