-
Notifications
You must be signed in to change notification settings - Fork 37
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
Shorten usage of Fields in include, where, and orderBy API functions #150
Comments
Hi @vestrel00, Would this thread be appropriate to continue the above mentioned conversation? |
Hey! Welcome 🔥 Anywhere is fine. This is okay. If you'd like, you can start a new discussion https://github.com/vestrel00/contacts-android/discussions/new it's all up to you. I have no preference 😁
|
Started a new discussion (#162) to continue on this. |
Based on that discussion, I'm reopening this issue and assigning it to you @jayasuryat! Please delete my 500 lines of code here and replaced it with your 2 lines of code!!! GENIUS! |
Included in release; https://github.com/vestrel00/contacts-android/releases/tag/0.1.10 |
* #150 Added some initial documentation about the Contact lookup key * #140 Added lookup key when logging Contacts table using the debug module extensions * Started a section for Contact ID vs LOOKUP_KEY in the DEV_NOTES * #140 Added more dev notes on lookup keys after researching the behavior after linking contacts * #140 Completed documentation * #140 Added lookupKey property to Contact entity * #140 Added ContactLookupKey extensions, finalized documentation, and updated sample app to use lookup key instead of ID
Problem
The suggested usage of
Fields
in the library results in too long statements due to redundancy of usingFields.
. For example,While this is the only way
Fields
can be used by Java users, we can shorten it for Kotlin users. Actually, Kotlin users can already remove the redundant calls toFields.
this by usingrun
on it,However, it is not obvious and requires consumers to still use
Fields.
once.Consumers could also import all properties of
Fields
. However, it could cause a lot of name clashes between the name of the field (e.g. Email) and the name of the entity (e.g. Email).Solution
Remove the need for consumers to use
Fields.run
(and other equivalent field sets), ininclude
,where
, andorderBy
API functions.Usage for Kotlin users would look like,
This also gets rid of the need for consumers to know that they should be using
Fields
to begin with, even though it is mentioned in the documentation.We can take this a step further by providing extensions for a field sets,
And even further by providing extensions for individual fields,
Checklist
The text was updated successfully, but these errors were encountered: