From f36107ac80927101381c58d510cb31d12fb17db7 Mon Sep 17 00:00:00 2001
From: Travis CI
This JS code is a simple facade over the native iOS imp
a clear JS API, real Error objects, and simple non-multi functions. Each
method returns a Promise object.
Fetches key and passes the result to callback, along with an Error if
there is any. Returns a Promise object.
Sets value for key and calls callback on completion, along with an
-Error if there is any. Returns a Promise object.
Returns a Promise object.
Merges existing value with input value, assuming they are stringified json. Returns a Promise object.
Not supported by all native implementations.
Erases all AsyncStorage for all clients, libraries, etc. You probably
+Error if there is any. Returns a Promise object.
Returns a Promise object.
Merges existing value with input value, assuming they are stringified json.
+Returns a Promise object. Not supported by all native implementations.
Erases all AsyncStorage for all clients, libraries, etc. You probably
don't want to call this - use removeItem or multiRemove to clear only your
own keys instead. Returns a Promise object.
Gets all keys known to the app, for all callers, libraries, etc. Returns a Promise object.
multiGet invokes callback with an array of key-value pair arrays that
matches the input format of multiSet. Returns a Promise object.
multiGet(['k1', 'k2'], cb) -> cb([['k1', 'val1'], ['k2', 'val2']])
multiSet and multiMerge take arrays of key-value array pairs that match diff --git a/docs/known-issues.html b/docs/known-issues.html index 7e9c791bcd0..3f9228683b4 100644 --- a/docs/known-issues.html +++ b/docs/known-issues.html @@ -11,6 +11,7 @@ Dialog Intent Media Pasteboard +PushNotificationIOS Alert
There are properties that work on one platform only, either because they can inherently only be supported on that platform or because they haven't been implemented on the other platforms yet. All of these are annotated with @platform in JS docs and have a small badge next to them on the website. See e.g. Image.
There are known cases where the APIs could be made more consistent across iOS and Android:
<SwitchAndroid> and <SwitchIOS> are very similar and should be unified to a single <Switch> component.<AndroidViewPager> (to be open sourced soon) and <ScrollView pagingEnabled={true}> on iOS do a similar thing. We might want to unify them to <ViewPager>.alert() needs Android support (once the Dialogs module is open sourced)LinkingIOS and IntentAndroid (to be open sourced) closer together.ActivityIndicator could render a native spinning indicator on both platforms (currently this is done using ActivityIndicatorIOS on iOS and ProgressBarAndroid on Android).ProgressBar could render a horizontal progress bar on both platforms (currently only supported on iOS via ProgressViewIOS).There is currently no easy way of publishing custom native modules on Android. Smooth work flow for contributors is important and this will be looked at very closely after the initial Open Source release. Of course the aim will be to streamline and optimize the process between iOS and Android as much as possible.
There is a noted difference in the handling of Views with an opacity of 0 between iOS and Android. While iOS will allow these views to be clicked through and the View below will receive the touch input, for Android the touch will be blocked. This can be demonstrated in this example where it will only be possible to click the touchable on iOS.