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...

Getting started with Spring Roo, GWT and STS

Time to get started. I'm going to run through the introductory materials on building a Spring Roo application with the Google Web Toolkit front end. I will be using the Spring Tools Suite as the IDE (based on Eclipse).

I will start by following some initial advice:

• on the Google side: here is a google code blog
• on the Spring side: here is the springroo start and the Beginning with Roo: The tutorial from Spring Framework reference documentation
• another blog (gwtsts.blogspot.com) by Cengiz Öner describing this effort has multi-part instructions

Installation

What I have

• Java 6 SDK r26 from here
• SpringSource Tool Suite: Version: 2.7.1.RELEASE: Build Id: 201107091000
• Using Google Suite Plugin Version 2.3.3.r36v201107211953
• Spring Roo (latest production release) 1.1.4 RELEASE

I got Spring Tool Suite bundled with Google Integration from here

After running STS, go to the dashboard and select the 'extensions' tab (bottom). Find and Check Google Plugin for Eclipse and press 'Install' (bottom left)

Restart STS and thats it (for now)

Overview of Spring Pizza Shop Demo

Lets use the Spring Framework Roo tutorial to get started.This tutorial walks us through creating a Roo project including entities controllers and the UI/scaffold. I will try to emphasise use of the STS tool as well as focusinging on using GWT as the front end. To begin with, we will follow the tutorial fairly closely.

Here is the project UML from the spring tutorial that we will create

This is the Roo Pizza Shop demo

First Step Basic Roo Configuration

Spring Roo builds upon Spring framework 3.0 with JPA 2.0. It uses a command line tool to create basic elements of a project, from persistence setup, to creating entities, to creating Spring MVC controllers, to generating Scaffold ui (in our case using GWT).

We can use spring STS to create a new spring Roo project project

1. From the Dashboard, select Create a Spring Roo Project
2. Fill out dialog: Project Name: pizza, top level package: com.springsource.roo.pizzashop
3. Accept all other defaults and press Next (and then Finish). This will create the Roo project and open the roo shell. Actually, STS is executing the roo shell to create the project directory and the roo command:

   roo> project --topLevelPackage com.springsource.roo.pizzashop

We see the ROO command shell at the bottom with a command promt inviting us to execute roo commands.

The window has a top part showing a console with roo commands as well as a prompt, but don't be fooled. The roo prompt we use in StS is below (a single line edit).
The spring ROO project leverages Maven2 and its unique project structure.

One cool roo command you will use right away is hint. This will give you possible options to do from the point in your project. In this case,

1. type HINT and press enter, Roo Shell will respond with a suggestion to do 'persistence setup'
2. type' persitence setup' and press ctrl+space. In StS, this will use code assist to allow you to select possible next options for the command (the command line, you press the TAB key). In this case we will select --provider HIBERNATE and --database HYPERSONIC_IN_MEMORY
3. The complete roo command is:

   persistence setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY

4. Roo will generate the JPA configuration files and initial spring context

Next: Create an Entity

Now we are ready to create some entities and fields

1. Press Hint again, and Roo will advise you to type ent and press TAB to get the next option (from STS, ctrl+space). This will allow us to create an entity with a specific class name: Topping
2. Type entity then press (ctrl+space) . This will produce --class
3. Type ~.domain.Topping for the class name (the tilda will indicate the project's package root (remember we specified com.springsource.roo.pizzashop)
4. Now ctrl+space doesn't give us more hints since all required options are satisfied, but type double dash (--) and then ctrl+space will give us a bunch more options.
5. type or select --testAutomatically to generate test classes for the new entity and press enter (the ccomplete roo command: entity --class ~.domain.Topping --testAutomatically)

Roo creates a whole bunch of files and aspects. Notice the actual entity "SRC_MAIN_JAVA\com\springsource\roo\pizzashop\domain\Topping.java" is created. You can see it in the packag tree. However, STS starts with an inital filter in the package tree to 'Focus on Active Task'.

Click the filter icon in the top toolbar of the Package view to reveal the entire project. Now navigate to src/main/java. See the com.springsource.roo.pizzashop.domain package and the created Topping.java class just created.

Next: Create Fields for Our Entity

Now lets add a field. Use the roo command to type field string --fieldName name --notnull --sizeMin 2
THis will add a field, and update/add to the generated aspects based on the annotaitions.

Opening this class, all you see is

Notice the classs annotations that roo adds @RooJavaBean, @RooToString and @RooEntity. These annotations generate aspects with extensions .aj for inter type definitions. Spring also adds JSR 303 bean validation annotations on the field based on the options we specified: @NotNull and @Size(min = 2).

The principle that Roo introduces here is the heavy leveraging of AspectJ's Inter-Type Declaration (ITD). The ITD code generates as a separately complied file, but is encorporated into the class byte code of the advised class. Generally we don't need to bother about what is generated here. But lets look anyway. For instance, the @RooJavaBean annotaion creates the class Topping_Roo_JavaBean.aj. Peeking at it, we see:

File: Topping_Roo_Entity.aj

We see that the name field produced a getter and a setter for the field. As we add new fields, this aspect will be updated. Using aspects this way allows the domain class to remain particularly pure.

As another example, lets look at what was generated for the @RooToString annotation:

File: Topping_Roo_ToString.aj

Pretty nifty, huh! this is the Secret Sauce of Roo as described in Ben Alex' Blog on Roo's Architecture

Finally, lets' look at what Roo does with the @RooEntity declairation

File: Topping_Roo_Entity.aj

Rather than creating a data access object (DAO) or service, Roo assumes that each entity created has its own implementation of persistence. The @RooEntity annotation generates a ITD (Inter-type Declairation) for the entity advising it to add many methods to support persistence, inclding id generation, versioning, access to the entity manager, various transactional methods:

• persist,
  
• remove,
  
• flush,
  
• merge,
  
• clear
  

and various finder methods

• count
  
• find by id
  
• findAll
  
• and pagable findAll
  

Next: Some More entitles and fields

As Roo creates objects, it keeps track of the last object you created. The next command defaults to this target, so there is no need to specify it explicitly. For example, when we created the field, we didn't need to specify what class to create the field for. It assumed we meant the last entity we worked with.. The spring Roo console shows what entity we last worked with in its prompt, much like a command shell might with a prompt showing the current directory path.

Now lets create another entity and some fields similar to the ones we created before. Here are the Roo commands:

That's it. As long as we follow the defaults, things are easy. This is the approach taken by Ruby on Rails: convention over configuration. The command line invokes templated commands to create objects quickly.

Our project should look basically like this (as seen from the project view)

Next: Some Relationships for our Entities

We are still in JPA land. JPA allows us to create relationships as well as if POJO java classes using well known collections. Roo supports a one-to-one or many-to-one reference, a one-to-many 'set' (and also ways to create many-many). In the above, we have a one-many relationship from Pizza to Topping (a pizza has many toppings) and a one-one relationship (reference) to a base. We'll use the Roo command shell to create these too. The tutorial shows there are two relationships from Pizza, a 'reference' to a base (m:1) where a Pizza has one base, and a set of toppings (m:m relationship to toppings), where a pizza has a set of toppings.

The above commands assume you are creating the relationship fields to the last entity you created: Pizza as it would show you in a command prompt. If not, make sure to append --class ~.domain.Pizza to the above commands (at least the first one) to assure the relationships are created for the Pizza class.
And we can finish up with PizzaOrder

Notice the last command creates another relationship, this time an PizzaOrder has a set of Pizzas ordered, which Roo will create a m:m relationship for of type Set pizzas. As you can see, creating entities, fields and relationships with Roo comes down to running a set of commands to generate the appropriate Java code and Aspects according to Roo convention. In fact, you can save these commands as a 'seed' text file that will create a project for you, generating the project structure, configruation, classes and aspects required.

Next: Lets Test

We can now run the integration tests using the roo command perform tests.

perform tests

Finally: Look at the test classes generated

Testing my RESTful controllers with Spring RESTtemplate

I have been playing with Spring's RESTtemplate as an approach to integration testing on my project.

Overview of Testing a RIA with Spring and Spring VMC

I feel I should create a set of blog posts related to how I am doing testing with this technology stack. Sometimes this aggregation is helpful. In my team, we are testing at the following levels:

• unit testing of everyting - pure tests, typically single class only, with mock (using Mockito)
  
• integration testing of our services - out of container (web server) testing, but with db
  
• integration testing of our controllers - in container testing, with db
  
• functional testing of our ui (TBD) - full in container testing
  

This blog will focus on integration testing.

Integration testing, different from unit testing, tests the code as it is wired up to other components, the server and the data base as well.

Testing the controller layer in Spring MVC

To set the stage, I am using spring 3 with Spring MVC for my application. In particular, I am leveraging a lot of Ajax, accessing the controller from the browser and transporting JSON. I am using the Jackson JSON mapping implementation to marshal to from beans to JSON.

I need to create good integration tests of my controller classes so I can run JUnit tests that connect with the deployed web app and interact RESTfully like the client UI, passing JSON objects back and forth.

A helpful blog post I have used for guidance: is ralf.schaeftlein s blog detailing an approach to integration testing of restful MVC controllers with JSON. Exactly what I was interested in.
The basic steps seem to be:

1. create a unit test with java4 leveraging Spring 3 Integration Test Annotations
   
2. configure your application context XML to define your mappers that will convert between JSON and beans
   
3. write your tests pojo style

Integration Testing with Spring uses annotations to supply a spring context to your test code. Further, the annotations specify what transaction manager to use and if a rollback should be performed after the test is complete. The tests itself are written with JUnit4. Here is a snippet showing the annotations required placed on your test class.


In this case, I am testing my Data Repository, which is essentially my Data Access Object (DAO) for you old schoolers. I will post why Repositories and not DAO in a future blog.
My application context file configures spring with the required setup for my application to run this test. First, the usual name spaces:

Then, we use automatic annotation discovery of out project

Here is wshere we configure the restTemplate to be used for this integration test of our controller
Finally the required configuration for our persistence. Notice we are using JPA configuration here


Finnaly the test code.

We write an integration test for our controller that connects remotely to the deployed application, sends beans mapped from Pojo to json for the call, and then maps back json to Pojo to assert results.

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).

New Technology Stack

In my real life, I actually have to deliver software :). So most of my blogs are about the technologies I am using today as well as best practices I am actually practicing (or trying to practice) in my real life.

This blog will focus on the following technology stack for now:

• JQuery and JQuery UI
• Spring and Spring MVC
• Java Persistence API (JPA 2.0)

Also I will be looking at:

• Spring Roo
• and GWT (Google Web Toolkit)

Some techniques and tools include

• Sun NetBeans IDE
• SpringSource Tool Suite
• Test Driven Development
• Continuous Integration
• Maven