6 Features and 8 constraints to manage in your modern Android App
This article is part of a series that introduces you to BADASS: a framework that kick the ass of your Android development time.
As in other post I use the example of an app that give you the weather at your current location.
This part explains the constraints and the functionality a modern Android app needs to manage to deal with remote data (server/API/Connected object) .
The four horsemen of Android app architecture apocalypse
Today, there is four actors that interact in an Android application:
- The User
- Application (App) itself
- Android I.E the operating system and the device that hosts it
- Remote Data located in distant server, API or connected object
You will see that these actors and theirs interactions involve features but above all constraints to be managed.
Let’s get in details to the four actors of this play and let’s see what are the implications.
The User: He wants all data now (and he doesn’t care about your problems)
First of all, the main purpose of your app is to give to the user data.
And the user wants this data displayed in a way he can understand: text, sound, charts, pictures, video and so on…not an SQLite database or Json file.
But there’s more, nowadays the user is just an asshole (yes asshole, I discuss this subject further down) and that implies some features for your app.
Feature 1(F1): Data are always and quickly available in a understandable format
This first feature, in my opinion, is the most important of all.
The user wants data to be always available inside an activity, widget or notification. And he doesn’t care about constraints like no connection to internet, your server and/or API.
He also wants data quickly: Yes it’s obvious but remember all these apps with long intro and/or splash-screen. It’s a main concern for many, I’m not the only dev that worked on that subject.
And, of course, he wants data in a understandable format, with sentences and charts, not incomprehensible XML or JSON files.
F2: The user can interact with app and data anytime
The user wants to interact with app and data. Anytime, even in the middle of the computation of remote data or..offline.
User might want to refresh the data with the remote one, he may want to filter it (in my app example: weather forecast only at the time he leaves for office for example).
He can be also a source of data. For example he may indicate locations where he wants weather forecasts.
And he can add, edit or remove his data : add a position, change it or remove it.
F3: The user has information about data status
The user may want to know data status. Is data refreshing? When did the GPS got the last location? When was the last weather report? Was there a problem?
Bonus: The user is an asshole, deal with it
The user is not your friend, he doesn’t care about your constraints, he doesn’t give a damn if you’re a student or a big corporation with hundreds of developers: he just wants his data.
And it’s very important, because the user will not hesitate to uninstall your app (80% of all app users churn within 90 days) or try a competitor (and there is more than 3 600 000 apps on google play!). Even worse, if the app performance is no good enough, he may never see it on the play store.
It is therefore in your best interest to meet your user’s needs particularly well.
So far, this is what you already have to deal with:
- F1(Feature 1): Data are always and quickly available in a understandable format
- F2: The user can always interact with app and data
- F3: The user has information about data status
The app: a little one with many needs
Let’s discuss your app. It’s not the worst actor in this drama but it has its needs.
F4: App has own data to be quickly and always available
To do the work your app has to put some things in order to work. For example you app has its own data (meta data about user data, some preferences from the user…). It also should have some data to get from outside world: Authentification, ads, billing information.. And this data should also be quickly and always available.
F5: App must prepare itself before doing the real job
For example, App needs to connect to some distant server (Crashlytics, firebase…) in order to work.
F6: App may have to communicate data to developer
It can be just a log file for debug, or some data for analytics.
Constraint 1 (C1): APP must be compatible with as many versions of Android as possible
If you don’t want to be limited to users of the latest version (21 % on Oreo at the end of 2018) you must develop it to be compatible with as many versions of Android as possible
Recap
Let’s add these points to the list:
- F5 (Feature 5): App has own data to be quickly and always available
- F6: App must prepare itself before doing the real job
- F7: App may have to communicate data to developer
- C1 (Constraint 1): APP must be compatible with as many versions of Android as possible
Android: it’s (very) complicated
Well, “Android”. It’s complicated. Really.
First of all, when I talk about Android I mean both the operating system and the devices that host it (Google APIs are discussed in the remote data section).
So, in order to give user data, your app needs Android to do many, many, many things: store data, access internet, get GPS location and so on.
If Android can do all of this stuff, I will address the many constraints it generates.
C2 (Constraint 2): Android can kill app anytime
…and it’s sooner than you would like.
First your device: It can be turned off at anytime, so does your app. And Android system can also kill your app anytime, for example if it’s not currently used by user. It’s a huge constraint, you can’t really manage your application lifecycle.
No matter if:
- you want to connect to remote server at a specific time
- you want to listen to server/API pushes
- you have a widget that continuously display important data and to be refreshed some times
Android can kill your app at anytime.
Why?
First of all, Android has an heavy legacy, it was launched in 2007:
- For device with very low specs ( ≈ 500 MHz processor with ≈192 MB RAM) and small battery capacity (≈ 1000 mAh, a third of 2018 ones).
- For the users that wanted to launch tiny apps between the real thing that can’t be missed at any cost: making and receiving calls
You see that people that develop the Android OS had to chose from the very beginning between your Dev Experience (DX) and User Experience (UX). They are making huge efforts to make it dev friendly but when they have to chose between DX and UX they always chose UX.
Even if it can be a pain in the ass for us, we all know it’s better that way.
It’s also explains why all is about the Activity thing and its lifecycle.
C3: “Time-consuming tasks” must be done on background thread
Related to previous constraint, you have the particular problem of the UI thread.
To prevent your app for locking the system (and blocking important calls) the OS has the ANR system. If you have any task that takes “some time”, Android forces you to do it in the background.
C4: App needs Android permission before getting data
In that “UX > DX” philosophy, to prevent some assholes to use app for doing some nasty things, your app need explicit permission from the user to access certain type of data. So (from Android M) you have to:
- Check if you have the permission (and you know what: the user can change the permissions outside of your app, so you have to check often!)
- Ask the user if and especially when it is necessary
- Manage the response (“so you want me to give you the weather at your location…but you don’t want me to get your location….”)
As you see there is not really any technical challenge but you must think about the ergonomy of your application according to this permissions system.
Recap
So here’s the new points on the list:
- Constraint 2 (C2): Android can kill app anytime
- C3: “time-consuming tasks” must be done on background thread
- C4: App needs Android permission before getting data
Remote data: in a galaxy far far away
Here we are with the last chapter: remote data. By now, I will sometimes just say data but always translate it as “Fuckin’ super boring remote data to deal with”
This is the central point. We’re dealing with data that are not reachable by your app directly.
The most intuitive exemple is data on a distant server or website. But we will deal also with:
- Data provided by Android OS like GPS position
- Data from API like Google Map
- Data generated by a connected object (ex: heart rate by your watch)
They share the same constraints:
They are not reachable directly and you must “pay” a certain cost to fetch them.
But let me detail this in four constraints. Le’s begin with the constraint of not being reachable directly.
Constraint 5(C5): Remote data is not always available
The main (and most intuitive) constraint about data is that’s not always available. It can be for obvious reasons such as not having any network or that the server/API is down but this may also be due to user choice: He can turn Wifi/data/GPS off or use an app that restrains app network usage.
C6: Remote data is not readily available
This is a huge and nasty one.
For example, remote data are not always available directly. Sometimes you must first connect to the server/API before asking for data. And it can be a not so simple process with login, password and so on…
Secondly, update cycle is obviously independent from your app life cycle. The location of your device can change anytime, weather reports fall at regular times not when the user asks for it. In a perfect world you want your app to take this into account at this specific moment, in a widget for example, not when the user launch activity.
And the server/API/connected object may not push any data at all. Your app has to manually check if there’s updated data…when you think it should!
Finally, the call is often asynchronous. You ask server/API for data and…it will give you data at a certain point (even when your app is off).
C7: Remote data have multiple sources
Another big constraint: you don’t necessarily have a single source of data. And sources can be linked to each other. For example you must have the GPS position BEFORE going to Internet to have the forecast of your position. Yes it multiplies other constraints.
C8: Remote data have multiple cost
It can be computational and/or financial.
Computing cost
Remote data are often in a form not readable by a normally constituted human being. You do not show XML/JSON as is to your users. You need to compute them to transform more than 3000 lines xml into “Sunny”. And it can take some times (so you must do it in background and so on…).
Financial cost
Some API, I know many in weather forecast, have a subscription fee. It’s linked to direct call to their API and/or by call by minute. So you want to make as few calls as possible!
Bonus:
Yes, all constraints can apply simultaneously and they often interacts in a nasty way.
Recap
Let’s add these constraints to the list:
- Constraint 6 (C6): Remote data are not always available
- C7: Remote data are not readily available
- C8: Remote data have multiple sources
- C9: Remote data have multiple cost
The complete List
Features
- F1: Data are always and quickly available in a comprehensible format
- F2: The user can always interact with app and data (refresh, filter, add, edit or remove)
- F3: The user has information about data status
- F4: App has own data to be quickly and always available
- F5: App must prepare itself before doing the real job
- F6: App may have to communicate data to developer
Constraints
- C1: APP must be compatible with as many versions of Android as possible
- C2 : Android can kill app anytime
- C3: “time-consuming tasks” must be done on background thread
- C4: App needs Android permission before getting some data
- C5: Remote data is not always available
- C6: Remote data are not readily available
- C7: Remote data have multiple sources
- C8: Remote data have multiple cost
And we just dealed wit a “simple app”…
In the next episode
We’ll try to respond to all theses features and constraint with some BADASS (Benayoun’s Asynchronous Data Android Simple System)!
BACK TO BADASS HUB.
About me
Pierre Benayoun, 42. Working and drinking red wine in Bordeaux (France). Computer engineer since 2001, Android developer since 2011 and unfortunate one man startup since 2013 (but keep trying). I’m also freelance, happy with my current mission but always open to new opportunities.
Thanks
Thanks to:
- Quentin Dommerc, Simon Cleriot and Christophe Oudar for the numerous corrections of spelling errors.
- Mathias Seguy for the technical comments.
Acknowledgements
Even if the linguistic quality of this article is far from perfect, it would be much worse without Deepl translator.
References
I bought some of the icons here.
