First thoughts on the Nexus 7

I got a Nexus 7 for Christmas. This was something I’ve been thinking about for a while – I wanted to see what the state of the art of Android was, and maybe start developing some apps for it. I haven’t done any benchmarking or measurements, this is just my subjective experiences and some comparisons with my iPad 3.

First off, appearance.

It doesn’t feel as well made as the iPad, and the plastic back makes it seem cheaper. I haven’t checked the specs, but it also feels thicker. I’m told it’s half the weight, but if you asked me I’d say it was nearly as heavy – maybe it’s just denser or something. However, the device is a very nice size. You can hold it in the palm of your hand with your fingers on both sides of the screen, as opposed to the iPad which you hold from one edge. It feels like a very good size for portability. It fits in your hand nicely, and it even fits in the back pocket of your jeans (just make sure you don’t sit on it). The screen isn’t as beautiful as the retina display on the iPad, but it seems good enough for watching movies and web browsing. Both devices have adequate battery life, and I don’t have to slavishly remember to plug them in every night like I had to with older generation cell phones, which is all I really care about. Which one has 9 hours of battery life and which one has 10 hasn’t really made an impact on my life yet.

Secondly, user experience.

If you just care about getting stuff done, I can see the appeal. I turned it on, put in my Google credentials, and just about everything set itself up. I didn’t have to set up or re-log in to Gmail, YouTube, Google Plus, Calendar, Google Play, etc. It all just worked. That was pretty cool. I’ve had no need or desire to connect it to another computer.

On the other hand, the default widget set, which are used by lot of the apps including Google’s own apps, are ugly as sin – flat, boxy, unshaded, untextured, visually unappealing. I’d say whoever designed them has spent way too much time using the Xt X Toolkits Intrinsics widgets on Unix, and that’s probably showing my age. There is also a lot of inconsistency – for instance, it was sometimes a bit of a hunt to figure out how to refresh a screen in different apps – sometimes it was the “getting more common all the time” pull the screen down and release it, sometimes it was a circle icon in the middle of a bunch of other icons near the top, and sometimes it was something completely different. Unlike iOS, where if you’ve got a small popup on top of a bigger display, tapping outside the popup will dismiss it, in Android apps you often have to use the “Back” button on the bottom of the screen.

On the other hand, the fact that the “Back” button works across different apps is the most awesome thing ever. I wish iOS has something similar. In iOS, if you’re in one app and you tap something that opens a web page in Safari, it’s a pain in the ass to get back to the original app – I think that’s why so many apps open web pages in their own UIWebViews. In Android, you just click the “Back” softkey and you’re back in the original app – and it even takes care of closing the tab in Chrome that it opened. Very cool. And it appears to chain across multiple apps as well. To me, that’s a good reflection of the Unix philosophy – if you make it easy to get stuff from one app to another, you don’t have to make one app do everything.

Another indication of the Unix design philosophy is that appears that there is less sandboxing between the apps, and so, for instance, Dropbox can see all the files on the device. If you click “Upload Here” you can see the equivalent of a $HOME directory and all the files below it. And your ebook reader app can read books directly out of your Dropbox. I can see the advantages of this, but I can also see the drawbacks of it. I think it was Dennis Ritchie who said that “Unix doesn’t prevent you from doing something stupid, because that would also prevent me from doing something amazing”. I wonder what Android does to prevent these apps that have access to each other’s data from modifying each other’s data, or from stealing information they shouldn’t be seeing. I guess that’s a question I’ll have to answer when I start doing some Android app programming.

Update: I forgot to mention this when I first posted this, but there are a couple more things I really like about Android. The first of these is the menu that comes up when you swipe down from the top right corner. It puts a couple of things that I need to access far too frequently, like wifi settings and airplane mode, way more handy and accessible than they are on iOS. The notifications (accessible from the top left corner) are also, I believe, somewhat better than iOS. As a matter of fact, they’re almost as good as the notifications on WebOS, which I think are still the best I’ve ever seen. I also like the way the keyboard has that built-in “Swype-style” thing, although I suspect that’s more of a gimmick than a really useful feature. I also like the way it shows a couple of autocorrect choices. Too bad it (the keyboard, I mean) looks so damn ugly.

Houston, We Have A Problem

In the two weeks that I’ve had this device, I’ve had one minor freeze-up (where everything stopped working, including the off button and the volume buttons) for 30 seconds or a minute and then it started working again, and one major freeze-up (where everything stopped working, including the off button and the volume buttons) for several minutes until I could walk up stairs to another computer and Google how to do a hard power off. Both times it happened, I was using the Facebook app. To me that’s a major red flag – an application should not be able to make the OS unresponsive, no matter how badly written. (And my experience with the Facebook iOS app and the Facebook web page is that Facebook stuff is *very* badly written.) I’ve had a few app freeze-ups with iOS, and I can recall using the hard power off a time or two, although as far as I can recall it was when I was moving from one wifi network to another (a constant problem in this old plaster and lath house), which iOS has had problems with in the past. I wasn’t doing anything of the sort when Android froze up – just sitting still putzing around on an app.

Where am I going with this?

Well, my overall impression is that for things where functionality is more important than a beautiful user experience (like a phone), I could easily transition to Android and I’ll certainly look at both Android and iPhone when my next contract renewal comes along. I’ve often wished my iPhone had a bigger screen like a Galaxy Note II. On the other hand, for day to day tablet use, I think I prefer the user experience and beauty of the iPad.

As a long time Java developer, I’d like to try my hand at Android development. I worry about the lack of compatibility between different Android platforms and I’ve heard that professional Android development shops will have dozens if not hundreds of Android devices to test against. On the other hand, I have a feeling that the future of app development is exactly where Steve Jobs said it was when the iPhone first came out – HTML5 and Javascript, with whatever you want on the server side.

I’ve seen people using a Nexus 7 as a navigator in their cars. I’d love to replace the piece of shit navigation system that’s built into my car, but to use a Nexus 7 I’d either need to tether my phone or get a Nexus 7 with 3G. Either is probably more money than I need to spend. I think I’ll stick to the Garmin app on my iPhone.

Let’s get realistic here for a moment.

The fact of the matter is that my shoulder is not getting better. My pain level is actually worse than it was before my first surgery, and has not been getting any better for two years. Basically every time I do my physiotherapy exercises, which I’m supposed to do every other day, I’m in pain for 3 or 4 days afterwards so they don’t get done as often as they should.

So barring some miracle happening in the next couple of months, I’m facing either not kayaking, or kayaking in pain. Judging by the way it’s gone in the past when I’ve tried to continue a sport with pain, if I’m really lucky I’ll get maybe one year to recover my fitness, and another year to race, and then the pain will be too great to continue – if I’m unlucky I’ll wimp out of the pain in March, sell all my boats and go back to being a limpet. So I guess the realistic thing to do is to prepare myself to train and race in pain, and hope for a miracle. And the best training for training in pain is to start doing my physiotherapy exercises in spite of the pain that they cause me. Who knows, maybe they’ll actually start doing me some good?

Design iteration

I have a web page that shows a bunch of data (trouble tickets) on different tabs.

In the first iteration, I was doing a ton of queries at load time, and building up the content of each tab using Perl Mason. Tabs that had no data on them were not even created on the page. There were three problems with this:

  1. It took a while to load the page
  2. Any time you did anything that would change the tickets that are on the page (like resolve or reassign one of them), I’d have to totally reload the page.
  3. You’d probably have to occasionally reload the page to see if anybody else had done anything that would cause more or fewer tickets to appear on one of your tabs.

In the second iteration, I changed it so each tab would only load itself when you clicked on it by making an AJAX call. This did wonders for the speed of the initial page load, you’d see the latest and greatest information on the tab when you clicked on it, and if you resolved or reassigned one, it would repopulate just that one tab. As an added bonus, I added paging and sorting to each tab. I was happy about the paging and sorting. The biggest problem is that I couldn’t hide the tabs with nothing in them, because I didn’t know there was nothing in them until you clicked on them. I didn’t like that.

In the third iteration, I added an argument to the AJAX call that would allow it to just return the count of tickets in the tab, instead of actually returning a page’s worth of tickets. This is fairly fast. So now when it goes to refresh tab “B”, it makes simultaneous ajax calls to get the count for tabs “A”, “C”, “D”, etc. This means that tabs that have no tickets are disabled, giving you a good visual indication of which tabs you need to look at. Also, any time you interact with the page, in the background it’s checking to see if any of the other tabs need to be enabled or disabled. I’ve checked in Firebug and it’s apparent that it does all these other tab count AJAX calls while the “repopulate the currently selected tab” AJAX call is processing, so it’s nice and fast. I’m pretty happy with this.

Next iteration would probably be to add some searching or filtering.

After that, maybe using a WebSocket or periodic polling to see if anything has changed instead of only refreshing when you interact with it.