AnyJunk rewrite their current mobile app for partners using . The key reasons for this were to a) add new features and b) bring the mobile development knowledge in house through a tight team collaboration. Based on my past experience with these kind of apps at Bizzby (an on demand services app) and my exposure to React-Native at Hoxfon I felt I could deliver on the company’s expectations.
AnyJunk is a very small but innovative award winning logistics company, with a great development team who share the same culture and values. Some pillars of the culture are the mutual respect for each other’s ideas and expertise, a healthy practice of code review and pair programming and the same passion for code quality and testing.
When planning the rewrite of their service partners’ mobile app, a clear objective was to deliver the best mobile user experience. Another important goal on the agenda was to not compromise the team values, philosophy and development practices. AnyJunk wanted to allow both Scala and React developers to review the mobile app’s code, develop in an iterative way coexisting with the weekly sprints and enable automated testing and continuous releases.
The React-Native mobile app
After comparing a few options of mobile technologies, AnyJunk opted for React-Native. The fact that the team was already familiar with React played an important role in this choice. Meanwhile more companies were sharing their positive experience with React-Native and this convinced both technical and non-technical stakeholders to use it.
Below is a screen shot taken from the final app version showing a service partner job details.
Before this collaboration I only used functional programming at university with OCaml and whilst conducting a few personal experiments with ReasonML, but I had no previous commercial exposure. At AnyJunk I have been exposed to more advanced concepts and I was taught how to code and design the internal API in a functional way using the library.
The Maybe is the first functional construct that I used in the app. Maybes are returned from a helper function called safeGet and provide a clean and reusable way to check the existence of Object properties and exposed me to another important functional concept: the distinction between nullable and non-nullable data.
To fully understand what are the pros of using Maybe and why they solve a very common problem found in React applicationsI suggest to check out Dan Hood’s article that explains in detail how Maybe can be used with redux and improve your code correctness. The following code snippets compare imperative and functional approaches to display a validated collection volume which represent the size in yards of a junk collection. I want the reader to appreciate that even though the imperative way has less lines of code it leaks basic validations into the main program forcing code repetition (lines 15–21).
Encapsulating the validation into a function allows for code to be reused easily and makes the app more resilient to future developers’ mistakes. Note how validateCollectionVolume() returns a Result that can be used for presentation purposes inside the render() function of a Component and for business logic.
The Model layer
After I introduced this pattern in the mobile app the rest of the team and I had few brainstorming sessions to understand why this pattern was useful in the current app structure and how it could be ported and even improved in the web app codebase. Eventually this constructive sessions helped implementing an improved and novel version of this pattern that uses data marshalling to process data between the server and the client. This is an example of cross-pollination of ideas between projects, initiated by peer code review that allowed to improve a shared code pattern through team collaboration. Redux and functional concepts established a common ground for the collaboration that helped to find this new useful pattern. This wouldn’t have happened using a completely different technology for the development of the mobile app.
We did this by extracting the methods for reading and writing to the state into a lens that could be passed in as part of the configuration, as well as extracting some dependencies. This way the redux-offline library doesn’t depend on things that it only needs when an assumption is made about the type of state it’s being used with. The redux-offline-immutable-config library is then a collection of the parameters and dependencies required to use redux-offline with an immutable state specifically, while the config included within redux-offline itself is an equivalent one for a non-immutable state.
The first phase of the project is now completed and the service partner’s app is used by all AnyJunk’s service partners every day. Almost a 100% of the code is shared between Android and iOS and thanks to the tight collaboration and code review carried on during these past months, the in-house AnyJunk team is completely confident in extending and maintaining the React-Native code base. During these time I have learnt a lot of new and useful concepts that I will certainly bring to my next projects.
One of the main benefits of using React-Native at AnyJunk was giving all developers complete visibility of the code and the pattern used. This is a clear improvement over developing Android and iOS apps in isolation, where it is is really hard to communicate and share because of the different languages and paradigms.