Closed PeterStaev closed 8 years ago
Hey @PeterStaev the reason I left it as a resolve is because I thought a developer may want to use that response "cancelled". Never know..
As for the android are you saying when a user hits cancel/back it ignores the resolve and just flat out rejects it, sending itself to the reject part of the promise? Sorry not sure I completely understand.
Hey @firescript , yes for android if the user presses the back button the check here https://github.com/firescript/nativescript-contacts/blob/master/index.android.js#L19 is false as the result is not OK, so it enters the else part and rejects the Promise.
I see your point about a developer needing to know whether or not the action was cancelled. So may be change the android implementation on the above line to resolve with "cancelled" response instead of rejecting? This way it will be consistent with iOS.
Thx @PeterStaev fixed, consistant now :) Added you as a Contrib as well, thx much
:+1:
Looking at when the Promise from getContact is resolved/rejected for android, seems that when the user presses the back button, the promise is rejected.
So i think for iOS, here https://github.com/firescript/nativescript-contacts/blob/master/index.ios.js#L14 it is better to call reject instead of resolving with result "cancelled". Also this way the response property can be removed from the promise's result