-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add identify-user support #3439
Conversation
2de0585
to
8d58db0
Compare
@grzesiek2010 all great finds! Can you stick it into "Request changes"? I'll have a look at fixes. |
Just questions on a couple of your points @grzesiek2010 (most of them clearly just need fixed):
Intention was just to have the keyboard "done" take care of this but that's fairly useless without the field focusing (as you point out) - I'll fix that. Do you think we still need a button if we have that? I was following the pattern used by password prompts on Android.
Great point. The spec states a "non-blank identifier" is required. I don't want to add too much validation in but I'd assume not allowing whitespace only would be ok. Do you have any extra contect on this @lognaturel? If not I can dig through the forum discussion. |
I've updated the acceptance in #3435 based on @grzesiek2010's findings |
8d58db0
to
67db47e
Compare
I would prefer to have such a button but it's my personal opinion. |
23703f1
to
e56a95c
Compare
Ok I think I've fixed everything @grzesiek2010 found. Some annoying stuff around Theming and getting the soft keyboard to show held this up a little. I'm unclear on one path into the form that I'll leave a comment on. |
collect_app/src/main/java/org/odk/collect/android/activities/FormEntryActivity.java
Outdated
Show resolved
Hide resolved
Generally mocking static methods is considered a smell as it's sign of implicit dependencies in the object under a test. Here it was particularly confusing as Powermock was being used to implicitly set the system to 0 so that tests would pass.
This makes it easier to work on audit features as tests can be run as a set and it's simple to see all the classes involved in audit logging. Also moved AuditEventSaveTastTest into Robolectric from Espresso.
- Introduced an AuditEventWriter abstraction that wraps AuditEventSaveTask - Test AuditEventLogger by inspecting the AuditEvents it writes to the AuditEventWriter - Remove dependency on Collect static method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks good to me and the functionality looks like it's all there thanks to @grzesiek2010's initial review! 🙏
I feel like I'm being a broken record but the fonts really look really small to me. I would expect this to lead to occasional inaccurate identity entry because it's just hard to see what's being typed in. BUT. I understand that they are default and match where the world is going so I think we should go with it and see what user feedback comes in.
Like @grzesiek2010, I instinctively want to swipe forward and had to think a second about tapping "Done". I would tend to have some kind of explicit "Save" button but I'm ok with waiting for user feedback on that part as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks good to me and the functionality looks like it's all there thanks to @grzesiek2010's initial review! 🙏
I feel like I'm being a broken record but the fonts really look really small to me. I would expect this to lead to occasional inaccurate identity entry because it's just hard to see what's being typed in. BUT. I understand that they are default and match where the world is going so I think we should go with it and see what user feedback comes in.
Like @grzesiek2010, I instinctively want to swipe forward and had to think a second about tapping "Done". I would tend to have some kind of explicit "Save" button but I'm ok with waiting for user feedback on that part as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks good to me and the functionality looks like it's all there thanks to @grzesiek2010's initial review! 🙏
I feel like I'm being a broken record but the fonts really look really small to me. I would expect this to lead to occasional inaccurate identity entry because it's just hard to see what's being typed in. BUT. I understand that they are default and match where the world is going so I think we should go with it and see what user feedback comes in.
Like @grzesiek2010, I instinctively want to swipe forward and had to think a second about tapping "Done". I would tend to have some kind of explicit "Save" button but I'm ok with waiting for user feedback on that part as well.
@seadowg Here is what I found
I also have questions:
|
@opendatakit-bot unlabel "needs testing" |
@mmarciniak90 thanks for these - I'll have a look at fixing these issues. I talked to a form designer today about the feature and they weren't conncerned about whitespace but given it says "non blank" in the spec I think we should block whitespace only entries. On the copy/pate menu covering the field: I'm not sure we have control over that but I'll have a look. On your questions:
I'm guessing you mean font size changes in the app rather than at the system level? I'm actually not sure where the distinction lies for what should react to the app's font size change. @lognaturel?
Good point. What is our normal process for getting translations in place? |
It only affects the form entry activity currently. It feels very weird because it doesn't include the hierarchy/jump view or the save/submit screen. Ideally I would think both would be affected because they feel like they're part of the form filling experience. I think that ideally font changes would go to this screen but I don't currently feel strongly about it given the chaotic current state. It's already weird that its fonts don't match the rest of the app (they match Material Design standards which is certainly better than matching nothing).
https://github.com/opendatakit/collect#contributing-translations outlines the process. Transifex pulls the Translations are a great thing to check, @mmarciniak90. I believe that it is now impossible to commit untranslatable strings because the build will break. But maybe what you can also do is quickly verify the |
collect_app/src/main/java/org/odk/collect/android/utilities/StringUtils.java
Show resolved
Hide resolved
We don't need its behaviour for this screen and it just causes problems with the Toolbar being hidden on lower API levels.
@mmarciniak90 1 and 2 are fixed.
EDIT: Scratch that. Had a sudden brainwave and managed to fix 3. Still not 100% sure I understand how exactly but it's looking good! |
For some reason this was setting the pop up background that appears on long press on an EditText.
@seadowg thanks for taking care of the mentioned problems. I can confirm that they are fixed. I noticed one more thing.
It would be better not to lose this data during rotation, what do you think? |
That definitely shoudn't be happening. I'll take a look. |
59d8f10
to
7b69272
Compare
@mmarciniak90 fixed! Thanks for keeping me on my toes around screen rotations (this goes for @grzesiek2010 too). It's probably very obvious I've managed to work mostly on apps that lock to portrait in the past 😉 |
Tested with success Tested on Android: 4.2, 4.4, 5.1, 6.0, 6.0, 8.1, 9.0, 10.0 Verified cases:
@opendatakit-bot unlabel "needs testing" |
Closes #3435. This implements the feature described (with designs and specs) in that issue.
A couple of notes on implementation:
AuditEventLogger
(producer) but it now defines anAuditEventWriter
interface that's implemented with anAsyncTask
. The goal here was to seperate out the logic that creates the list of events from the writing of those events to a file.audit
package. This is talked about in the State of the Union.FormEntryActivity
as it controls loading and rendering the form. The code that makes that happen isn't great but I want to follow up with a bit of a refactor of the Activity itself. I didn't feel including that would be the right move as it would be a lot of noise for a reviewer.What has been done to verify that this works as intended?
Local testing and submitting the form to Aggregate.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
There shouldn't be any changes other than the new feature. Would be good to test form entry in general to make sure we haven't messed up any existing flows.
Before submitting this PR, please make sure you have:
./gradlew checkAll
and confirmed all checks still pass OR confirm CircleCI build passes and run./gradlew connectedDebugAndroidTest
locally.