React Native Nuggets — episode #02
or: testing, testing, testing
Being a complete newbie, I banged my head many times into many walls throughout the long journey that took me where I am now — and a few times I felt the need to write down the error, the solution, the trick or the workaround that helped me.
What you’ll find in this series is the list of all these small bits of knowledge, with the hope that at least once, to someone, one of them may be helpful to you reader 🤓
Nugget #4: always test on both platforms
Put aside some rare cases when you need React Native to ex. release on just iOS, or maybe to create an add-on for an existing native application, the chances are that you are using this fantastic framework to write code once and deploy for both markets.
When I started, I was pretty confident that the incredible power of React Native would create, from my code, the same result for both platforms: Oh what a sweet summer child hope I had. As soon as you move up with the complexity, you may find that the same code can create very different results depending on the platform (ex. react-navigation): to avoid situations where you run
run-ios and end up saying way too many “hey what?! it wasn’t doing that on Android!”, try saving (at least!) one hour per week to run your app on the platform you don’t use daily for testing.
Nugget #5: test both development & production releases
Ok, this may be a bit cryptic (or even wrong, you’ll tell me): but, basically, a while back I was coding a page where the user could set up the classic starting and ending date&time for an appointment. I was using the standard JS Date object, and, even if the logic wasn’t the best ever, the app was working just fine while I was developing on my “Android test device”.
So, without thinking about it too much, I generated the release version and uploaded it to the alpha stage of the Google Play Store, to have some users try it out; result? 💥CRASHES EVERYWHERE💥
Turns out that — from my understanding — the version of the JS built-in for the develop version was slightly different from the version in release, in a way that what I was doing in the code was accepted by the develop version, while in the release version it was crashing the app.
So, the bottom line is: always test yourself both versions, don’t fall into the trap of “well it works on dev” — it will save your reputation with that pesky client soooo many times 😎
And, bonus side-nugget: always use moment.js when handling date & times— you’ll thank me later.
Nugget #6: Buy a cheap Android phone for testing
Since the overall “theme” of this episode is testing, here my last advice on this argument: find a cheap sub-150£/€/$ Android phone, buy it and use that for the classic
react-native run-android command.
When developing, using iOS simulator is ok (mainly because it’s fairly complex to get it to run on an iPhone) — but most of your users will probably not use a top-notch spec heavy iPhone 7 plus or a Galaxy S8, which both have probably the same “power” as the laptop I’m using to write this article. They will have an aged phone with a small screen and without all the tweaks and apps you have installed on your device: it is fitting for you to get an idea by yourself of how your app will perform in that situation.
Moreover, it will save you the pain of figuring out why the google-analytics lib you had to code last week keeps throwing error… just to realise it was because of that system wide adBlocker you installed on your personal custom kernel rooted device 🤖
Did you already knew all of this? Do you have any nugget you’d like to share? Let me know in the comments, I’m always looking forward hearing fellow developers’ opinions!
I have ~20 nuggets left in my journal, so I’ll be writing this series for ~5 more articles, consider following me here or on Twitter to be updated on next episodes.
And, as always,
Happy coding! 🤖