Sencha Touch

This blog is outlining my experiences developing a mobile web based application developed with Sencha Touch and packaged with PhoneGap.

I have been developing a quick app for my iphone using Sencha Touch API (currenty 1.1). I have found it quite intuitive and the outcome is that I get a web based app that can be run nicely on Android as well as iOS devices. And I get to develop on my Win based machine in Java. Easy to test without emulator using normal browser too.

The idea is to write code via HTML5 that can be useful on touch based devices such as iPhone, iPad and Android based phones and tabs. Rather than learning languages and frameworks specific to these technologies it is possible to stick to common HTML5 skills that still support touch device like gestures and form factors.

In addition to deploying as a device capable web site, I intend to wrap it up with PhoneGap to deploy it as native binaries onto multiple devices (Android, iOS, BB) with access to native APIs.

The technology I am starting with

I'm not cool enough to develop on a Mac Book, so I'm building on Win 7 Laptop. For my editor, I've been trying out Sublime Text 2. Nice that it opens a folder tree and has smart syntax highlighting for JavaScript, and knows about all the HTML5 stuff (CSS, JSON, HTML, JavaScript) but a full fledged IDE would have things like code complete and syntax checking right in the IDE, so I am also old schooling it and using Eclipse IDE.

I have setup Eclipse IDE (Classic edition) augmented with Android SDK and the emulators, with the ADT Android Developer Tools eclipse plugin. However, for just Sencha touch the android stuff is not needed. But soon i will be looking at PhoneGap to create binaries ready to deploy to devices. And I'm also developing with Android SDK specifically.

I am also building the server side. I have been looking at node.js as a possibility. But I am also looking at Java based solutions as well (I'm showing my age I guess). For the Java based solutions, I am looking at deploying a J2EE (war) app and using Spring MVC as a core framework on the server side.

To deploy as a server based web app (and I also intend to have server side components as well), I have constructed a maven driven web app from a maven archetype (see this great blog article), and assuring it has the web app nature for using eclipse with help and great gratitude from this blog. This process of getting Eclipse to work with Maven for a web app based project was more complex and error prone than I'd like. My desire was to use the IDE to code and build, and see the results immediately synchronized on the integrated web server. But Eclipse doesn't build natively with Maven goals like NetBeans does, and the integrated web server plugins aren't as smart as they should on when to sync, deploy and run. I may rethink this choice as I go along.

To help provide the server stuff I need (remember Im on a Windows platform) I downloaded XAMPP and am running separate a Tomcat instance as an independent deployment target different from the Eclipse integrated tomcat server where I can test changes during development.

For the hosted solution and since I'm deploying to a java based app server (tomcat), I am deploying to jelastic I can test  it on my real devices. I also have Android emulators integrated into Eclipse and also iPadian emulating an ipad but I haven't tried that avenue yet.

The real devices I have to test on incude:

• galaxy 10.1 tab
• iphone 3GS (old I know)

For basic application architecture I have two MVC frameworks!

• One MVC on the client (Sencha Touch with MVC pattern) and 
• One MVC on the server (Spring MVC). 

Overkill? we shall see. We will get into the MVC model client and server side in another blog.

For Sencha Touch I am following the MVC pattern as described by the sencha forms tutorial.  Also, I have followed a great talk and tutorial from this German developer Nils Dehl where he creates a shopping list app.

For persistence, I have two choices: old school main stream relational (MySQL) or NoSQL approach with MondoDB. I will start out with mondo db and see what happens. The idea is that the data model is going to be json based and object oriented. Structured, hierarchic data can be managed using objects and indexes. For the app I want to build, it may work well. But it seems heretical (not necessarily a bad thing)..

Next article I will get into the app design...

A shout out to a framework for html5

One of my readers sent me a link to Strobe, (http://www.strobecorp.com/) an open source platform built from the ground up to leverage html5, but still leverage MVC. Although my ship has already left down the river of Spring, I can longingly look at its innovation and see what we can adopt for ourselves. I know I will loose a few hours this weekend on playing with this one.

Thanks

PS, I also seem to be wasting my time playing with knew language ides: ever check out Clojure. Yes, it talks with a lisp as well.

Crossing the chasm to the new paradigm

I titled this post in homage to Moore, the author of Crossing the Chasm. He clearly described how marketing strategies for high-tech are different from other product categories. He heavily leverages the technology adoption life-cycle bell curve where Rogers et. al. segments people into 5 categories:

1. innovators,
2. early adopters,
3. early majority,
4. late majority and
5. laggards

(although the last category seems a bit offensive :)). Moore emphasizes that getting from early adopter to early majority is like crossing a chasm: the former 'visionaries' have very different expectations then the later 'pragmatists'. To mix authors (like metaphors), a 'tipping point' seems to be required to make the shift.
So it is for developers: new ideas, languages and techniques come by all the time. Some jump in 'where angels dare to tread'. I seem to be the former. At least I like to think of myself as such. Others wait. Some are clearly risk averse, but I think for some, it is hard to let go of the 'it works, why change it' paradigm. Perhaps they are right. They are pragmatists, and by nature practical. But innovators and early adopters seem to reap benefits. Since the technology wave moves incesntly and swiftly, it is best to keep on its cusp, like a surfer, using its power and momentum to guide you on, lest you be left paddling to catch up, far behind.
But many on my team aren't of the innovator ilk. Nor is my company. I work for a very large software company that should be on the leading edge, if not the bleeding edge of innovation adoption. But we're not. We suffer from a stifling bureaucracy (like most large companies or governments, dare I say), and a hefty dose of 'not built here' syndrome. Interestingly enough, by boss isn't a 'laggard' in any stretch of the imagination. He, however, bears the brunt of having to argue for the wacky ideas of his reports in front of very risk averse corporate gatekeepers. Sometimes he wins, sometimes not.
But, within the team, it was surprising to me how shocked people were when I said,

"we are not going to write JSP any more."

I'm sure some of the readers of this blog post (all 1 of you) might be shocked as well. But sometimes we need to be shocked. This is a broad and sweeping statement, but it is powerful, because it hints at our reliance on rendering the UI on the server. And we shouldn't. This is heresy, and would have been foolish in the past. From early cgi and perl (remember those days) to the development of J2EE, the browser was considered a dumb reader of html, not a smart client platform like thick client apps or client server. Applets were to be that, not the browser. If not Applets, then flash, if not flash then... well, ... the browser.
What is the browser today? Its not dumb. It's not just a reader. It is an operating system. It is a platform that has capabilities to run sophisticated programs delivered to it. HTML5, CSS3 and JavaScript are the languages it speaks. If you know the lingo, you can unleash a vast array of capabilities that just a couple of years before were left to the native or thick client world.
So, my aha moment came when I realized that what we needed to do was to go back to the client server days. In those days, you had vast power of the desktop, its graphical and multimedia power and local storage capability. You connected to the server for data. Yes, business rules and shaping of data occurred on the server. Certainly secure selection and delivery of data as well. It enforces transactionality and validity. It handles persistence and auditing. But its is never in the business of rendering the user interface--that's the client's job.
Rendering UI on the server was the compromise required to deliver applications over the web. And it was worth it too. Not to wory about the client footprint, not to have to wait for support to install and configure the next version. immediate access to everything a mouse click away. It rocked our world. It changed our world. Thanks Tim for that. But he was thinking hyperlinked books after all, not applications. It was amazing what we can do even with its obvious limitations. And Tim has moved on too.

But we no longer need to make this compromise. We can benefit from the zero footprint immediate access to all the worlds knowledge and applications but still leverage graphics, multimedia, processing power and even local storage of the desktop.

Fun with HTML5

I guess I'm a bit late to the game. However, perhaps not too late. HTML5 offers a host of solutions for the kind of application I want to build: rich client, local storage, animated, etc. I walked through several HTML5 demos and examples over the weekend.

I can deliver a rich client experience for an application needing local only storage with nothing but HTML5, JavaScript and CSS3. But for real 'client server' or mashups with shared information, we still need connectivity to the server (Ajax based, RESTful, transport in JSON).