Heuristic Test Strategy Model for App Development
Lucas da Silva Machado | Oct 06, 2022
Hybrid technologies have been employed for quite a while in mobile application development. Frameworks such as PhoneGap and Ionic come with an appealing motto: Develop once, run everywhere. And they actually do what they promise: you write a web-based app once and release it everywhere, from iOS to Android and the Gates of Mordor, as long as it gives support.
I do believe that they play an important role in the mobile app development scene: the huge community of web developers can write mobile app code and are able to deploy fast. But, in my opinion, the idea of developing one shared application for all platforms is dead per se.
…the title said something about code reusability and this guy keeps talking development philosophy. Sorry about that, it’s part of the thinking process. I just want to emphasize: don’t expect full reusability on the UI components. You’ll be able to use a couple of generic widgets seamlessly across both platforms, but that’s the beautiful thing of React Native, it encourages and gives the tools to write dedicated UI code for each platform when needed: it’s as simple as adding a `.ios.js` or `.android.js` suffix.
React Native not only solves the performance issue present on other hybrid solutions, it improves the application quality with a native user experience.
Now let’s say you have already implemented a React web application. It’s up and running, you have used the whole Redux pattern stack, configured webpack for bundling, created actions, reducers, all HTTP requests for API integration, tests, etc. You don’t want to re-implement everything (even if it’s just copying and pasting from the webapp). It’s not just a matter of development time, you would have to manually keep track of updates on both of them, fix bugs on both codebases, and so on. Reusing code is a good idea in the short and long terms.
You can easily inject your web application code as a dependency of your mobile code, using npm. This way you normally access your actions, reducers or helper functions from React Native as any other dependency. And further on, it’s possible to separate the logical part, that is shared between applications, in a different directory.
The view part will have to be done from scratch. Not only because it’s necessary to replace the HTML elements with React Native components, but also because the components will probably have a very different behaviour on the mobile app.
Wait a second, if all platforms share so much code, why don’t we put everything under the same codebase? Well, source code is not the only part of it, each project has a very distinct development environment, build scripts, tests and so on. They could actually reside in separate folders under the same repo: mobile, web and modules. But what if someone has to release a bug fix on a webapp component, it affects other devs that are only working on the mobile components and the other way around. That’s not scalable. Splitting is good.
React Native still has a lot to evolve and it doesn’t replace real native coding, yet. But it opens mobile development doors for a huge number of web engineers, that now are a few API docs away from building good-quality mobile applications. It makes possible to share most of the core logic between web and mobile applications, not only reducing development time, but also creating applications with a more consistent behavior. Together with a native look and feel, it improves user experience and product standards.
Interested on seeing a sample application on this subject? Drop me a line and I’ll be glad to prepare part 2!
Settled down from travelling to build some good applications. Feels comfortable developing on both ends, though lately tends to the front-side of the moon.