Developing beyond the screen
How React Native, Firebase and innovative design and math skills are helping us to reinvent the wheel, smart homes and release Yeti.
It is no secret that in Netbeast we decided to shift our focus from developers to the masses therefore we had to discontinue developing new features for our awarded open source IoT framework, the Netbeast Dashboard. We were decided to package all our know-how to build a simple solution that was installable by anyone.
Our mission already was to make homes work for you, rather than the opposite. But we could simply not package our dashboard into an app, because it was not designed for that. It would have been a crazy workaround and maintaining both our activity in front of the open source community and the public would’ve been much complex.
So a team of engineers with no experience in Android nor iOS, decided to start developing native mobiles apps. And achieved it in 10 weeks with more than 41 native dependencies, lots of native code wrote and, above all, a lot of React Native.
This article is a collection of Things We Wish We Had Known Before Getting Started with our new adventure and other nuances.
Disclaimer: Do not try this at home, unless you know what you are doing.
React Native is a bliss, if you know how to ride that horse. In first place you need to understand how importing native libraries is, specially in an app that uses an amalgam of sensors, network capacities, bluetooth and location. Because those APIs have not yet been integrated in the mainstream Facebook React Native releases. All of that having in mind how bridges from native to javascript work, where are the bottlenecks of performance, etc. Also there is a huge problem, not yet optimally solved: routing. How to render different screens and navigate among them. Remember that React Native –at least in our app– had to be built to Android and iOS at least.
Learning all of that was tough, but it would have been much harder to learn from scratch to create good native experiences in Swift and Java separately, duplicating our workload and recreating (in a different manner) the logic that makes our services work on each native language. Choosing React Native allowed us to focus all of our workforce into developing Yeti, and resolving together the particulars for each platform. That is what gave us that speed boost, so enter the crowded smart home space so fast. And now we are ready to play, developing and improving our product at an amazing pace.
Other problems appeared through the way. Even though we had available 100% of our developer power into the product there were some more caveats: React Native landscape is (still) almost desert. When we started, few components where available, contrary to the support and many many components, sdks, and tutorials that we can find for Java, C-objective or Swift.
However we already knew how fast javascript moves forward, and how could we benefit and contribute to that. Being Open Source and participating into many Open Source communities, we already experienced the boom of npm and React. We knew it would become easier as we mature our product to find more support to the technology. And it was true: each week we found updates, fixes and documentation. We also try to do the same thing and our developers contribute to dozens of other projects, via issues, pull requests or publishing the things we develop and use on our own (SSDP port to React native, A Dial component, Slack bots and a long list of forks)
Now, developing beyond the screen
Here is where we have to think the most about design and math. Devices as bulbs, thermostat, sensors and cameras handle a lot of information, and their interfaces often represent physical properties. Distances, switches, colour maps or graphics is what we have to design from the bottom to the top daily. And that is exciting.
Our brightness control is a complex animation where the speed and radius of the component is described by the following formulae:
Since we try to innovate and match our user interfaces with the real world, we commit also mistakes, and try to be always hearing to our users to see if they actually like the way the app is growing for them. For example it is tough to make an intuitive relation between luminosity and a bar, however it fits more natural when related to the actual power it is transmitting, leaving other dimensions to less sensitive parameters as saturation or warmth of a light.
There are more examples on how we use math and sensors in an innovative way. Yeti is the first app that detects if actually a device is plugged into a smart plug. Sounds easy right? Not so fast, many smart switchers are just on/off devices even with measuring capabilities. If we can grab power data form the source, we detect the existence of a plugged device. Independently of the brand or API.
Developing for a wide range of physical + software experiences forces us to create a Multiverse of mini-apps. React Native, thanks to its component modularity helps us to have many little bricks that we reuse, to build each one of those interfaces. Without it, we could not have developed an awesome Sonos + Spotify controller either, which it is on is own as complex as a stand-alone app.
Reducing complexity
Managing state on an app is complicated. Really. Representing data and maintaining it valid, logic and uncorrupted, offline and distributed concerns a lot of developers. And it is concretely where lots of Facebook engineers put the focus when they created Flux.
Imagine how complex it is if your state, literally, goes beyond the screen. It is stored not only in the cloud of many different manufacturers, but also offline in your app, locally in your home and eventually in many different hardware devices.
We embraced Redux because of its simplicity. It allows us to keep the interface consistent with our local state, and that is already an achievement. We use redux to update and hold states also offline and in our local network. It is however a huge problem still to delegate and maintain the whole thing coherent, and that holds a lot of our developer time. Nevertheless it is worth to mention than Redux has saved us a lot of time and thanks to other APIs as AsyncStorage we had the privilege to forget about best practices in different platforms and focus on our own expertise. Which also happens to be extremely efficient and helps us provide a nice and fast UX.
A base for the infrastructure
We had to develop everything and develop it fast. We know that scaling processes are really hard, but those can be smartly be addressed as the app scales if one is well aware beforehand. But preparing for the scale before it happens is a no-brain.
Developing is really hard. Developing for the scale is even harder. You need resources, think before hand of efficient data structures, choose the appropriate configurations and service providers and then deploy and keep services updated and available. If one wants to do all of that and do it well, it is going to take a lot of effort. Even a experienced systems architecture with lots of ease writing APIs and SQL can acknowledge the amount of time that he actually needs to get it done and tested.
That is why we chose Firebase. Since they were a little startup (before being bought by Google) I found it extremely useful: create a reliable database with a convenient document-oriented (and fast) data structure that works as an API out of the box. A serverless solution.
We are managing now hundreds of daily users in iOS and Android operating without a single line of backend code. Except for a little cute bot that makes sure that everything is alright at home taking care of your routines.
* * *
Holding state in a distributed system, developing reach user experiences and maintaining a solid and testable code base have been our reasons to use React Native, Redux. Firebase came to the table so we did not need to write a lot of backend code.
Starting was exciting, but we are already preparing for the next thing. You should stay tuned. I can promise we will not scale either as a conventional business.
Thanks for reading so far. Hopefully I managed to share a bit of what we do that is useful to you.
