Progressive Enhancement (PE) is a web design strategy that concentrates on accessibility to ensure that basic functionality is available to all while making the most of available tools to improve the experience for the user whenever possible.
While the practices involved in PE can't directly be mapped to mobile development some of the principles that it employs certainly can be.
Separation of Concerns
A central concept of PE is that content should be separated from presentation, this application of the Single Responsibility Principle (SRP) by separating concerns can be applied to any area of coding that has a UI it presents to its users.
Within our mobile apps their should be code that generates/retrieves data and their should be code that displays that data, their is no reason for these two areas of code to be aware of each other and each should be able to very independently in its implementation.
Code that deals with data shouldn't care what your intending to do with it, code that presents the data shouldn't care where it comes from.
By separating these things out we limit the impact of change and ensure as much re-use as possible.
For example if each piece of UI code is obtaining data directly and we make a change to how that data should be accessed we suddenly have a large repetitive re-factoring job on our hands.
Control Freak
Within a web environment PE will encourage having has much code as possible in an environment we do control, the server, and minimising the amount of code in an environment we don't control, the browser.
You may think we'll that doesn't apply to mobile we control all of it?
But do we, how much can we change the structure of our code when were working in the UI layer on iOS or Android? Or is it case that we have to fall in line with our Activities and View Controllers.
Even within mobile we should be trying to create an architecture that puts as much code as possible outside of any platform enforced constraints. We have to tow the line in the UI layer but we are king in our service layer, data layer and any other abstraction we chose to have.
When we interact directly with the OS we not only have less freedom in our architecture we are also exposed to more potential change, the next version of Android or iOS might introduce changes that could break us so lets make sure the surface area of our code exposed to this danger is as small as possible.
Don't Assume Anything
The reason PE exists is because with so many browsers and possible configurations out their you cannot assume anything about the functionality or tooling that may be available.
A common problem in mobile development is when we assume we will always have certain resources available to us, most common of these are internet connectivity and location.
So many apps end up just showing empty screens or white space whenever a call cannot be made to a server or the users location isn't known.
I'm not saying your app has to miraculously work even without internet or if the user cannot be located, but it should anticipate that this situation may arise and keep the user informed as to whats going on and do its best to still offer some level of functionality.
Just because we may work primarily in a certain field of development whether that be mobile, web, database or infrastructure there are still things we can learn taking the basic truth of certain principles and applying them to our particular area.
There's always more to learn as a developer and the best way to tackle certain problems is as a group so take advantage of all that collective knowledge and experience by being open minded about what others with a different perspective can teach you.
No comments:
Post a Comment