NextVTA Updated – 1.3.1

I updated the NextVTA Android application to version 1.3.1. I made several improvements were made to clean up the user interface and increase usability,

• added icons to indicate the route type (bus, light rail)
• added route type filter to hide or show only certain route types
• added route description (major start and end points)

Also note that the routes list now shows the route number only. The choice of direction (north, east, etc.) and period (weekdays, saturdays, etc.) are moved to the route view page. This makes the route list easier to navigate as there are fewer entries. The period is auto-selected based on the current day of week.

NextVTA

I just published my first Android application to the Android Market: NextVTA. Very simple app that allows to you select a Santa Clara Valley Transportation Authority bus or light rail route and then with one click see the next scheduled bus or train for the selected time point. It can also be used as a browser for all VTA schedules. The app requires no network access; all schedules are bundled in the application.

It doesn’t do any location-based searching. That would be nice, but I suppose I’d have to get access to the latitude and longitude of all VTA time points. I don’t see that happening.

I may enhance it a little in the future, to be able to search for routes, and to move the selection of route direction (northbound, eastbound, etc,) and period (weekdays, saturdays, etc.) from the route list to the route view, to shorten the list of routes and make it easier to scroll through to find what want.

Nothing more than a learning exercise.

HTC Dream+Android (1.5) and the Motorola S9 Bluetooth Headset

I had two reasons for picking up a bluetooth headset. First, I am really, very sick of wires dangling around me and getting caught on things and pulling my headphones out of my ear. Second, because of the HTC Dream’s combo charge / headset USB port, I cannot charge and listen to music at the same time.

Setup was painful. After some combination of pairing and re-pairing, connecting and disconnecting, disabling and enabling bluetooth, and rebooting I finally managed to get a stable setup. I won’t detail the problems, but suffice it to say there are many accounts of this headset working, and also not working. I figure I got lucky with the right sequence of events.

Now when I turn on the headset, it connects … in about a minute. That is annoying in itself, but read on. There’s a nice hiss in the earphones when you are connected. This is acceptable for phone audio but not for music. Worst of all, the headset needs to be very close to the phone. Close, meaning 12″ or less. At ~18″ I get about 20% loss of audio. When the phone is on my belt, I get about 60% loss. By loss I mean the audio cuts in and out.

As I mentioned earlier, I thought this device would allow me to listen to music while charging the battery on the Dream (after all, I need to be constantly charging the thing). I was very surprised to see the battery actually drains when it’s charging, when USB is active. Apparently USB draws so much current the little charger can’t keep up.

The above pretty much makes this combination of headset and device pointless, but there’s a few more things I want to say about the headset alone. I have not short hair, and it’s impossible to get the device on without pulling my hair and having hair matted between the earphones and my ear. The headset it quite uncomfortable. The earphones don’t fit into my ear canal (are they supposed to?) and they push against my ear painfully. and, because they don’t fit into my ear, the volume and sound response is unacceptable.

Stereo USB headsets just aren’t there yet. They can’t match the sound quality, ergonomics, or plain simplicity of wired headphones.

Why Android Swap Doesn’t Make Sense

Reading through forums about to to tweak and increase performance, one of the items I found was enabling a swap partition, or file. Maybe an expert can correct me, but I don’t understand how this could possibly help, and probably hurts.

Unix swap, and virtual memory in general, allows physical memory to be extended. A section of the disk is turned into what is essentially very slow memory. When the system starts to run low on memory, the OS moves inactive processes into virtual memory to make space for new or active processes. This works well in general as there are usually a large number of background processes that are idle for long periods of time. If the processes aren’t active, it doesn’t matter if the memory in which they reside is slow.

Android, while a fairly typical (but trim) Linux under the covers, has it’s own mechanism for handling low memory conditions. It terminates the application, but first gives it an opportunity to persist it’s state (via a series of callbacks). For example, a map application might persist a latitude and longitude before it is terminated. When you access the application again,  the location is passed back so it appears that the app was running all along. In actuality the app was restarted completely.

Both swap, and Android’s native application swapping mechanism do the same thing, at a high level anyway: they move inactive processes out of physical memory free up space for those that are active. However, which does it more efficiently?

1. An Android swap partition must live on your SD card. SD cards are very, very slow memory. They are 100 to 1000x slower than a SIM. They are   10 to 100x slower than a hard drive. They are marginally faster than a network connection. When an application is “swapped out” it is copied into this very slow memory, and copied back to physical memory when it needs to run. On the other hand, when an app needs to be restarted after being terminated by Android, it is loaded not from the SD card but from the device’s (relatively) fast physical memory.
2. When an Android app is terminated because of low memory, it decides what information must be persisted to represent it’s state. This can be very, very small. For example, it might be an integer index into a database. When an app is moved into virtual memory, the OS has no idea what’s important. It just moves the application in whole. It can’t be smart about it.
3. Having swap actually prevents the native Android memory management scheme from activating. The system sees memory and doesn’t distinguish between physical and virtual. It will therefore prefer swap over the native Android memory management scheme, and won’t activate the native scheme until swap is full.
4. Having swap requires some overhead of system resources.

And here’s a few counter arguments that I can imagine,

1. The native Android memory management scheme is there for apps, but not for other processes. That is, having swap allows the many processes that run to support the Linux operating system to be moved out of physical memory.
2. If you are running AppToSD, point #1 is negated as in that case the apps are being loaded from the SD card not physical memory.
3. ?

Android and the AppsToSD Mistake

The HTC Dream, and Magic to some degree have a fatal flaw- their lack of internal memory. There’s actually three memory types to consider with these devices: internal ROM,  internal RAM, and removable. ROM is where the OS runs, RAM is where applications and their data lives, and the removable media is resigned to storing pictures, music, video, etc. As long as the OS fits in the ROM, there’s no issue there … and with SDHC cards up to 16GB you probably will not run out of space for your media files. The problem is RAM.

Adding applications eats up the internal RAM. The number of applications you can therefore add to the phone is finite, and quite limiting. And hey, that’s the fun thing about these devices- exploring the wide variety of interesting applications.

Before someone jumps down my throat, yes I am aware that there are hacks to allow Android to store apps on the SD card (known as “appstosd”). I’m running it now in fact. There’s one small problem to this that no one seems to bring up: memory speed.

Let’s consider some various transfer speeds to get a frame of reference. A slow hard drive can transfer at 100MBps (mega bytes per second). USB 2.0 can transfer at around 40MBs. An average RAM transfer speed might be 1000MBps.

Now consider the transfer speed of an SDHC card. If you look closely, these cards are designated with a class: either 2, 4, 6, and now sometimes 8. This is the transfer rate, in MBps. See the problem? Running appstosd on Android is using an extremely slow media in place of what is typically the very fastest media.

This is why the iPhone doesn’t use a removable media for app / data storage. It uses a SIM memory chip for fast access. This is why the iPhone is lightning fast when loading apps and data.

Android vs. iPhone OS

I’m a little late on this review, but I thought I’d post me thoughts anyway.

At the macro feature level, it’s a toss up. There are minor aspects that are missing from one or the other, or just different, but at a high level it’s 90% feature overlap. This would be a boring blog entry if I left it at that though. Let me point out a few notable differences …

Form Factor / Size

Android is of course just the operating system, but I thought I’d quickly compare the iPhone  against the two released Android hardware platforms: the HTC Dream and the HTC Magic. The iPhone feels as if it’s higher quality. Both HTCs feel like typical not-built-to-last cell phones. I can’t speak for the actual longevity of any of the devices, this is just my feeling.

The iPhone makes maximum use of it’s size; the screen encompasses almost the entire front of the unit. The Dream has a smaller screen that doesn’t expand to the edges of the unit like the iPhone. The Dream and Magic’s screens occasionally feel too small, which is something I never experienced with the iPhone. Indeed, the HTC models sport a 3.2″ vs. the iPhone’s 3.5″.

The iPhone feels almost as if it’s the optimal length and width. Anything less would make the screen feel too small. Any less thickness would make me feel like the unit wasn’t structurally sound. The HTC Dream feels thicker and bulkier than it should. This is at least partly due to it’s slide out hard keyboard. The Magic comes closer to the iPhone but still falls short.

If the HTC hardware really turns you off, just hang in there. While the choices are limited now, the near future will see an explosion of devices running Android.

Background Applications

This was sounding quite one-sided, up until now.

The iPhone has limited ability to run applications in the background. For example, you are running Pandora. Now you switch to check an email. Pandora stops playing. Another good example is a GPS run tracker application that records speed and routes. It works fine as long as it’s in the foreground, but if you switch out to play some music, it stops recording.

Actually, a certain, limited set of iPhone app are allowed to run in the background. These include but are not limited to: music player. AIM, and mail (the new mail checker part anyway). However, in general, 3rd party apps are not allowed to partake.

Conversely, Android is quite advanced in this regard. Any app will run in the background. It’s just part of how the operating system runs and requires nothing special from the application itself. Whether it’s a GPS tracking application, streaming music, or whatever, they just continue to work as you go about and perform other tasks on the phone.

From a developer’s perspective I can understand the limitation on the iPhone. As soon as you allow apps to execute in parallel, you have to consider memory limitations, battery consumption, access to shared resources, etc. All in all a much harder problem.

I think, many of iPhone users won’t notice or care about this limitation. They get new email notifications, and their music plays in the background. That being said, there are complaints from the iPhone community about this limitation. Time will tell if Apple responds.

Applications

Both the iPhone and Android have an extensive set of robust quality applications available through their respective store fronts. In general, the iPhone has more, and better applications available, but the average user will be able to find what they need in either place.

Keyboards

The iPhone’s on screen keyboard works better. Part of this has to do with the larger screen size with the iPhone vs. the HTC hardware. Larger screen size means bigger buttons and less fat fingering.  The HTC dream has a fold out hard keyboard. It’s hard keyboard for heavy duty / soft keyboard for quick and dirty typing is an excellent combo. The Dream wins overall. The HTC Magic of course has no hard keyboard. Android’s soft keyboard is usable, but inferior.

The downside of a hard keyboard is that it’s mechanical, and like any mechanical device is prone to failure based on the amount of use. No specifics here, just my opinion.

Touch Screen Ergonomics

The iPhone’s touch screen is ultra responsive with no noticeable delay. Excellent overall. Android’s is not as good. There’s a slight but apparent delay between touching and when the OS reacts. Also, it is sometimes difficult to click onto things at the screen edge. Touch screen gestures in Android feel clunky. For example, a “flick” is at best jerky and sometimes doesn’t animate at all, just jumping directly to the end point. It feels as is the HTC hardware is under powered.

Widgets

Android Home Screen with Weather Widget

In Android, a widget is a mini app that can run on your home screen. The closest analog is an OSX widget. On the iPhone, it would be as if the application icons could change and display information dynamically without the app being started. Of course the iPhone has no concept of a widget. Some of the app icons do update, but this is reserved for system apps like mail.

This is a very handy feature. From my home Android home screen, I can see the current weather, new messages, clock of my choosing, etc. without having to run the respective applications.

Notifications

In Android, the notification bar is always at the top of the screen. It shows small icons indicating the presence of certain types of notifications, and the bar and be pulled down to show them in detail, and allow direct access to the source of the notification with a click. The iPhone has no official notification mechanism. Some things like mail, IM, and messaging generate an audio notification, or even a popup modal dialog, but few apps make use of this. Moreover, the problem with the modal dialog is that it interrupts whatever you are doing and forces you to take action immediately.

Screen Orientation

There are a few things that really annoy me with regard to how the iPhone handles screen orientation. The first is that it sometimes gets stuck. This seems to happen when the orientation changes while the phone is locked. I notice is a lot with the music player. When I unlock, it’s in the wrong orientation until I flip it back the other way, then back to where I want it.

Second is that it’s not available on all apps. Some apps handle the change, others do nothing, and there’s no way to tell except memorizing how each app will react. In Android, all apps react to the change. Well, more precisely, the OS reacts by modifying the screen resolution and orientation. This is really all I want – adjust screen real estate in the X or Y direction. My reverse engineering of how this works is that on the iPhone, the app receives an event and is given the option of reacting to it. If the app doesn’t re-draw itself according to the new orientation, nothing happens. In Android, the OS revises the X and Y size of the screen, and re-paints the app. As long as the app has laid itself out with proper gravities and fills it will do the right thing.

My third point is how the stock iPhone apps react. Some apps like mail, compose do what you’d expect … give more space for the soft keyboard and more horizontal space to enter the message. Other apps like the music player arbitrarily change their behavior. The portrait mode for music player is the typical music player controls, well done. Landscape mode is the proverbial horizontal album art stack view, which is nice eye candy but really pointless for every day use.

The Cloud

Android is tightly coupled to your Google data. That’s an understatement. It won’t work without a Google login. If you have taken Google’s red pill, this is a very good thing. One login gets you your contacts, mail, calendar, photos, videos, and on and on. And better yet, all this data is in Google’s cloud. There’s no need to manage the data locally: keep it backed up, synchronize, etc. If you haven’t taken the red pill, things are not so rosy. Integration into other systems like Exchange, Lotus, etc are spotty at best. I have no direct experience with this so my comment is just based on comments I’ve seen floating in the ether.

iPhone on the other hand by default synchronizes to your local system via iTunes. There is MobileMe, which is Apple’s cloud offering, but it’s a pay service ($99 / year) and it has data transfer / size limits. The iPhone can work with the major Google services, but it’s tedious process of configuring each one.

Music Player

As a music player, both the iPhone and Android perform. The iPhone is excellent: the iPod you know and love that was once a dedicated device is now encapsulated as one of many applications on the iPhone. Android’s stock music player is basic but satisfactory.

It’s a shock to not be tied to the iTunes hegemony, but I prefer it. On Android, you just mount your SD card and drag your music onto it.

The main problem is the HTC’s lack of a 3.5mm audio port. At first I didn’t think this would be an issue. Purchase a $5 USB to be 3.5mm adapter. However, the first problem was that the only adapter I could find locally was 3′ long. Combined with my headphones I ended up with 7′ of cabling hanging off my belt and getting caught on everything. I since ordered a shorter adapter online.

Consider the battery life of smart phones, my typical day is to sit down at my desk and listen while charging. What I didn’t consider is that the HTC’s multi-purpose charge and headphone port doesn’t allow this. There are adapters that split the HTC’s port into audio and charge, but they are reported not to work with the latest Android release (!). I don’t have a solution to this yet.

Summary

Overall, the iPhone wins. Android and it’s hardware platforms are definitely rough around the edges and pale in comparison to the iPhone’s polished hardware and software. I feel Android has the potential though, in that it’s doing a lot of things correctly from the start.