Why jQTouch is Rad, But Won’t Last

Recently at jsConf, @sintaxi (of @phonegap fame) said in a Track B talk (and I’m paraphrasing here), “the best thing you can do now for mobile development is to make a mobile website or webapp.” Now, these words were intended not so much as for what the title of this article implies, but more for the whole issue surrounding the changes to the ToS that Apple recently announced in regards to using other means for creating iPhone apps. Regardless of the context of why he was making this recommendation, it still is something with which I totally agree, but for a different reason, and that is wherein jQTouch comes.

jQTouch is an amazing project spearheaded by @davidkaneda and has been promoted by many people including @jonathanstark. jQTouch, if you ain’t know, is a JavaScript library dependent on jQuery and is intended for making mobile webapps targetted for the iPhone. jQTouch is an absolutely brilliant piece of work where one can take the default project, modify the index.html with their markup, change some simple JavaScript, and within minutes one has a mobile webapp that looks like a native iPhone app. I have used jQTouch for rapid prototyping efforts and have been repeatedly blown away at how fast I can take a concept and have it “working” on an iPhone in such a short amount of time.

However, jQTouch, is only for building something that is specifically targeted for the iPhone. That approach, in my opinion, is flawed. The browsing experience of a jQTouch webapp on an Android device is awkward at best and crashes the browser altogether at worst. jQTouch will be similar to the problem that arose when people were building webapps where Internet Explorer was required and was “best viewed in a 1024px x 768px” screen resolution. We all know how successful that approach was.

In my opinion, one needs to design, architect, and develop sites, apps, and experiences, universally. That is not to say you can’t take advantage of some of the cool things the iPhone browser has over some of the other devices’ browsers (hardware accelerated transitions FTMFW), but note that creating a mobile webapp that is supposed to simulate a native iPhone experience creates at best, a lackluster experience for (almost) all the other internet friendly mobile devices.

Moreover, Android’s market share is rising…fast. iPhone’s market share is not that safe. Why? iPhone is a device. Android is a platform for devices. There will be thousands of Android devices by this time next year. There will still only be one iPhone. Moreover, Palm, Blackberry, and Nokia appear to be moving to webkit as well. Do you really want your mobile webapp to look like an iPhone app on a Blackberry Curve?

And if you needed more proof that providing a “native iPhone mobile app experience” for all mobile apps is the wrong approach, look no further than a recent article on ReadWriteWeb where mobile stat guru, Taptu, explains the future of the web is to be dominated by cross-platform based mobile websites that are “mobile web touch-friendly”. So while it currently may be trendy to design and develop strictly for the iPhone (because it dominates in mobile browsing market share), one may be shooting one’s self in the foot in the process. Moreover, with so many various touch screen devices coming to market from the iPad to Archos, Acer, the HP Slate, and various Android and Chrome OS tablets, doesn’t it make sense to design and develop for various mobile platforms that support touch events? Why limit yourself to the experience that is only on the iPhone?

But Joe, I only want to design for the iPhone. Great! Meanwhile me and the rest of the world will be designing for iPhone and everybody else. But Joe, jQTouch makes it so easy! I know, suck it up and build your own framework. Get smarter, get better, design something, destroy it, start all over, and then do that again. Now you are ready for the mobile web.

3 Comments / Apr 22.10 / Mobile, Posts / by joemccann

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

Cons

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

« Previous Entries