When developing an app, it’s often very enticing to just jump right in, focus solely on your Minimum Viable Product (MVP) and get your app onto the market as fast as possible. However, when you code without a plan, you are effectively stealing time from the future. This is the epitome of technical debt. Sure, the program might be out and in the hands of customers, but it’s also a ticking time bomb, waiting to collapse upon itself with one extra line of code.
Photo by Kaleidico on Unsplash
This is where thinking about mobile architecture becomes invaluable; it separates the ‘ok’ apps from the ones that stand the test of time. It allows your app to grow and expand your product without worrying that the whole thing is going to come tumbling down like a stack of cards.
When beginning to plan the mobile architecture for your app, there are some simple questions that need to be asked.
- How can we break down the business problems into layers?
- Where are all the places where your apps state can change?
- What are the external systems we need to connect to?
As always, if you need to add a senior mobile developer to your project with a mobile architecture first mentality, contact us.
Layers
Layers are one of the most fundamental architectural concepts. They essentially involve you breaking down your app into a hierarchy of responsibilities. Each layer, or group of classes, handles one job – such as making network requests or drawing user interfaces. If a layer needs more information, it can talk to the layer either directly above it or below it, but that’s it.
The following diagram illustrates a simple layering strategy for a mobile app.
At the topmost layer, we have our user interface (UI). These are our buttons, screens, lists, switches, etc. If it needs to be painted on the screen, it goes here. The user interface knows know to talk to two different lower layers – The Business Logic layer and the Analytics layer. We already have a very clear, but albeit simplified separation. The UI doesn’t know any of the rules for our app, it just knows how to make things look pretty. It can also report to the analytics layer when something interesting happens, like a screen view or a form submit. Notice that the UI layer only knows about generic analytics, not specific providers like Google or Facebook.
There is also a full layer of indirection between the User Interface and Networking layers. This implies that under no condition are classes in the UI layer allowed to make network calls – they must talk through an intermediary. The reasoning for this is because the business logic layer may not need to talk to the network every time the UI makes a request. It has the option of choosing whether to talk to the network or caching layers. If the app has already retrieved data from its API, it is now in a position to intelligently decide if it can use previously fetched data or make a fresh request. These are all decisions that are much easier for a developer to make when their code is compartmentalized into components.
Handling State
State is hard. Managing state in apps, especially the mutation of state and synchronizing these changes with the UI, is one of the most constantly debated topics amongst developers. The prevalence of design patterns that try to solve this problem should immediately indicate its complexity – Redux, MobX, MVVM, MVC, Rx, BLoC, etc.
Which one should you choose? Is Redux the one pattern to rule them all? No.
Mobile architecture decisions need to start from the top down. You need to carefully gather your requirements for the app and analyze all the different points where your apps state is mutated. After completing this exercise, the way forward should become clear.
- Is your app primarily a CRUD app? Try MVC.
- Do you need an undo feature or want to replay your user’s actions? Try Redux.
- If one element in your app changes, do many components need to response? Try BLoC.
Also, it’s never too late to choose some combination of state management or even something unique that applies to your apps specific requirements.
Managing External Systems
Photo by Kaleidico on Unsplash
Apps rarely exist in a vacuum. At the very least, your app will likely need to communicate with a backend system that is hosted on a remote server. In addition, there could be multiple analytics systems, advertising providers or integrations with external hardware via Bluetooth. Every time data leaves your app to travel to another application, some extra considerations need to be made when architecting the integrations.
Firstly, integrations between systems, are the first vector of attack that hackers will target. These are exposed entry points in your system that need to be protected carefully. At a bare minimum, all communication over the internet should be done over HTTPS, not HTTP. In addition, there are extra layers of authentications that can be used such as JWT (Json Web Tokens) or OAuth.
As with user data, external systems are also often in a state of flux. APIs change. Servers can fail and the wear and tear of the physical world can impact your apps connection to other devices. Understanding and accounting for the fallibility of external connections is critical to providing a strong user experience, even when things don’t go according to plan. Strong mobile architecture plans for the worst but hopes for the best.
Though it may seem like excessive effort, investing in scalable mobile architecture pays dividends as your app matures and expands.
If you want to build a mobile app that can stand the test of time, contact us today at www.briankayfitz.com