Writing and Then Re-Writing a React-Native Library
A couple of years ago I was assigned a task to implement an application feature that allows users to switch between application icons. The application was built using React-Native so my solution was to write an open-source library called react-native-change-icon.
Writing
I began by using the react-native-create-library tool to create a template that provided me with the basic file and directory setup which includes the required Java classes for Android and Objective-C modules for iOS. Now you might think that I must be mad skilled at writing code in Java and Objective-C but that far away from the truth. I had some experience with Java before but I never used it for Android, and it was the first time that I was using Objective-C, that too for writing something for iOS applications.
I started searching for tutorials and documentation for both Android and iOS to find ways to implement the task. For iOS, I was able to find a blog that provided a straightaway implementation of the method setAlternateIconName in Objective-C and the setup that I needed to create in order to use this. For Android, I did not find any direct way to implement this but I found an article in which a similar functionality was created by manipulating the <activity-alias> element.
iOS
The implementation for iOS was pretty straightforward. First, we need to add and link multiple icons in the Xcode project of iOS app. Then, we mention these icons in the Info.plist file to be used as alternate icons. Then, to switch the icon, we need to pass the name of the icon we need to activate in the setAlternateIconName method.
Android
The implementation for Android was a bit tricky. First, we need to add all the icon assets in the mipmap directories. Next step would be to create an <activity-alias> element for each of the icons that's there in the application's assets. As we’ll be using <activity-alias> elements to display the application icon on the device launcher, we can remove the activity MAIN and category LAUNCHER intent filters from the <activity> element. The functionality will work by enabling one <activity-alias> at a time and when switching the icon, we’ll disable the previous activity and enable the new one. We’ll create a custom function that can do this using the Android activity package manager. As I said the implementation is tricky but you’ll get a clearer picture by watching the code implementation.
Package
The native implementation was finalised but now I had figure out how to give this functionality to the React-Native context. For this, React-Native has provided an API called NativeModules. It provides native packages that can be used to expose your native classes and methods to the JavaScript context through the React-Native bridge. The API would have been easy to use if there was proper documentation at the time I was writing this library as they have now. With this API, you can call native methods with arguments, get callback values or return promises with values. I used these APIs to export the changeIcon method from the Android Java module and the iOS Objective-C module.
With this, the package implementation was complete and I published this package on NPM.
Life of the package
Since the time of its initial release, the package received a number of issues and pull requests from the open-source community. These issues and pull requests helped in continuous updating of the package to work with the latest React-Native, iOS and Android versions.
Re-Writing
Recently I came across a new CLI tool that generates templates for new libraries which is @react-native-community/bob. This package allows you to generate templates in multiple native languages that work with Android and iOS. You can use Kotlin or Java for Android and Objective-C or Swift for iOS. With this package, I generated a template for the change icon package written in Kotlin for Android and Swift for iOS. Now all I had to do was convert the code that I already wrote in Java and Objective-C to Kotlin and Swift.
The template generated was very seamless to work with. It included a setup which I didn’t have previously because I didn’t think I actually needed it. To all the people who are creating a new react-native library, I would strongly suggest you go with this tool. It takes all the pressure of your mind to create all the basic and recommended setup for an NPM package. You are able to just focus on your native implementation.
There is really good documentation for working with Kotlin and Swift. I was able to move all my code to these languages pretty easily. From the point of view of a package user, nothing was changed, the steps to install and use the package remained the same.
Conclusion
As a package owner, I would suggest to always keep good documentation for your package. Provide step-by-step instructions to install and use the package. For react-native packages, the installation and usage might be a little tricky so in my opinion, you should always create an example application that uses your package, it makes a lot easier for people to understand how to use the package. While creating a release, write a good changelog that exclusively mentions the breaking changes. Maintaining the package is one of the most important aspect for owning a package.
Thank you for reading this!
