iPhone medical apps can be improved by Google Android

by Felasfa Wodajo, MD

In a recent post, entitled, Why doctors should choose Google Android over the iPhone for medical apps, the author seems to have gone out out of his way to make a series of increasingly hyperbolic arguments declaring Motorola Droid superior to the iPhone.

The long trail of negative comments on the site demonstrate that perhaps not all readers were swayed by his arguments. This post is an attempt to clarify or rebut some of the points made in that post. I will not address every issue, as there are too many. I will try to maintain a tone of neutrality, at least until towards the end.

As a preliminary, I would note that the author mixes features of the Android operating system and the Motorola Droid throughout his post. Of course, the two are separate and other handsets that utilize the Android operating system will have different hardware features (CPU, screen, connectors, keyboard, etc). To the casual reader, however, this muddling is a disservice. The iPhone, in contrast, is a single operating system running on a single hardware device. Therefore, its features are predictable, both to the user and to the developer.

On the hardware front, the writer comments on the availability on the Droid of a mini USB connector, saying “[f]or medical device connections, the USB is a necessary standard”, in contrast to the iPhone which uses a 30 pin connector. This was unclear – necessary for what? I cannot remember any “medical” device that I wished would connect to my iPhone. Mind you, USB connectivity is already available within the 30 pin iPhone connector. That is how you connect with the computer, for example. The additional pins simply allow for much richer communication, which will allow for future innovations in device control, now that Apple has opened this interface to developers.

Next, the writer states “The iPhone currently has no facility to get app data off of the phone except for email which is not acceptable for transferring sensitive data”. The author undoubtedly has used wireless (wifi) networking to sync his iPhone with desktop applications and web services, as he presumably will with the Droid. I am unclear how this obvious point was left out. Of course, the fundamental breakthrough of the iPhone and related smart phones is the combination of installable applications and the always-on connectivity of a cellular network. The idea that the Droid’s micro SD slot is a major advantage in transferring data seems to be a bit backward-looking. I don’t even take the card out of my camera to transfer images, I just plug it into the computer.

Perhaps the most important problem with the post is the statement that the Android operating system is “… far superior to the iPhone OS for enterprise software, mainly because it can run more than on application at a time.” Of course the iPhone can run more than one application at a time, in fact the iPhone operating system is identical in many respects to operating system of Apple’s powerful desktop Macintosh computers. Every iPhone user runs more than one application at a time when they listen to music while surfing the internet or when they receive mail and SMS messages while the phone is “sleeping”.

Apple simply made an overt design decision not to allow third party developers to have the option of having their applications run in the background. This was done expressly in order to preserve battery life and can be reversed by Apple at any time. Until there is a big breakthrough in battery technology, however, this protects users from having a poorly designed application quietly drain the battery in 3 or 4 hours. This might have been a minor inconvenience in the past, but at this point, losing access to your smartphone by mid-morning could have significant implications for your ability to care for patients.

The author goes on to clarify this “issue” with a hypothetical vignette of how an iPhone and an Android phone would handle a “simple problem.” In this example, a doctor receives a phone call while “reviewing a Chart on their phone via a Chart app”. On Android, he says the app would be suspended while talking, allowing the doctor to resume when they are finished, whereas on the iPhone, the chart app would have to be reopened after finishing talking. The implication is that the doctor would waste time “reopening” the chart app on the iPhone versus “resuming” on the Android phone.

This supposition is not necessarily correct as I will explain shortly. However the next statement by the author was overtly false and needs to be exposed: “If the doctor wants to see the chart during the call, he/she will have to hangup the call and reopen the Chart app.” As any user of an iPhone knows (including, presumably the author who states he owns one), the phone application runs in the background and any other application can run or be launched while talking on the phone. The doctor does NOT have to hang up the call to launch another application.

As for application suspension versus restarting, a well designed iPhone application, per Apple, should remember exactly where the user left off when they last quit. Apple’s design philosophy, which rings true, is that mobile devices like the iPhone are different from desktop computers in that they are typically used in brief bursts, often while on the go. A user will take out their iPhone, check one or two things, then put the phone away. Therefore, a well designed application should always launch exactly where it last left. This is evident, for example, in the iPhone mail application. If one leaves while in the midst of typing an email and then returns, the previously typed text and scroll position will be precisely restored. Therefore, by virtue of careful application design, very few iPhone owners are even aware that only one third party application is allowed to run at a time.

I will discuss two last items from the post. The author makes the predictable point that the iPhone does not have a physical keyboard, stating the Droid “… has a real keyboard which most professionals prefer”. Without entering into the particulars of this worn debate, I would start with the question of what is the device predominantly being used for ? Meaning, if the predominant usage involves typing, then this feature might indeed be important for the user. However, I would posit that if a mobile medical application requires a large amount of text entry, then the application design ought be reconsidered to be realigned closer to the way small hand-held devices are most commonly used.

Lastly, the author enters into a somewhat technical realm by describing memory management on the two operating systems, noting that the iPhone OS uses manual “retain & release” while the Android employs automatic “garbage collection”. In fact, Apple made the conscious decision not to add “garbage collection” to their mobile operating system in order to extend battery life, not due to an oversight.

This distinction in memory management is important to application developers but, of course, users are blissfully unaware of it. And, there it might have stayed, but the author found it necessary to continue and add that, if memory management is “left in the hands of the programmer,” and the programmer makes a mistake, then “the program will eventually run out of memory and quit.”

Is this statement really necessary ? To be clear, developing applications on any mobile device will always involve making critical decisions on the use of limited resources including screen space, battery consumption and device memory. Any medical application must and will be carefully tested before releasing, and applications can crash for numerous reasons besides faulty memory management.

Aside from being an unnecessary swipe at skills of legions programmers, this comment is a classic example “FUD”, i.e. using technical sounding arguments to spread fear, uncertainty and doubt. It is typically employed by those who should know better.

Perhaps one can argue that screamers such as “Android is a feature rich OS with the power for the programmers to write very sophisticated medical software. The iPhone OS was built as an entertainment platform” drain enough credibility from the author that the reasoned rebuttal is not needed. However, I felt compelled at least to attempt to combat some of the obfuscation wrought by the author, on behalf of the non-technical reader.

I will close by stating that the continued success of Google’s Android operating system is a great boon to consumers and specifically to the iPhone platform, as it will stimulate Apple to innovate. In reality, the platforms that stand to lose the most share in the foreseeable future as a result of Android’s success will be the Symbian and Windows Mobile platforms, not the iPhone. I look forward to yet another flowering of innovation and medical applications on the Android platform.

Felasfa Wodajo is a writer at iMedicalApps.com and blogs at a few thoughts from a tumor surgeon.

Submit a guest post and be heard.

Similar Posts:

• Google Android versus the iPhone for medical apps
• Android and iPhone pros and cons for healthcare
• What doctors need to know about Google Android and Nexus One

Tagged as: Health IT, Patient, Primary care, Specialist