Lessons from iOS dev #1: Threads solve nothing

A bit of prehistory: I first wrote Keep Calm on Android about a year ago and the whole app run on the UI thread. All posters were generated, saved, edited, etc on one thread (unless the system did it on another thread for me, which it generally didn’t). I then learnt the quirks of concurrency on Android and I thought great, now the app should run a little smoother. By last summer when I was writing the first version of Keep Calm on iOS I had fallen in love with concurrency, and even the version currently in the store uses about thirty odd threads (hence why it is so slow, and I’m pushing an update).

Firstly, concurrency is absolutely vital in making a good app. You can’t do network communications, heavy file IO or complex processing on the UI thread because it will begin to become unresposive.

Secondly, don’t use performSelectorInBackground: when you need to do something more than once in the background. It creates a whole new thread which is often completely unnecessary. The superior alternative is to use NSOperationQueue. My current pattern is to use a single background queue across the application because creating additional queues is unnecessary: one NSOperationQueue doesn’t represent a single thread (unless you limit it to) and can run several operations concurrently, so there is no real need to create new queues.

Thirdly, it is far too easy to over-use concurrency. I found myself doing loads of UI operations on another thread which eventually meant I was drawing things about three times and just wasting time and processing power.

I have a new rule for working with concurrency: the view and controller layers (I use MVC, as one should with iOS development) should operate on a single main thread however the controller can instantiate tasks on the Model layer either on the main thread or on my separate NSOperationQueue. My reasons for this are because it reduces complexity, is easy to understand and actually ensures that the app ends up being pretty quick. Obviously there are some tasks that the controller may ‘do’ in a separate thread, however I consider them to be Model tasks.

Lessons from iOS dev #0: Intro

I began doing iOS development around a year ago and since then I’ve gradually improved, having learnt Objective-C entirely from scratch. In this past year I’ve published a few iOS apps (most notably Keep Calm which has had nearly 2M downloads) and I’m gradually moving towards some larger projects, hopefully some games, this summer.

A lot of what I’m going to write over the course of these posts is solely from my own experience. Not all of it will be correct but I’m going to try and focus on things that there isn’t as much documentation on that an iOS developer starting out might not realise. I’ve also learnt a lot of neat tricks as well, so I’ll probably cover those.

Aside from benfitting other people, it also has the advantage that I’m getting stuff out of my head and getting it written down because I’m bound to forget it :).

Things I wanted from Android

A year ago today (March 24th 2012) I published a post on my old blog about things that I wanted from Android. I thought I would do a follow up post now, a year later, to see whether or not those things did ever happen:

  • SVG support everywhere: the key advantage of using SVG for UI graphics is that you don’t have problems with pixel density on the screen. Unfortunately Android still doesn’t support the use of SVG like this, so we are stuck with PNGs for UI graphics. The ADT does now make it easier to import one high-resolution graphic and produce lower resolution versions, and 9-patch PNGs are always an option
  • Better font support: Roboto was introduced with Android 4, but Android still lags behind big time on the number of fonts
  • Higher PPI displays: At the time nothing really competed with the iPhone 4/4S, however now there are a good number of Android phones that do.
  • One Android: I had envisioned that all devices would come with one standard Android. This hasn’t happened, but the growing popularity of Nexus devices has lead to more devices using stock/Google Android
  • Google Play gift cards: these have been introduced, and sales have increased as a result 🙂
  • Better integration between Eclipse and Google Play: when you finish producing an iOS app, it only takes a couple of clicks in Xcode to send it off to Apple. With Android, you still have to produce an APK and upload it via the web interface. Obviously this isn’t much of a pain, but I like Apple’s simple system.
  • OTA updates: obviously automatic updating of the Android system is something that vendors do rather than Google (aside from Nexus devices, and their increasing dominance is a very good thing for developers) however the difference between users on the latest version of iOS and Android is still huge. Interestingly, long before the original post was written Google had announced in 2011 the ‘Android Update Alliance’ which promised timely updates by manufactures every 18 months after a device release. This never happened, and I should imagine that the reasoning is that the devices of early 2011 would have been running Android 2.x, whereas the devices released last summer would have been running Android 4.x which required much higher performance
  • A better emulator: today the emulator is much faster, especially thanks to the introduction of GPU/hardware acceleration and a new Intel (rather than ARM) image that makes the execution of apps a hell of a lot faster

Obviously Android still hasn’t met all of these requirements and I didn’t think it will meet some of these for quite some time, if ever. I’m pleased, however, to see that changes have happened and that they have worked. Here is what I would still like from Android, from a developing perspective:

  • Faster development time: This is most likely due to my lack of experience with Android development compared to iOS development, however I’ve found that I can write an iOS app much faster than I can write an Android app. Setting up the UI takes longer, linking the UI to code takes longer, the IDE is slower, the emulator* is slower, deploying the app takes longer and the export process takes longer
  • A better IDE: Eclipse has been a great IDE and it is still very usable, however IntelliJ seems to have a lot more useful features
  • Java?: I’m not sure that we need to stick with Java for Android development at all. Xaramin have done an awesome job at bringing C# to Android, and they claim that performance is just as good (if not better) than Dalvik. That’s impressive, and with a better IDE, nicer language and full API support (but high cost) it certainly is a viable option

*The iOS ’emulator’ is actually a simulator. When you test iOS apps on desktop it compiles an x86 version instead of an ARM version.

Estimating Syllables

The English language, unlike many other languages, has no set rules for what does and doesn’t make a syllable; the dictionary definition is ‘an uninterrupted sound’ that helps to form words. Some dictionaries go onto explain that they can estimated by counting the number of vowels that are surrounded on either side by a syllable.

This basic method actually works in about 75% of the cases that I tried with it. In fact, if you assume Y as a vowel it works with every word in the previous sentence. The problem, however, is that vowels can sometimes appear next to one another and in some cases they will form one continuous sound (such as the io in action) or form two separate sounds (such as the io in lion).

What, therefore, can we do to combat this? The first method is to look for sounds that contain multiple vowels and remove one of the vowels, so ome becomes om and ime becomes im – using the previous method sometime would have four syllables, however by replacing these two sounds we instead correctly identify somtim as having two syllables. I equally found that it was necessary to convert ine to in, ely to ly and ure to ur.

This then solves quite a few problems. Here are some example sentences using solely this method:

  • Shall I compare thee to a summer’s day? = 11
  • Thou art more lovely and more temperate = 13
  • The winds do shake the darling buds of may = 11

Clearly there are faults with this current algorithm, given that Shakespearean sonnets are set in iambic pentameter and therefore have 10 syllables per line (I did find examples, however, where the pronunciation of a word is completely different today, and so my algorithm doesn’t work as effectively on Shakespearean English). By outputting the number of syllables that the program thought was in each word I was able to identify a fault:

  • Compare = 3 syllables
  • More = 2 syllables
  • Temperate = 4 syllables

If the word ended in an e (and later I discovered that provided it didn’t end in le) then there was one fewer syllable than I had originally thought, so I simply adapted the program to subtract one at the end if appropriate, as well as handling plural words to (so compares has the s stripped off and e is considered its last letter).

-e wasn’t the only suffix that I’ve had problems with; -ing causes similar problems. For example, according to the current version walking has two syllables whereas going or flying have only one. Thankfully the rule for fixing this is relatively simple: if the word ends in -ing (or -ings) and the letter immediately before that is a vowel then one syllable should be added. I final suffix that causes problems in a similar fashion (there are others, I won’t discuss them all here) is -ed because happened only has two syllables but the program estimates 3. Despite this, fainted does have two syllables which are correctly found. Therefore I have to examine whether or not there is a proceeding t or d and if there is not then remove a syllable.

So how accurate is the algorithm in its current state? Let’s compare the lines of the sonnet again:

  • Shall I compare thee to a summer’s day? = 10
  • Thou art more lovely and more temperate = 10
  • Rough winds do shake the darling buds of may = 10
  • And summer’s lease hath all to short a date = 10

OK, this is a pretty significant improvement but the algorithm is still far from perfect. For example, taking the first sentence of this post incorrectly identifies didn’t as having only one syllable and languages as having only two, however gets everything else correct.

In my case I did not want to write a 100% accurate algorithm and I believe to do so would probably require a great number of defined ‘special cases’ that would lead to the algorithm becoming bloated, which is a shame because it currently occupies just over 20 lines of C# code.

This algorithm is suited to counting syllables however it is not yet capable of finding syllables. In some cases people may pronounce a word differently (such as long-er and lon-ger) and in some cases it is not clear which letter starts and ends a syllable. Furthermore, language (common use English especially) is slowly devolving towards using fewer syllables in words – missing out the letter t (a pet hate) significantly reduces the number of syllables in one’s speech.

You can check out the source code on GitHub.

The increasing irrelevance of the iPod Touch

The iPod Touch has come a long way since the first iteration in 2007 and has generally been accepted as a low-cost alternative to the iPhone with the only major sacrifices being a slightly worse camera and no cellular in the current generation. Steve Jobs even referred to the iPod Touch as ‘training wheels for the iPhone’.

I’m moderately amused by the low cost iPhone/iPhone Mini rumors that have been emerging on the web over the last few months. The general consensus seems to be that it will cost about half the price of an iPhone, with possibly the same 4-inch screen. So basically it’s an iPod Touch with an extra radio.

I’m worried, however, that the iPod Touch is becoming irrelevant:

  • It no longer competes with low-cost (and premium devices such as the Nexus 4) Android devices in exactly the same price range
  • It isn’t as affordable as it once was. The 8GB iPod Touch 4G was the entry level device at $199, however the current 32GB ‘entry level’ fifth generation iPod Touch is $299. Despite this, the move to 32GB as a minimum is a lot more sensible
  • It doesn’t fit into the iOS ecosystem as well. The iPad Mini, a device that is equally fast, has half the storage and a screen three times bigger is only $30 more. People will be more tempted to spend $329 on a tablet and use a lower end Android phone as their music device than to buy a $299 MP3 player

If Apple do release a low cost iPhone Mini (which I see as unlikely, but I’m probably wrong) it will kill the iPod Touch. The odd thing about the iPhone Mini is that the iPod Touch is a premium portable media device, and an iPhone Mini would not be a premium smartphone because the price is too low. Android was the iPod Touch’s first nail in the coffin, the iPad Mini was the second and the iPhone Mini will be the third.

Android on the desktop

Over the past year or so there has been a great deal of speculation online over whether or not Google will bring Android to the desktop. I personally don’t think that Google will do it1. I decided that I would have a play around with the Android-x86 project last weekend to see what it is like and whether or not one could use it as a full time desktop environment. My logic was that people use tablets as their primary computer, so Android 4 should be usable as desktop OS too.

Installation and booting

I decided to try out two Android versions; Android 4 (a stable release on Android-x86, originally released by Google in December ’11) and Android 4.2 (still in development, Google released it in November ’12). I was impressed by the small download size (300MB each). I installed both of them by booting from a memory stick, and the installation for both only took a few minutes (the Android x86 guys seem to have done a good job with installation and drivers). From there on you set it up like a regular Android tablet2, logging into WiFi, setting locale and most interestingly logging into your Google account.

Applications

Both versions had full access to the Gmail app and Google Play, which I was very surprised by. Unfortunately Android-x86 doesn’t include Chrome, but the stock browser was actually quite a bit better3. I had a go at installing Chrome, but I got a message in Google Play that told me ‘this app isn’t compatible with your device’. I managed to get Google Drive on Android 4 but not on Jelly Bean.

The main problem with apps at the moment is the fact that the vast majority of apps are designed to run on ARM devices rather than Intel devices. Intel devices get round this by using a bunch of libraries (which can be installed in Android-x86 but I failed completely at doing so) to emulate ARM. This makes it very difficult to install games on Android-x86 unless you install the ARM emulation stuff. If you do get it working, you can play games like Angry Birds.

Oddly I couldn’t install apps at all in the Android 4.2 installation. This is probably because it’s using development keys because it isn’t a stable release yet, but I should imagine it was probably me doing something wrong.

Performance

It’s actually really fast. Boot times were generally sub-30 seconds on a netbook and application switching (in Jelly Bean especially) was very quick. Web browsing was comparable to using a regular Linux distro with Firefox or Chrome installed. I disliked, however, the lack of screen space visible for the web page because you have the black bar across the bottom and the notifcation bar across the top, along with action bars and any other chrome an app may have.

The general speed is probably a credit to where Android has come from; it was designed originally to run on smartphones with less than 128MB of RAM, whereas modern OSes often require at least 2GB.

General experience

Aside from a limited range of apps (or at least limited on my machine) it actually proved to be a pretty good desktop OS. I wouldn’t use it as a full time OS because I spend most of my time using a keyboard rather than a mouse, which Android-x86 is designed to be used with. Android is still a touch OS, so no usual desktop shortcuts work, which is a shame.

Another slightly odd problem I had was the lack of a shutdown option in Android 4 (since added in Jelly Bean) although you can install an app (originally designed for rooted devices) that will shutdown for you.

If you are planning on playing around with Android on your computer it is probably worth noting that Android-x86’s Android 4.0 builds are a lot more stable than the 4.2 build, which will probably be worth getting after it has come out of development.

Conclusion

In general Android-x86 is a very functional, lightweight desktop OS. It’s good if you want to browse the web, do email and read books (the Kindle app isn’t great in landscape though), but not so good if you want to code, play games or do other intensive tasks. The main disadvantage it has is that Android is a touch OS, and Android-x86 hasn’t quite made it a desktop OS. Google’s alternative offering, Chrome OS, does all of these things better and it is designed as a desktop OS rather than a tablet OS. It’s the same reason that it doesn’t make sense to have the same OS on your 27″ desktop as your 10″ tablet (*cough* Windows 8 *cough*). A real benefit is for developers because you can debug apps via VirtualBox, although the latest emulator with the Intel image is actually pretty good.

Ultimately I don’t think that Google will bring Android to the desktop because it isn’t what they are aiming Android at. I can see Chrome OS coming to mobile (because it is such a lightweight OS as it is) on the other hand so it can compete with Firefox OS.

You can use Android on your computer now, but that doesn’t mean you should.

  1. Probably worth noting the difference between an Intel version of Android and Android on the desktop. Google and Intel have both worked on porting Android to Intel smartphones, however the Android-x86 has further adapted it so that you can install it on a desktop PC.
  2. I was a little annoyed that my *computer* was referred to as a tablet throguhout the installation process. I assume Android has a string somewhere for ‘tablet’ or ‘phone’ but it would have been nice to see ‘computer’
  3. Whilst Chrome is a very good browser on mobile and desktop, stats show that the stock Android browser is actually faster

A week without Flash

Last week I decided to disable Flash in Google Chrome for performance reasons. I was aware that there would be some web content that I couldn’t view because it relies on Flash for video, but I really didn’t find it to be a problem. Either most sites have been proactive at switching to HTML5 for video (which I found to be much smoother) or just rely on YouTube, which automatically switches to HTML5 because I’m in the HTML5 trial.

I last tried this about a year ago, however then it was impractical because a lot more video relied on Flash, but now I can’t really see the point in enabling it again.