Chariot's blog is trying something new today. I asked Jason van Zyl to give our audience a preview of his talk at Philly ETE this year. I know it is a bit of promotion for the conference, but our conference planning committee knows we have the best content to date. This year, we are also partnering with Sonatype's Maven Meetup.
PHILLY ETE 2010 – GUEST BLOG
Jason van Zyl, founder and CTO of Sonatype, will be speaking at Emerging Technologies for the Enterprise in Philadelphia. His talk, Next Generation Development Infrastructure: Maven, m2eclipse, Nexus & Hudson, will take place on Thursday April 8, 2010.
In this talk van Zyl will discuss the future of Maven, “specifically Maven 3.x, the rapidly approaching m2eclipse 1.0 release, the recent Nexus 2.0 release and roadmap, and changes that have been made to Hudson to provide better interoperability with Maven.”
My presentation at Emerging Technologies for the Enterprise will cover a lot of ground, as there’s a lot going on a Sonatype these days. Just this past week we released Maven Studio for Eclipse, the only Eclipse Integrated Development Environment specifically optimized for Maven. The Studio essentially cuts the time a developer spends configuring development environments from multiple days to minutes.
I will also discuss the future of Maven, specifically migrating from Maven 2 to Maven 3.0. When migrating from Maven 2 to Maven 3.0 we’ve planned that, in most cases, users won’t experience any challenges. We’ve designed Maven 3.0 to be a drop-in replacement for Maven 2.
Ahead of the Emerging Technologies for the Enterprise conference, Sonatype will be hosting a Maven Meetup. Wednesday April 7, we will be holding a day of presentations covering everything from OSGi Runtimes, to p2, Nexus, Tycho, m2eclipse, Selenium and Peaberry.
You can register for the Sonatype Maven Meetup at www.sonatype.com/meetup2010
Monday, March 29, 2010
Friday, March 19, 2010
Audio Interview: KYW NewsRadio on Social Media in the Radio News Business
On Thursday we did an interview with Steve Butler, Program and News Director of KYW News Radio, discussing the reach of Social Media in news outlets. We cover topics as diverse as Twitter and the generational divide, using social media to discover news stories and are all areas of social media right for every situation and business.
Click on the Play button below to listen to Mr. Butler's interview with Tracey Welson-Rossman.
Developing the ETE Conference iPhone Application
As you probably know, Chariot is hosting its annual ETE conference this April. This year we've added mobile device support for obtaining all the conference information an attendee would need. This included a mobile browser friendly web site, and both iPhone and Android native applications. I had the pleasure of working on the iPhone application and would like to describe, at a high level, the process and design/implementation decisions that were made along the way.
The Importance of Storyboarding
The first step in designing the mobile application was storyboarding how a user would access the available information about the conference. This turned out to be more valuable than I had imagined. Not only did it define the screens that needed to be developed and the data required by each screen, but the extra value was identifying where screens could be re-used. Given a large part of the application is viewing various lists of sessions, the amount of re-use I was able to attain was impressive and time saving.
Also, when my co-worker Andy Oswald started to work in the Android version of the application, he could follow the same basic flow through the application that I had laid out for the iPhone, albeit designed more to the native Android look and feel.
What about the Data?
The next issue addressed was data access. The initial decision was to access the server side data on an as needed basis. This could be accomplished numerous ways including web services, REST, etc. Since the ETE website was a Rails application, REST seemed like the obvious answer. After a little research, the Objective Resource framework was found. This framework makes the interaction with Rails based web applications easy. It provides a nice abstraction of the REST calls (via either XML or JSON) and object serialization that makes remote data access simple. After some initial experimentation, it was realized that when generating JSON on the server side, Objective Resource did not support the serialization of nested objects on the client side. Since our data model had nested object graphs (Sessions have Speakers, etc.) we were forced to use XML. Sure, we could have modified the framework, but time was not on our side.
Is it really that fast?
So far, so good. We had our screen designs and our remote data access all defined. Development started and progressed nicely. Once the core functionality was developed, I moved the application from the simulator to my iPhone for more realistic testing. Suddenly, the remote data access, and therefore screen loading, seemed a bit sluggish. So, I retrieved the data on a separate thread, added progress screens while data was being retrieved from the server and loaded, and I added some local in-memory caching. This still seemed a bit sluggish, so I investigated using JSON rather than XML. It turns out the JSON was lighter weight and quicker to parse. This required some redesign on both the server side and client side, as we had to flatten out the data model being sent down to the iPhone. This wasn't too bad and it improved the user experience a good deal. But the application still didn't seem responsive enough. We kicked around different options for a more persistent local cache, but these tended to introduce what seemed to be too much complexity in staying synchronized with the server. Then Andy Oswald (developer of the ETE Android application) came up with a great solution.
Protocol buffers and local storage for a better experience
He suggested the use of Protocol Buffers to transmit data to the mobile applications. The Rails application would listen for changes to the data and subsequently generate a new protocol buffer file. Our mobile applications would make a request to the server indicating the date of the version of our local file (using the if-modified-since request header), and if a newer version existed in the server, it would return the file. If our version was current, we would receive an HTTP 304 response code. Our applications could then handle the response accordingly. This way, our local data was always synchronized with that on the server.
Since the iPhone application was now going to have a local copy of the server-side data, it was time to re-examine the data access for the application screens. Our data model was small and the relationships were pretty basic, so I decided to pursue the use of Core Data as the new data access and persistence architecture. Core Data provided the ability to deal with objects, abstracted away the actual persistence, and build queries as needed to support the various view the application presented to the users. Also it was quite performant, so the responsiveness and user experience improved greatly. Since the initial design included a nice separation between the view and data access code, this change was pretty non-invasive to implement.
So, in the end I learned the importance of laying out the user interface upfront, testing on the device early and often, and the value of local data (if possible) on the users mobile application experience. We also got a pretty cool application for the ETE 2010 Conference.
More info on the iPhone App can be found here
More info on the the Android App can be found here
The Importance of Storyboarding
The first step in designing the mobile application was storyboarding how a user would access the available information about the conference. This turned out to be more valuable than I had imagined. Not only did it define the screens that needed to be developed and the data required by each screen, but the extra value was identifying where screens could be re-used. Given a large part of the application is viewing various lists of sessions, the amount of re-use I was able to attain was impressive and time saving.
Also, when my co-worker Andy Oswald started to work in the Android version of the application, he could follow the same basic flow through the application that I had laid out for the iPhone, albeit designed more to the native Android look and feel.
What about the Data?
The next issue addressed was data access. The initial decision was to access the server side data on an as needed basis. This could be accomplished numerous ways including web services, REST, etc. Since the ETE website was a Rails application, REST seemed like the obvious answer. After a little research, the Objective Resource framework was found. This framework makes the interaction with Rails based web applications easy. It provides a nice abstraction of the REST calls (via either XML or JSON) and object serialization that makes remote data access simple. After some initial experimentation, it was realized that when generating JSON on the server side, Objective Resource did not support the serialization of nested objects on the client side. Since our data model had nested object graphs (Sessions have Speakers, etc.) we were forced to use XML. Sure, we could have modified the framework, but time was not on our side.
Is it really that fast?
So far, so good. We had our screen designs and our remote data access all defined. Development started and progressed nicely. Once the core functionality was developed, I moved the application from the simulator to my iPhone for more realistic testing. Suddenly, the remote data access, and therefore screen loading, seemed a bit sluggish. So, I retrieved the data on a separate thread, added progress screens while data was being retrieved from the server and loaded, and I added some local in-memory caching. This still seemed a bit sluggish, so I investigated using JSON rather than XML. It turns out the JSON was lighter weight and quicker to parse. This required some redesign on both the server side and client side, as we had to flatten out the data model being sent down to the iPhone. This wasn't too bad and it improved the user experience a good deal. But the application still didn't seem responsive enough. We kicked around different options for a more persistent local cache, but these tended to introduce what seemed to be too much complexity in staying synchronized with the server. Then Andy Oswald (developer of the ETE Android application) came up with a great solution.
Protocol buffers and local storage for a better experience
He suggested the use of Protocol Buffers to transmit data to the mobile applications. The Rails application would listen for changes to the data and subsequently generate a new protocol buffer file. Our mobile applications would make a request to the server indicating the date of the version of our local file (using the if-modified-since request header), and if a newer version existed in the server, it would return the file. If our version was current, we would receive an HTTP 304 response code. Our applications could then handle the response accordingly. This way, our local data was always synchronized with that on the server.
Since the iPhone application was now going to have a local copy of the server-side data, it was time to re-examine the data access for the application screens. Our data model was small and the relationships were pretty basic, so I decided to pursue the use of Core Data as the new data access and persistence architecture. Core Data provided the ability to deal with objects, abstracted away the actual persistence, and build queries as needed to support the various view the application presented to the users. Also it was quite performant, so the responsiveness and user experience improved greatly. Since the initial design included a nice separation between the view and data access code, this change was pretty non-invasive to implement.
So, in the end I learned the importance of laying out the user interface upfront, testing on the device early and often, and the value of local data (if possible) on the users mobile application experience. We also got a pretty cool application for the ETE 2010 Conference.
More info on the iPhone App can be found here
More info on the the Android App can be found here
Tuesday, March 9, 2010
Rapid Mobile Application Prototyping with PhoneGap
There is no doubt that carving out a mobile presence is a priority for many companies offering any type of product or service, or for start ups looking to gain rapid exposure. The Apple App Store has over 100,000 apps on it, and the Android platform is gaining ground. Those are just the cool kids – let's not forget the grandfather of mobile technology, Blackberry. Others in the class include Palm, Symbian and of course, Windows.
Multiple Platforms
With so many platforms available there is a risk of losing focus on developing and producing applications as resources are expended on supporting multiple platforms – a necessary evil as each presents different development environments and eccentricities.
This is why PhoneGap really stands out at the moment as four [1] of the aforementioned platforms share a common factor – a WebKit-based browser. This doesn't include BlackBerry's announcement [2] of their new WebKit based browser to come in late 2010, which takes us to five out of the six platforms.
Enter PhoneGap
Where does PhoneGap sit in this picture? Well, it jumps off the canvas and sits in your lap! PhoneGap allows you to develop applications using HTML, CSS and JavaScript and provides a JavaScript API which enables you to interact with a device's native functionality [3]. In addition to this simple application architecture, PhoneGap comes with build scripts/plugins (PhoneGap extension for XCode) which bundle up your pages into a deployable application.
The packaging and deployment to device for iPhone, Android and Palm was trivial; I can only speculate that the remaining platforms are equally easy to deploy. In light of recent Apple 'crackdowns', as of October 7th [4], 2009, it is worth noting that PhoneGap (version 0.8.0 and higher) is Apple approved.
The JavaScript advantage?
Anyone who has used a JavaScript library, Prototype, jQuery, MooTools etc, knows how powerful they can be. Anyone who has not used them can easily pick up JavaScript basics. The guys over at PhoneGap recommend using XUIJS[5] with PhoneGap as it does not contain a lot of cross-browser compatibility overhead and weighs in at < 10kb compared with jQuery at 24kb – although for simple functionality you may want to avoid using a extra library at all.
Due to the fact that we are ultimately aiming to work inside one browser implementation (WebKit), we are not held hostage by the browser compatibility issues that have haunted JavaScript for so many years. That's not to say that fragmentation in the mobile world is not an issue [6].
Now, I am not going to try to argue that these HTML/JavaScript apps offer greater performance or a better user experience over their native counterparts. However, I will say that PhoneGap will allow the rapid development of an application for multiple platforms, using a single code base [7]. This is ideal for prototyping or for apps that will have a limited life span and do not warrant the time and investment of producing native apps.Considering all of this in combination with developments coming down the pipeline, most specifically HTML5 (which includes WebSockets and Client-side database storage), the potential for these types of mobile applications is vast and genuinely exciting.[1] Android, iPhone (safari), Palm (WebOS) Symbian/S60(WRT) http://en.wikipedia.org/wiki/List_of_web_browsers#WebKit-based_browsers
[2]http://devblog.blackberry.com/2010/02/blackberry-webkit-browser-preview-at-mobile-world-congress/
[3]http://nachbaur.com/blog/phonegap-officially-permitted-on-the-app-store
[4]Checkout the road map for specifics: http://phonegap.pbworks.com/Roadmap
[5]http://code.google.com/p/xui-js/
[6]http://techcrunch.com/2010/03/04/mobile-fragmentation-forever/
[7]ok, you are going to have to tweak it for BlackBerry.
Multiple Platforms
With so many platforms available there is a risk of losing focus on developing and producing applications as resources are expended on supporting multiple platforms – a necessary evil as each presents different development environments and eccentricities.
This is why PhoneGap really stands out at the moment as four [1] of the aforementioned platforms share a common factor – a WebKit-based browser. This doesn't include BlackBerry's announcement [2] of their new WebKit based browser to come in late 2010, which takes us to five out of the six platforms.
Enter PhoneGap
Where does PhoneGap sit in this picture? Well, it jumps off the canvas and sits in your lap! PhoneGap allows you to develop applications using HTML, CSS and JavaScript and provides a JavaScript API which enables you to interact with a device's native functionality [3]. In addition to this simple application architecture, PhoneGap comes with build scripts/plugins (PhoneGap extension for XCode) which bundle up your pages into a deployable application.
The packaging and deployment to device for iPhone, Android and Palm was trivial; I can only speculate that the remaining platforms are equally easy to deploy. In light of recent Apple 'crackdowns', as of October 7th [4], 2009, it is worth noting that PhoneGap (version 0.8.0 and higher) is Apple approved.
The JavaScript advantage?
Anyone who has used a JavaScript library, Prototype, jQuery, MooTools etc, knows how powerful they can be. Anyone who has not used them can easily pick up JavaScript basics. The guys over at PhoneGap recommend using XUIJS[5] with PhoneGap as it does not contain a lot of cross-browser compatibility overhead and weighs in at < 10kb compared with jQuery at 24kb – although for simple functionality you may want to avoid using a extra library at all.
Due to the fact that we are ultimately aiming to work inside one browser implementation (WebKit), we are not held hostage by the browser compatibility issues that have haunted JavaScript for so many years. That's not to say that fragmentation in the mobile world is not an issue [6].
Now, I am not going to try to argue that these HTML/JavaScript apps offer greater performance or a better user experience over their native counterparts. However, I will say that PhoneGap will allow the rapid development of an application for multiple platforms, using a single code base [7]. This is ideal for prototyping or for apps that will have a limited life span and do not warrant the time and investment of producing native apps.Considering all of this in combination with developments coming down the pipeline, most specifically HTML5 (which includes WebSockets and Client-side database storage), the potential for these types of mobile applications is vast and genuinely exciting.[1] Android, iPhone (safari), Palm (WebOS) Symbian/S60(WRT) http://en.wikipedia.org/wiki/List_of_web_browsers#WebKit-based_browsers
[2]http://devblog.blackberry.com/2010/02/blackberry-webkit-browser-preview-at-mobile-world-congress/
[3]http://nachbaur.com/blog/phonegap-officially-permitted-on-the-app-store
[4]Checkout the road map for specifics: http://phonegap.pbworks.com/Roadmap
[5]http://code.google.com/p/xui-js/
[6]http://techcrunch.com/2010/03/04/mobile-fragmentation-forever/
[7]ok, you are going to have to tweak it for BlackBerry.
Subscribe to:
Posts (Atom)