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

Sabrina/customer info model #27

Merged
merged 4 commits into from Mar 23, 2020
Merged

Sabrina/customer info model #27

merged 4 commits into from Mar 23, 2020

Conversation

@sabrina-li
Copy link
Contributor

sabrina-li commented Mar 19, 2020

customerinfo.java: data model for all user inputs from the checkout view
added Constants class to better manage constants as well as available fields that's shown in checkout

}
}
return false;
}

This comment has been minimized.

Copy link
@patrick-fs

patrick-fs Mar 20, 2020

Member

why use hash maps like this rather than use getters and setters?

This comment has been minimized.

Copy link
@sabrina-li

sabrina-li Mar 20, 2020

Author Contributor

great question and exactly why I've been working on this for this long.
The problem with having specific setters is that all of those methods need to propagate through model->repository->view model and finally used by the view via binding. It gets harder when using encapsulate the whole form into one LiveData, you'd have to make it "property aware". It would potentially make the code more readable but also likely make it a harder to maintain when fields need to be added/modified. I wanted to use the constants as a "catalog" of the fields and have them organized.
Having said that I realize form validation might be a challenge this way.
I have leaned against binding onTextChanged handler to persist data as user input their info. Feels like unnecessary calls to update data on each key stroke. But maybe that is the solution after all... WDYT

https://developer.android.com/topic/libraries/data-binding/two-way
https://medium.com/androiddevelopers/viewmodels-persistence-onsaveinstancestate-restoring-ui-state-and-loaders-fc7cc4a6c090

This comment has been minimized.

Copy link
@patrick-fs

patrick-fs Mar 20, 2020

Member

I think erring on the side of readability is the right choice. I'm not sure what the consequences are of persisting data as it is entered. I skimmed through those articles and it seems like two-way binding on ViewModels is once approach that Android recommends, though having to verify that values have actually changed at the risk of incurring an infinite loop is a little freaky. I always prefer unidirectional binding for these types of reasons.

I'll go ahead and approve.

Copy link
Member

patrick-fs left a comment

LGTM

@sabrina-li sabrina-li merged commit 1c632ec into master Mar 23, 2020
@sabrina-li sabrina-li deleted the sabrina/customerInfoModel branch Mar 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.