Nexus One Review From a Programmer and UI Engineer’s Perspective
Ahh, the Nexus One, the gadget the interweb is all aflutter about. There have been countless reviews at this time but you won’t find the typical “former iPhone 3G-S user switching to Android-based Nexus One” review here, where in my opinion, they don’t “get it” from a developer or UI engineer’s perspective. If you want to read something like that head over to Gizmodo. The following post is not a review about the sleekness of the phone’s chassis or any comparisons to the iPhone (I think one is missing it entirely if they are trying to compare the Nexus One to iPhone, but that’s a separate blog post), no, the following review is what I think is good and bad about the Nexus One from a programmer’s perspective and a UI engineer’s perspective as I like to think of myself as both.
Disclaimer: I have had a G1 since October 2008 and have developed a few Android apps (none publicly released yet, but soon will be). The majority of my bias may come from the upgrade to the Android source (2.1 as of this writing) coupled with a number of hardware related upgrades.
Pros
- Snapdragon 1Ghz processer’s snappy-ness
- The orientation change’s (switching from landscape to portrait and vice versa) responsiveness
- The screen’s clarity and fidelity
- Five pages/screens of “home desktop” real estate
- Voice commands for nearly everything
- 5MP Camera with LED Flash
- Video recording in MPEG-4 quality
- Navigation mode with Street View
- Live Wallpapers
- Auto-adjusting display brightness
Cons
- Haptic response keys’ awkward experience
- No orientation change on home screen(s) plus a bug when attempting to do so
- Power button only means of “awaking” the device
- Gallery application interaction issues
- Unlock screen’s awkward “slide” gesture
- Text input in landscape mode’s poor experience
Programmer’s Perspective
By seeing such features as the Navigation and even the street views available in Google Maps, I have become motivated to start utilizing those APIs or consider using some of the additional features of the Android SDK that I did not consider before, mainly because the phone itself is fast enough at rendering something like Streetview in a rather seamless fashion. Seeing what Google has done with some of their own apps, coupled with the overall speed improvements between orientation changes inspires me no longer worry about programming against a poor experience. However, the speech-to-text feature, and its inclusion in nearly all of the input fields on the device, gave me glimpse into the future of Google’s approach to allowing that faster mobile processor to remain just that: fast.
The speech-to-text feature processes all its data in the cloud. This concept is not something that should be taken lightly. The processing power needed to handle something as complex as speech-to-text recognition would bring the 1Ghz Snapdragon chip to a crawl. However, Android, and more importantly Google is relying on this processing to take place elsewhere (the cloud) and instead rely on the data transfer (and the subsequent data networks) and ultimately the speed of the transfer to create a seamless and pleasant user experience.
The text-to-speech feature is not unique to the Nexus One, but its pervasiveness across input types is (so far). Furthermore, the front and back microphones (for improved noise cancellation) installed on the Nexus One shows a commitment of sorts toward the idea of “more speaking, less typing”. This is inspiring from a programmer’s perspective for if Google does in fact adapt this model for let’s say something like, potentially the managing, streaming, or recording of 3-D camera data, and they handle the intensive processing, but we simply receive back data, then the sky (or cloud) is the limit. The services provided by Google (or potentially other cloud-processing/SaaS vendors) would offload the heavy lifting for programmers so the programmers can focus on creating bleeding edge apps without worrying about the processor’s ability to crunch loads of data. This, from my perspective, is huge.
UI Engineer’s Perspective
Where to begin. The richness and clarity of the screen is enough to make any UI engineer anxious to create an app that simply cycles through RGB values. The AMOLED screen is now more like a canvas. This not only provides obvious benefits for the visual designer but can also pose a problem in regards to fragmentation across devices’ screen resolutions. I think we’ve dealt with issues like this before.
The new animations and simulated 3-D environments across many of the apps including the “Starwars” rollover effect for the Home screen lend to the notion of more animations coming available to the UI designer. The Android SDK comes packaged with some preset animations, but it is interesting to see how Google is using some of the newer animations/transitions on the Nexus One running Android 2.1.
Google has also paid attention to even subtle improvements at interactions with the UI at the application level. For example, the browser renders pages much faster and if the page is a standard site, not a mobile version, it shows the page in nearly in full with the ability of double-tapping to zoom in to the area you wish to see at a more granular level. The double-tap is way more intuitive than the earlier quasi-magnifying glass click then drag and release awkward interaction. Note, this interaction is an Android 2.0 version improvement, not unique to the Nexus One (Motorola Droid).
I would be remiss not discuss the newest bit of eye candy for the UI engineers: Live Wallpapers. The live, moving, seemingly breathing wallpapers that shipped with the Nexus One are definitely the first thing one notices when you turn on the Nexus One. Not only are the wallpapers animated and full of color, but that are fully interactive as well. For example, the “rippling water” live wallpaper not only has leaves falling onto the pool of water thus causing a rippling effect, but a tap anywhere on the desktop of the home screen not occupied by an app or widget shortcut triggers the same rippling effect as if you had actually touched the water. How practical and useful is something like this? Well not so much. What is important is the fact the the animation library Processing was used on a couple of the early prototypes (according to Romain Guy) and an API for developing live wallpapers is due out in the Android 2.1 SDK release. The potential for using Google’s version of a Processing-like class for other uses than actually making live wallpapers is really inspiring.
Final Analysis
Most of what the Nexus One offers as a mobile smart/superphone is not anything game-changing for the device itself or the mobile smart/superphone market. Yet, the Nexus One is not just another smartphone, but more of a showcase of what the Android platform is capable of doing. Given the right hardware and knowledge of the Android platform (and potentially C and/or Linux), vendors and developers can create Android-based devices with the ability of being game-changing or even create new categories for devices altogether. A touchscreen tablet for web browsing? E-readers? Live TV-streaming devices that fit in your pocket? All of these are possible. However, to simply compare the Nexus One next to an iPhone, Palm Pre, or any other slew of mobile smartphone devices, is not, in my opinion the correct comparison. Android is to mobile what Windows is to desktop PCs. The Nexus One just happens to have a telephony as a feature of this mobile device.
No Comments / Jan 11.10 / Android, Mobile, Posts / by joemccann
Viewing Web Pages Locally on Android’s Emulator
I am doing some hacking with Android and building an app using various open source technologies such as lawnchair, xui, and Titanium and came to a point where I needed to simply view a web page that was running locally on my development machine, in my case on the localhost . So after launching the Android emulator and opening the browser, I tried typing in http://localhost, http://localhost:8000, and even the IP address http://127.0.0.1 but all to no avail.
So after doing some digging I found an article somewhat related that called for modifying your hosts file. However, this didn’t work for me either.
So it was onto Android’s online documentation. Yikes, I know. Nonetheless, I found EXACTLY what I was looking for almost immediately. According to the authors of this section of the documentation
Each instance of the emulator runs behind a virtual router/firewall service that isolates it from your development machine’s network interfaces and settings and from the internet. An emulated device can not see your development machine or other emulator instances on the network. Instead, it sees only that it is connected through Ethernet to a router/firewall.
As it turns out the virtual router that is running actually has its own internal loopback interface which is the same as the loopback interface address on my development machine, 127.0.0.1. However, the key is the special alias that the virtual router provides to your localhost’s loopback interface, that address is 10.0.2.2.
So just type http://10.0.2.2 into the browser from the Android emulator and you’ll be requesting from http://127.0.0.1 on your development machine.
No Comments / Nov 28.09 / Android, Mobile, Posts / by joemccann
Distributed Collaboration – Building a Website Remotely
Just recently, a great friend, and an even better visual designer, Brendan Finlayson (@brendanfin) and I have been working on helping each other out with some side projects we both have to complete. Namely, I would like him to skin me a new UI for my site and he would like me to assist in developing his online portfolio. Nothing Shocking there except that I live in Austin and he lives in Oakland. Before the days of high-speed connections and standards-compliant browsers this sort of scenario could take weeks to complete.
Not anymore, with applications like Dropbox, XAMPP, Digsby, and Skype, and using them together in methods that exploit their awesome utility when combined.
Dropbox
For those of you that aren’t familiar with Dropbox, in a nutshell, Dropbox is the easiest way to share and store your files online. It works on any platform as well. Brendan has a Mac and I have a PC and it works flawlessly on both of our machines. Let’s say you have a home desktop computer, a personal laptop, a work laptop, and a work desktop computer. Once you install Dropbox’s application on each of those computers, you will have access to any files you store in your “My Dropbox” folder on any of the computers. For example, say you have a TPS Report that you save in your “My Dropbox” folder on your work desktop computer. With Dropbox running on each of the other three computers, they each will automagically have that same file stored in their “My Dropbox” folder as well. Moreover, say you get home and on your personal laptop you make a change to the file. The delta (the difference or change to the file) is the only thing uploaded to your Dropbox account and a revision is created for that save (or in subversion terms “commit”). Now, that file on every other computer is automagically updated with the new version of the file. If you need to revert back to a previous file version, just open up the revision that you need. Simply brilliant.
Now, one of the coolest features for Dropbox is that you can create a folder and share that entire folder with anyone you invite. For example, I created a folder called “joe_paddy” (Paddy is Brendan’s nickname), right-clicked on the folder and under the Dropbox menu selected “Sharing Options”.
My browser then immediately opened up my Dropbox account page where this folder, “joe_paddy”, resides. On this page, there is a box where I simply add Brendan’s email address to invite him, but, I could have invited as many people as I wanted to have access to the folder, granted they each have a Dropbox account. Upon accepting my invitation, the folder “joe_paddy” was instantly created on his computer.
The beauty of this is now Brendan, the visual designer, can work directly out of the “joe_paddy” folder and I will receive any/all files and changes to those files in nearly real-time. On the flip side, since I’m the one building out the web pages (HTML via PHP, CSS, and JavaScript), any changes I make are reflected immediately on his computer as well. But Joe, he can’t just open a PHP file and it render in a browser, it needs to be served up from a well, server! That’s where XAMPP comes in.
XAMPP
XAMPP is an easy to install Apache distribution containing MySQL, PHP and Perl. XAMPP is really very easy to install and to use – just download, extract and start. Currently, XAMPP is available for Windows, OS X, Linux, and Solaris. XAMPP assists with a distributed collaboration environment when it is coupled with the use of Dropbox.
For example, Brendan and I are collaborating on a website right now. He is handling the design composition in Photoshop, slicing up images, and creating a style guide. If you don’t currently use a style guide in your projects, I highly recommend you do. In a nutshell, it is a document combining all typefaces, typeface sizes, and typeface colors and colors for other elements (e.g. background color) used in the design composition so the developer doesn’t have to refer to anything but the style guide when hashing out the CSS. Okay, so back to the example, Brendan is doing the visual stuff and I am building out the pages in PHP. Now, if I am making a change to the PHP file and I want Brendan to be able to open a browser and see the webpage in its current state, he can’t do this without a server running. He installs XAMPP for his platform, OS X, and he now has a “local” server up and running, http://localhost/. However, the default httpd.conf file has the document root set to the htdocs folder under the XAMPP install folder. On Windows, that location is here: C:\xampp\htdocs. Unfortunatey, we don’t want to see XAMPP’s local site that is bundled with the application, we want to see our site that we are working on.
At this point, I opened the httpd.conf file and found the lines that I needed to modify in order to point the document root to the directory of where I’m building the site out. First line is of course, the DocumentRoot setting. The value for the DocumentRoot should be the full path to the folder that is where I am building the web pages. This path contains my “My Dropbox” folder.
The only other line I needed to change was the <Directory> setting as it was pointing to the htdocs folder under the XAMPP install directory and instead needs to be pointing
After making these two changes to my httpd.conf file, I save it, close it, and restart Apache using XAMPP’s slick control panel. Simply stop Apache…
…then start it,
…then navigate to http://localhost/ in your browser and voilà, I am now able to see the website on my local server.
In most cases, trying to get a designer to modify an httpd.conf file can be very difficult, mainly because they are not as technical as developers. Not a problem in our case, for using Digsby as my instant messenger client I am easily able to direct Brendan on what lines in the httpd.conf file need to be modified.
Digsby (and Adium and Skype)
Digsby is an all encompassing instant messaging, email, and social networking client that I have found to be incredibly stable and abundantly useful for not only instant messaging, but keeping up with new emails in my Gmail account, new message on Facebook, LinkedIn, Myspace, etc. Digsby is a one stop shop for all of my communication needs.
After adding my GTalk account to Digsby (and after Brendan installed XAMPP on his Mac), I was able to communicate directly with Brendan and guide him through the httpd.conf file in order for him to modify the two lines of code needed to point to the folder we were sharing to build the website. Moreover, we were then actually able to collaborate and make changes in near real-time. For example, if we are looking at the “About” page of this particular website, he can tell me that the border of an image needs to be red. I simply make the change in the proper CSS file, save that CSS file, then have Brendan reload his browser and BAM, the image has the border. The magic lies in the fact that Dropbox only uploads and subsequently downloads the delta (what was saved in the CSS file), not the entire file!
If you’re on a Mac, I hear Adium is a great instant messaging solution.
Now, if you’re more of a vocal and visual person or just prefer to talk on the phone with folks, Skype may be an even better solution that Digsby. Skype is great Video Chat and VOIP phone service that not only has an instant messaging client, but has the ability for you and another person to physically chat with one another and even see the person as well! All you need to do is install Skype and hook up your web camera and microphone. Me and my three brothers have the following camera, which is in HD and has a microphone built in: Logitech QuickCam Pro 9000. Super easy to install and use; I highly recommend this one.
Conclusion
So the combination of the aforementioned resources has enabled myself and Brendan to successfully build out the website plus, it has enabled us to confidently take on any additional projects with which we may be presented. The best part about it? All of these resources are FREE. Moreover, I believe I’ve only scratched the surface here with this concept of “distributed collaboration” as I’m sure many out there have their own tricks and tips. So share them in the comments!
6 Comments / Aug 31.09 / Posts / by joemccann







