Some early results:
There are some use cases where we need to fall back to a native library for react-native (and very likely Corodva too). I'll analyse them one by one:
h2. Device Self Defence checks
There are several libraries for react-native and cordova that try to detect if a device is rooted/jailbroken, uses mocked locations, runs from an external SD card, etc. (RN: https://github.com/GantMan/jail-monkey, Cordova: https://github.com/dpa99c/cordova-diagnostic-plugin). The methods seem to be similar: for the root check they scan the filesystem for the presence of revealing binaries (su, sshd, etc.) or packages (Cydia, Superuser, etc.). They all use native code for this because otherwise they would not be able to access the filesystem at that level. We would have to do the same.
h2. Metrics
Most of metrics can be covered without native code:
* App Version: read from package.json
* SDK Version: can be exposed from the SDK's package.json
* Platform: react-native provides the Platform module which can be used. Cordova has a plugin but it relies on native code: https://github.com/apache/cordova-plugin-device
* Client ID: On react-native we can use AsyncStorage and on Cordova LocalStorage to save the generated ID.
* App ID: Java package/iOS module: it's probably not possible to retrieve this without native code. On iOS it currently has to be hardcoded even because there is no API to retrieve this information.
So we could cover most of metrics without using native code if we find a different definition for the App ID and a non-native way to retrieve the platform information on Cordova.
h2. Auth
The auth framework is based on OpenID Connect on Android. There is no implementation on iOS yet, but a very similar library exists (https://github.com/openid/AppAuth-iOS). There is a pure JS library (https://github.com/IdentityModel/oidc-client-js) that can be used for Cordova but it has no react-native support. There is a libary for App Auth on react native: https://github.com/FormidableLabs/react-native-app-auth
But i would like to avoid telling our customers to rely on 3rd party modules. We have this functionality in our Android SDK so it would be very inconsistent to tell a customer that on react-native they should just use a 3rd party module.
The pure JS library shows that it is possible without native code and maybe we could even contribute to that project and add react-native support. But short/mid-term it seems to be easier to just wrap our already existing Android SDK (and later iOS).
h2. Push
There has been an attempt to create a pure JS Push client: https://github.com/aerogear/aerogear-js-push. But it is no longer maintained and the functionality seems very limited. The existing Cordova plugin seems well maintained: https://github.com/aerogear/aerogear-cordova-push.
Again, it's probably possible to create a pure JS push client and at some point we will have to do it (to support progressive web apps). But short/mid term it seems easier to use/wrap what's already there.
h2. Conclusion
We can't satisfy all our use cases without using native code (or changing the requirements). That requires us to overthink the SDK architecture. What we wanted to achieve was one SDK that has the same semantics in Cordova, React Native and Browser. And for pure JS code there are ways to achive that (e.g. UMD modules).
With the requirement of native code i'm not sure if the current architecture will work: I don't think we can have one, say, aerogear-js-metrics SDK that can be used in Cordova and React Native and wraps native code? So that leaves us with creating separate modules: aerogaer-reactnative..., aerogear-cordova..., etc. And if we do that there is no smallest common denominator for all three platforms, we can just wrap native code where it makes sense.
The problem is that we won't have a Web SDK as an implicit result of the work. We will have to do that separately.
h2. Next steps
I'll try to build a react-native library and a cordova plugin wrapping what we already have.
Those conclusions are what i get from the investigation. I'm of course open for a discussion about any of this. ping [~davidmartin] [~wtrocki] [~phajidec] [~danielpassos] [~jgallaso] |
|
