1,905 reads

Android is hard

by Andrea FranceschiniDecember 1st, 2016

Too Long; Didn't Read

In 2011 I was asked to make a free iOS app implementing a spreadsheet based on a couple of medical papers. After I completed it, the client lost interest and didn’t pay me, so I published it as a paid app.

Companies Mentioned

TL;DR. I have my very first Android app out!

CRUSADE Bleeding Score - Android Apps on Google Play_Helps cardiologists estimate a patient’s risk of in-hospital major bleeding._play.google.com

Backstory

CRUSADE Bleeding Score Calculator on the App Store_Read reviews, compare customer ratings, see screenshots, and learn more about CRUSADE Bleeding Score Calculator…_itunes.apple.com

Well, no. I initially published it for free with ads for a while, looked at the numbers go up, then removed the ads and started selling it for $0,99. The numbers kept going up, and I am now making between 15 and 35 euros per month: well enough to cover my developer account fees.

This app became my pet project designed to keep me in touch with the ever-changing basics of iOS. I eventually developed an iPad version, with a slightly modified UI — which pushed the price up a bit. I integrated Crashlytics, now Fabric, which helps a great deal with maintenance and device intelligence. Very recently, I rolled out an Apple TV version, although that is still sitting alone on the App Store’s shelves, so that did not push the price up because hey.

Enter Android

Earlier this year I bought my very first smartphone — I know — and an Android at that. I had been meaning to try some Android development for a long time, but always delayed it because the Android emulator had abysmal performance, so I could not even try. But now I had this phone, so porting my pet project app seemed like a good idea to get me started and to keep track of Android development. I read a bit about it, I installed Android Studio, and I created my project.

I was well aware that there are some significant differences in UI conventions and UX between iOS and Android, so I started researching those first.

Writing code

On iOS, the small screen version has three tabs, the first two for the two different calculations, based on the two scientific papers, and the third one for some information about the app.

Tabs on iOS appear on the bottom of the screen. Tabs on Android tend to appear at the top of the screen, although things are a-changing. I decided to stick with the top of the screen, as it was the predominant choice for a long time in Androidland, so I figured most people would be used to it.

Confusingly enough, Android does not have a direct equivalent of a UITabBarController in which you plug all your UIViewController children of various definitions. Instead, you have to extend a FragmentPagerAdapter and stick a TabLayout on top of it. To make things more interesting, Fragments are apparently too new to be first class citizens, and to make things incredibly more confusing, why would I even want to differentiate a Fragment from an Activity when every UIViewController on iOS can be plugged in as a child of any other UIViewController and live a long and happy life? Cherry on top: the Compat library. If you want to support older versions of Android, no problemo! Just import the backward compatibility library et voilà, there you have all your latest and greatest toys implemented to various degrees of completeness, functionality, and stability all the way to Android 2 — for comparison, we are now on version 7, Apple basically ditched whatever can not upgrade to iOS 8, meaning stuff made way longer than four years ago. All this without mentioning that some of the new toys end up directly in Compat, with no non-compat equivalent to be seen. In short: you are stuck with Compat, and Compat does not even always make sense. Philosophically speaking, this is not a very good starting point.

This is more or less how it felt.

Designing the iOS version of the app was easy enough, even though the only sensible way of doing this in iOS is by using a UITableView with custom cells. Not the greatest, but no big deal either: with a little elbow grease, I got it done. I’m not going to pretend UITableViews are easy to deal with. In fact, setting up a screen that mimics System Preferences closely enough to provide a least-astonishing experience can be quite a nightmare, so I was relieved when I learned that Android has a Fragment for that. Except that it took me a full week to set the FragmentPagerAdapter and the TabLayout on their own, don’t even get me started with plugging a PreferenceFragment in — of which you obviously need to use the Compat version to be able to serve ancient devices that haven’t been sold in ages anywhere on Earth — but hey, someone out there might still be using Windows 3.11 on a 386, right?

Further disclaimer: bear in mind that I’m doing this in my own spare time, and that it took me a good month to wrap my head around iOS when I first started doing it professionally in 2011, having very limited prior experience of embedded development.

Anyway, I finally had something on my phone’s screen! Success! I decided to take a break and design the Info page before going back to implementing business logic.

Tools

The first time I looked into tools was when Android was very young and the best you could do was Eclipse. The situation improved over time, and Android Studio is now not entirely unpleasant. Android Studio is built on top of IntelliJ IDEA, which is a nice IDE, though somewhat clunky. The debugger is not half as bad as I thought, and the build process is nicely integrated, although horribly slow at times. I’m just going to say that Xcode was a mess, when I started, but has become quite a nice and functional IDE over time. Android Studio… not quite there yet. But I have faith in you, Google.

I started designing the Info screen, and that was when I learned that Android has now its own constraint-based layout thingie. I was overjoyed! If you don’t know what I’m talking about, constraint-based UI design is a way of placing objects on the screen by describing the spatial relationships between them, and between themselves. Something like, “this label has to be on the right of this button, and their horizontal distance can’t be shorter than 10 points, and longer than 20 points”. Apple did an amazing job with their constraint engine, and Android is… getting there.

The way in which iOS screen classes and constraints work together makes the whole thing move nicely, but hey, here’s one thing in Android I’m not complaining about!

Anyway, the whole ‘design the Info page’ business was relatively painless, if not borderline pleasant. At the very least, it was a bit less frustrating than Apple’s was at the beginning.

Java

I am a hater, I admit it. I hate Java. I hate everything about Java. I have been hating Java since the first time I touched it in 2002, and I have tried to avoid it as much as I could ever since. I am not going to explain my reasons behind my hate because this post is not about Java, so: Java is my bane, and I am not alone.

Obviously, Java must have made a lot of sense to Google when they were designing Android. You plan to deploy on an array of wildly different architectures over which you intend to have no control. You don’t want to force every developer to set up ten, twenty different toolchains just for the sake of it. With Java, app developers compile their code once for a single known fake architecture, and you build a virtual machine that pretends to be said fake architecture to run your code. Every device manufacturer should be responsible for compiling the virtual machine so that it runs correctly on their chosen architecture. This plan has some flaws, but I can see how Google made that choice. I do.

That does not mean that Java is perfect, and people tried to fix it, and made a complete, giant, illogical mess out of it, so much that some other people said “hey, Java is a mess but the whole virtual machine shebang is not entirely stupid, let’s just make better languages and forget about Java!”. Google must have missed the memo, and got into a huge legal battle with the owners of Java along the way. And had to develop their own virtual machine just for good measure.

Publishing the app

I searched “how to publish an app on Google Play” online and I was expecting a nice and detailed step-by-step guide on how to prepare your app for release (check), how to set up a developer account (cheeeh…ck), and how to build and sign your app for submission (eeeh…).

In a matter of minutes I ended up with a merchant account based in a country that is not the one I wanted because apparently Google inferred it from my payment card, and now I can’t change it (easily, at least), and I still have no idea how signing my app is done, nor if my signature is secure enough, and on what protocol it is based.

By comparison, Apple makes you jump through way more hoops, but at least they check that you are who you say you are, and explain everything thoroughly at every step of the way. You have to create a certificate through an online interactive procedure, you have to take care of it, and generate individual signatures for all your apps that expire within one year, so you are much more involved in the process, and aware of it all. That is not considering the fact that Xcode takes care of the whole process, from building and signing, to submitting to the App Store, whereas Android Studio barely gives you the compiled binary, signed who knows how, and then it’s up to you.

You know how they say to make things easy, but not any easier than they need to be? That’s because otherwise people will do hard stuff carelessly and make a mess.

Yes, I understand that there is Only One App Store, and there are dozens of Android stores, but hey, Android Studio does not even support Google Play!

In conclusion

In conclusion, I managed to publish my app. It’s here.

CRUSADE Bleeding Score - Android Apps on Google Play_Helps cardiologists estimate a patient's risk of in-hospital major bleeding._play.google.com

It’s cheap. If you are a cardiologist, you’ll probably want to take a look at it. If you know a cardiologist, you may want to let them know. And may I remind you that I have an Apple TV version out too — that also runs on iPhones, iPods, iPads, the whole lot.