Add nickname to name projection on iOS. #121
Conversation
|
Thanks for the PR! I'm trying to keep the API and behavior of this plugin consistent across Android and iOS. I'm willing to merge this PR, but I would highly prefer it also having an Android implementation. But currently I don't have time available to do this myself |
src/definitions.ts
Outdated
| @@ -134,6 +134,7 @@ export interface NamePayload { | |||
| family: string | null; | |||
| prefix: string | null; | |||
| suffix: string | null; | |||
| nickname: string | null; | |||
There was a problem hiding this comment.
For consistency it might make sense to use nick instead. As we're also not using displayName instead of display for example
| nickname: string | null; | |
| nick: string | null; |
|
Thank you for the quick reply. I can handle the Android code fine, I think, but am not setup to test it. Shall I do it anyway? |
gregzo
force-pushed
the
add-apple-nickname
branch
from
3bd99e7
to
9122337
Compare
gregzo
force-pushed
the
add-apple-nickname
branch
from
9122337
to
ccc8fcd
Compare
By this, you mean that you don't have Android Studio for coding and an emulator and/or an Android device to test the code on? Or that it's not completely clear how to test this project on an Android device? I could assist you with the latter |
|
I don't have Android Studio, emulator, or device. We're developing for iOS first, Android to follow depending on market fit. Small team, sadly no time for exploratory work an Android right now... |
|
Understood! No worries there. You could try and write it off the cuff. But you may have a hard time developing like that. And you don't have the added features Android Studio provides, like linting. So you could try, but it's sub-optimal indeed. Off-topic: isn't Capacitor actually the kind of platform that could solve your problem? From my experience, I found that once when you've setup one of the platforms with Capacitor, adding another one is peanuts. Even if the developer hasn't got experience with said platform. But of course, depending on your use case and business case this might be a completely different story. But I think if you're mainly using the first party plugins, it shouldn't be much overhead |
|
Gave Android code a go just now, but because the nickname field isn't part of |
Very straightforward PR, I simply added
nicknameto thenameprojection and mapped Swift side to CNContactNicknameKey. I've no experience with Android, but it could be a tad more work, mapping toContactsContract.CommonDataKinds.Nickname.NAME.Closes #120 but only for iOS.