Yet Another Update on imgAreaSelect (and the Horrors of Mobile Web Development)

It has been a while since I posted an update about the development of the new version of imgAreaSelect… so here’s an update about the development of the new version of imgAreaSelect.

I am working on the project in my spare time, which is unfortunately an extremely rare commodity for me these days (the joys of running a company), so progress is rather slow. However, over the last few weeks I did manage to fix a couple outstanding issues, and I feel the code is now much closer to my next goal, which is a release candidate for version 1.0.

I must also say I never expected it to be this complicated to make the plugin compatible with mobile browsers — while it did require a few modifications to the basic code of the plugin, other than that it was mostly a matter of adding support for touch events. In reality, it turned out developing and testing a JavaScript UI component for mobile browsers is blood, sweat, and tears.

Maybe you’ve seen this picture, it popped up on my Google Plus feed a few days ago:

You might think, surely it can’t be that bad, it’s not that you have to own every single one of these devices, right? After all, there are simulators and stuff and you can do all the testing from the comfort of your desktop, can’t you?

Well, based on my experiences so far, maybe it’s not that bad, but it’s bad. For reliable results, you do have to test on real devices. While the iOS simulator that comes with the Xcode suite appears to be good enough for mobile web apps testing, the Android virtual device is useless. Its performance is a joke and makes it impossible to work with anything that requires UI responsiveness (such as my precious plugin). So, I’m testing with two real Android devices, one running version 2.2 and another running 4.2, and I hope the results are representative enough to generalize towards the overall population of Android devices out there.

In addition to that, mobile browser debugging tools are still immature. For the Android version of Chrome, there is a very good remote debugging utility, but no such thing exists for the default Android browser distributed with the system (or at least I’m not aware of such a thing). And although the two browsers should be pretty similar engine-wise (as they both use WebKit and are both made by Google), in my tests I did come across a bug that only manifested itself in the default browser and not in Chrome, and so was hard to track down.

I have also experienced funny things like bugs mysteriously disappearing without any changes to the code (and re-appearing later, naturally), strange HTML positioning problems, etc. At one point, when I was trying to reproduce some weird issue, repeatedly hitting that small screen and inventing brand new profanities, I realized that the last time I felt this level of frustration was in the dark ages of IE6. Yes, I mean it — mobile web development can be a horror comparable to dealing with IE6.


Sorry for the amount of whining in this post, I think I just had to vent. I survived IE6, so I’m not going to give up now, either. That release candidate is coming, I will keep you posted.

Leave a Reply