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.

2 thoughts on “First thoughts on the Nexus 7”

  1. I’ve had sort of the opposite experience – I’ve used Android since the very first phone came out, but from time to time I need to use an iPhone for work, and I find it very disorienting. I have a hard time getting around without the back and menu buttons, or the “long press” function that does a lot of stuff in Android but doesn’t seem to do much in iOS.

  2. I’ve made a few Android apps. A few tips:

    – The need for dozens or hundreds of test devices is exaggerated. If you making a 3D videogame, or doing streaming video, or doing something else where the specific characteristics of the graphics chipset and display are relevant, then that might be true, but for typical apps using the emulators is just fine. (But don’t be surprised when you get reports that your app doesn’t run on some particular model. It happens.)

    – The OS fragmentation problem is real. If you design your app to use the 2.3 API, then it will run on a majority of devices, but look old-fashioned when running on an Android 4.x. If you design the app to run on 4.x, it will look great on 4.x, but will be unavailable to most Android devices. If I was going to do an Android app for my own personal use and fun, I’d just target 4.1 and say “fuck you” to everybody with old devices, but when doing paying work, it’s best to design for 4.x and then do whatever you need to do to make it backward compatible with 2.x.

    – My biggest peeve with Android development is that everything looks like shit by default. If you just put some controls on a page, you end up with what you’d get if you did a website with no CSS. Most of the style stuff is underdocumented. And then every manufacturer provides a different set of fonts, a different default color scheme, and so on, so defining styles that look good on all devices is really difficult.

    – My other peeve with Android is that the API is designed around the idea that all your data is in a local MySQL database, and each screen just displays the results of a query and allows modification of that data. If your app doesn’t fit that architecture, then you find yourself often asking “Why does this have to be so freaking hard?!?”

    – A lot of popular Android books and tutorials still use 2.x and a phone as their starting point, and have 4.x-related info tacked on to chapters at the end of the book. I think most developers would be better served by looking at the 4.x API first and targeting both phones and tablets, so avoid those older learning resources.

    – While Android development uses the Java programming language, many of the Java APIs that developers are accustomed to aren’t available on Android. Stuff in java.lang and java.util are there, but for a lot of other things you will need a third-party library or have to use some weird Android alternative.

    – You spend more time editing XML files than writing Java code.

    – There is some degree of sandboxing between apps, so by default, most apps can’t access the data of other apps. But unlike iOS, it is pretty straightforward to design apps that share their data and UI elements with other apps.

    – I think we are still a few years away from the point where HTML5 apps are just as good as native iOS and Android apps. It will happen eventually, but right now the difference is hard to ignore. (OTOH, if you are one of those people who thought Android 2.x is just as good as iOS, then maybe you can ignore those differences.)

Comments are closed.