One of the things we have been doing over the last few days has been another iPhone application.

A common problem during development is getting it onto our clients phones for testing before it goes up onto the app store. This is because Apple makes it exceedingly difficult to deploy onto devices unless you physically have the device to hand (and even then its a pain!).

This time, we had the opportunity to give jailbreaking a go, as a very good friend of mine (and guru behind the app in question), got away from his desk and went and bought us a couple of iPhones to muck around with. Basically he needed a quick and easy way of getting the development version of the app onto various devices without having to go through the rigmarole of setting up xcode for code signing and device provisioning for each and every different iPhone whilst we are developing or putting onto our clients iPhone’s so they can test.

So we simply provided a step-by-step guide to jailbreaking the iPhone and detailing how to get the development build of the app onto the device.
Granted, its still a slight pain, but at least no hanging around for Apple to send out code signing keys and deploying via xcode.

Another great benefit is the ease for us as a development team to easily get the build of an app onto the devices. We just build it then scp it onto the device. No need to setup xcode on each and every Mac we use to do builds.

So for any development companies out there who are developing for the iPhone, its well worth having a device that’s jailbroken simply for developing with.

A while back I had some fun playing with Flex, Spring, BlazeDS and Hibernate.

We recently won a contract to create quite a large on and offline application that we are implementing the GUI in Flex and the back-end in J2EE.
Given how much we like Spring and Hibernate, and how useful BlazeDS is, I have spent a bit of time again getting these all playing nicely together.

Firstly there is now a Spring and BlazeDS integration kit available which moves the configuration of BlazeDS completely to Spring. I really wanted this in our latest setup as it is far more elegant than the mish-mash of configuration files before.

Secondly there are now a couple of lazy loading frameworks for BlazeDS and Hibernate. We identified Gilead and dpHibernate as contenders. We really wanted decent automatic lazy loading for this particular project due to the size of the data model. Lazy loading is critical in any Flex-BlazeDS web app that is going to have a large and deep data model, otherwise the whole data model will have to go over the wire when only little bits of it are actually needed.

Getting this all working together nicely was not however straight forward!

Firstly I spent some time evaluating Gilead. At the time of writing, this simply doesn’t do what it says on the tin.
I was expecting automatic lazy loading but Gilead does not do this. Rather, it expects you to make the calls and what it does offer is the merging and cloning of objects. This solution is not a complete lazy loading solution and still would require quite a lot of code around it to achieve automatic lazy loading. So I moved onto dpHibernate…

And this gladly does do what one would expect! The source code is also very nicely written and well laid out, which made a thorough examination quite easy.

Next up was getting the Spring and Flex integration kit setup.
This went fine until trying to configure in dpHibernate, as the M2 release (which was current release at the time), didnt have support for wiring in and configuring a custom BlazeDS adapter, essential for any lazy loading solution.
Luckily, in the trunk was work by the very talented Jeremy Grelle which seemed to be the solution.
Getting it to actually work took a bit of debugging but I finally got there and documented the core stumbling block here.

So what we end up with is a Spring configured BlazeDS web app with a Hibernate persistence layer with lazy collection loading.

As I final point I want to highlight the issue of LiveCycle Data Services, which is Adobe’s commercial offering of BlazeDS, and does handle lazy loading out of the box.
My problem here was that after 6, yes SIX, attempts to get a cost from Adobe for LiveCycle DS, Adobe failed to ever respond (I tried all the contact options detailed on the product page).
Apart from lazy loading, the other reason we quite liked the idea of LiveCycle DS was the on/off-line data synchronization it has for AIR applications (as we will also be creating an AIR app for this particular project). Instead we will roll are own framework for this bit, and likely open-source it. So Adobe, if your listening, you lost a sale here by simply not responding. I wonder how many other potential sales have been missed?