Comments (2)
This is indeed only the case in Android. It's kind of expected behavior which I am currently looking into if it can be worked around. Allow me to explain:
On iOS one can simply indicate the projection with unique keys, and the iOS system will only retrieve and return those fields specified in the projection.
In Android this works pretty similar. However, as it turns out, these projection keys are not necessarily unique. For example DISPLAY_NAME
resolves to the string data1
. But so do COMPANY
and NUMBER
for example.
That means that if you query the name
of a contact, Android will also retrieve and return the organization
and phones
fields for that contact.
This can be worked around of course. There are a few ways:
Provide a selection matching the projection. This means that we will indicate to Android inside the query that we only want to retrieve specific types of MIMETYPES. I actually already tried this before and it's now commented out in the code: https://github.com/capacitor-community/contacts/blob/main/android/src/main/java/getcapacitor/community/contacts/Contacts.java#L144
The disadvantage of this, is that it will only retrieve contacts that match your projection. For example if your projection only specifies organization
, Android will only return contacts that actually have an organization attached. I think this may be unexpected to a developer. Moreover, it's different from the iOS behavior, which will always return all contacts. Even if those contacts won't have any other field than the contactId
, because they do not have an organization attached for example.
We could do two separate queries. One where we follow the solution mentioned above. And then also one where we query all the remaining contacts, but then only request the contactId
of those.
This solution seems pretty neat to me. However, I'm not sure if it's actually faster than just doing it the way we're doing it now. If it's not faster, it kinda defeats the purpose of projection
. So it wouldn't make sense to implement it anyways. But that's something I need the investigate still.
That being said however, I don't think for most use-cases this imperfection in the plugin will actually effect the performance significantly. But please let me know if you have experienced otherwise.
from contacts.
I have a PR for this: #97
Ran a bunch of benchmarks, but couldn't really find a significant performance difference between the current implementation and the two alternatives. So I'll probably just end up implementing it like this because of consistency with the docs and the iOS counterpart.
If you would like to share your opinion about this; please do!
from contacts.
Related Issues (20)
- iOS image payload assumes that Base64 is always a png. HOT 3
- feat: add ability to pick multiple contacts HOT 2
- Upgrade to v5 HOT 7
- Add namespace in build.gradle to fix android compilation issue on Capacitor 5.x.x HOT 1
- iOS Contact Image not cropped HOT 5
- Type definitions for pickContact is wrong HOT 1
- CANCELLED HOT 3
- feat: Add flag for isFavorite
- How to open a contact with default contact app after creating a contact
- Add thumbnailImage projection HOT 3
- ANR android crash HOT 2
- feat: Capacitor 6 Support HOT 17
- Feat: Do not require android.permission.WRITE_CONTACTS HOT 2
- Feat: Add nickname to name result type
- Contact fields duplicating in strange ways on Android HOT 1
- checkPermissions doesn't give back a response on iOS HOT 2
- projection with image crashes the App on iOS HOT 1
- SaveContact HOT 1
- getObject calls without a default value will return null in Capacitor 5 instead of an empty object to match iOS behavior
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from contacts.