Adaptation-related project as iOS or (.aar) Android library

I am exploring the possibility of using response-native to create an iOS structure (android library) that can be distributed and can be integrated with applications, including when creating an application.

For example, supporting a single code base for creating ".framework" for ios or .jar for android (mostly compiled code instead of component code) as a distribution for the developer community.

+15
source share
1 answer

React's own way to install responsive dependencies is through npm install . A very simple solution would be to ship your library without responding to the source code, and then letting the SDK users set to respond to the native using the recommended response method.

https://facebook.imtqy.com/react-native/docs/integration-with-existing-apps.html

The problem with this approach is that their own developers are not familiar with npm install and it is not very convenient for them to solve problems associated with npm install . Native developers are more accustomed to grading and coco-pods to create their own application, and, unfortunately, they respond to native ones, they no longer support it. As an SDK developer, we cannot get our SDK users to start using npm and follow current integration guidelines. Here's how we solved this problem for our use case,

Android:

The host responds to its own maven repository and asks the SDK users to add the line below to their project-level build.gradle file,

 allprojects {    repositories {        jcenter()        maven {            // All of React Native (JS, Android binaries) is installed from private maven repo            url "<Your private maven repo url.>"        }    } } 

Add the line below to the build.gradle application file,

 dependencies {   compile 'com.facebook.react:react-native:0.53.+' } 

You can also use this private maven repository to host your aar SDK file.

With this change, it will be very easy for Android developers to include your SDK and respond natively to their application. The problem with this approach is that you will end up supporting multiple responsive versions in your own private Maven repository ( Maintenance Costs ).

IOS:

Our first solution was to include response libraries in the .framework file and create a thick binary. This requires that you include libReact.a and other .a files related to the reaction in your framework file and link them.

With this solution, your .framework includes all the dependencies. Integration with the SDK will be very simple (just drag it into the Frameworks folder). The problem with this approach was that the React library was growing in size. The latest libReact.a file is 105 MB in size. This means that the file size of the framework will be huge, and SDK users will have difficulty transferring it to github.

We recently moved on to a solution in which we place our own React dependencies in a private module, and SDK users can load response dependencies by adding a few lines to their Podfile. This solution is similar to the recommended way to respond, and the only thing we avoid is npm install . We want to provide both options to our SDK users (one with npm installation and the other without it). Based on the feedback from the SDK users, we will decide on the build process in the future.

Please note that this solution has several limitations and overhead for maintenance, but it solves our use case. This may not work for everyone.

+4
source

Source: https://habr.com/ru/post/1242588/


All Articles