With mobile devices becoming the primary way people access the internet and perform daily online tasks, it’s understandable that a lot of people will casually come up with ideas for the next great app.
In fact, at least as far as the Android platform goes, these idle dreamers are the source of almost all the system’s library of software.
This can result in a lot of “shovels” being produced, but it also provides that sense of freedom and wild endeavor that’s the perfect formula for innovation and, to be cliché, thinking outside the box.
Given the seeming simplicity of mobile interfaces, it’s easy to expect mobile development to be considerably easier to tackle than desktop development.
Sometimes this can be true. It’s really a matter of perspective. While the core logic of programming doesn’t really change from mobile device to desktop to game console, the quirks, eccentricities and abstract practices can be distinct from one to the other.
What’re the general principles of mobile development that differ from other environments?
In truth, a lot of these will be very common sense, especially to those with existing programming experience. However, it’s far more important to take these common-sense tenets to heart in mobile environments.
Let’s take a look at some of the most important things to keep in mind when developing for mobile devices.
Single Responsibility Principle, or SRP:
The single responsibility principle should generally be adhered to in most if not all environments, but in the very modular nature of the mobile app, the design makes this so much more important here. What is SRP exactly?
In a nutshell, SRP is the idea of every module, class, an element having a very specific task in mind. The entirety of this object’s code is dedicated to performing this task and no others if possible.
Think of it not unlike the common if the inaccurate portrayal of a beehive. Each worker bee is given a specific task, and it performs this task and this task alone.
Each component having a singular task not only produces a more organized project structure, but it results in far more efficient design overall. It also makes tracking problems down much easier, and updates far less messy to implement.
When planning your app, determine every core task that needs to be performed during the app’s operation, and expect to design a module dedicated entirely to each of these tasks.
Open/Closed Principle, or OCP:
This sounds like a bit of a paradox, doesn’t it?
How can something be open and closed at the same time? Well, it all comes down to how you design your task-oriented classes and modules.
You’ll inevitably want to expand the functionality of some or all of your design when you release a new version of your software (or simply decide to add something to the project before it’s complete).
To keep this from becoming an unholy mess (ask an experienced programmer about “spaghettified” code), design your code in a way that new functions can be smoothly added to them without modifying any of the code that already exists.
This may sound complicated, but if you go into this with this sort of design principle in mind, it starts to come naturally to you in shockingly little time.
Liskov Substitution Principle, or LSP:
This is where things can get a little more involved. Any experienced programmer is familiar with abstraction and inheritance of parent and child classes.
A child class can assume the identity of a base parent class while adding case-specific functions and properties to it.
Designing your child classes so that they don’t break the rules of the parent class, thus wildly altering their basic nature, is of paramount importance in mobile design.
Poor abstraction can cause mobile apps to crash in really awkward and disastrous ways. This is, in fact, one of the leading causes of apps crashing.
The Interface Segregation Principle, or ISP:
While the above principles are considered good practices in all programming, this one is very distinctly a mobile concern.
When designing a mobile interface, it’s important to remember the modular nature of app design.
The interface doesn’t need to know how the database modules work, or how the mathematical calculations are done to produce a given result.
It simply needs to know how to render data given to it, feed data it receives to the appropriate component, and trigger the proper events.
The interface, in other words, needs to be kind of dumb and self-contained.
Following this, when an interface becomes too complicated, resulting in running afoul of screen real estate, it’s time to divide it into multiple smaller interfaces that only know what they need to know as well. When it comes to interface design in mobile, remember the old adage, KISS (Keep It Simple Stupid).
The Dependency Inversion Principle, or DIP:
This is another more abstract tenet that’s especially important in mobile.
It essentially deals with proper, efficient dependencies. There should never be a high-level module depending on a low-level module. They should both mutually depend on basic abstractions.
Furthermore, these abstractions shouldn’t depend on details, the details should be defined by the abstractions. Remember LSP from earlier? Now it all comes together.
A Final Note:
It’s worth mentioning that anyone used to standard Windows/X/MacOS desktop interface design may actually find mobile UI design to be a bit obtuse in the beginning.
Mobile interfaces are intended to be more dynamic and responsive, scaling and adapting their layout to constantly changing conditions.
When designing these interfaces, it’ll come more naturally if you’ve at least experimented with modern HTML interface design, which has a lot in common with mobile while being a tad less initially alien.
