AeroGear.js 1.2.0 has been “Pushed”!

We have been busy the last 6 weeks and this release is a big one. To help you navigate this post and get to the parts that most interest you, here is a list of the items covered.


SimplePush is a new specification and protocol coming out of the Mozilla camp that we are really excited about. In short, SimplePush gives Firefox OS and soon Firefox Desktop and Mobile browsers the ability to receive push notifications just like native mobile applications. The spec is much simpler than the current Push API draft specification being developed in that it is more like a basic ping to the client letting it know that something needs attention but then leaving it up to the client how to handle that notification. There is no message in the notification other than a simple version number which the client can use to verify that something has changed.

We believe that push messaging on the web will be an important part of web apps in the near future and with that in mind, we have created our SimplePushClient as part of the AeroGear JavaScript library, as well as our own SimplePush Server following the protocol as laid out by Mozilla. Our client will work just fine with Mozilla’s SimplePush server but we also wanted to provide another server option both for security (some companies would like more control over the push environment) and as a way to set up completely internal push networks. For example, a company with an internal app with a need for push notifications could deploy a SimplePush server on their internal network/VPN and have push messaging capability to their web apps without having to contact an outside server.

With these tools, our hope is to first help bring push messages to web apps in all browsers and second, to hopefully encourage developers to use these APIs, learn what they like and don’t like about them and then hopefully be the catalyst to encourage browsers to implement these features natively. Go grab the source from the links above or grab the SimplePushClient as part of the full AeroGear.js download or from Bower* and let us know what you think!

* To install via bower, after installing bower from the link above:

bower install aerogear


Along with our SimplePush offering, the team has been hard at work to create a quick and simple way of managing push messaging across multiple networks. To that end, today we are releasing our UnifiedPushClient which works with our also newly released UnifiedPush server as part of AeroGear.js 1.2.0.

The UnifiedPushClient provides and easy to use API for registering SimplePush endpoints registered through our SimplePushClient with a central service which will in turn manage sending push messages not only to our web apps but also iOS (APNS) and Android (GCM) applications as well. For a more thorough breakdown of UnifiedPush, see this blog post. To start using the JavaScript client, you can download AeroGear.js or use Bower.

Integration Testing and CI

A lot of work has been done to improve the testing of AeroGear.js. We have created a new integration test repo which contains QUnit tests for the pieces of the library that interact with other libraries and servers. There are also scripts there that will download or clone the servers and fire them up as needed and all of this is orchestrated by the amazing tool, Grunt.

Related to this effort, we have also set up a continuous integration strategy by way of Travis CI. Using commit hooks on Github, coupled with the environment provided by Travis, now every time a new commit is pushed to the master branch of AeroGear.js, a build is performed and all of the unit and integration tests are run to be sure anything added to the library doesn’t break anything else.

Documentation Updates

Outside of the usual documentation updates that come with releasing a new version, some effort has been made to give a bit more information about each component of the library. Specifically, a feature stability rating has been added to each part of AeroGear.js to give people an idea of how they can/should use it. There are 3 stability ratings as explained in this excerpt from the updated project README file:

  • Experimental – This feature is new and has not been thoroughly tested outside of development. This feature could be changed or removed at any time. Use of these features in a production environment is at your own risk.
  • Stable – This feature has existed for a full release cycle and has been thoroughly tested. These features are considered safe for use in production environments.
  • Deprecated – This feature is being removed or replaced. As with experimental features, these features could be removed at any time and their use in production environments is at your own risk. For features being replaced, it is recommended to update to the next version and begin using the new feature.

Change log / JIRA Resolutions

Now we get into the nitty-gritty of the release. Below you will find a list of commits from the git repo and a list of resolved JIRA tickets. This represents all of the changes to AeroGear.js in the 1.2.0 release.


  • Fixed typo in README
  • Build: Add missing integration test dev dependencies
  • Build: Add back missing qunit task
  • Build: Add integration tests for SimplePush
  • Add @status to all components for feature stability reporting
  • README: Add SimplePush and UnifiedPush documentation as well as feature stability definitions
  • Build: Remove hyphens from folder names and update build for consistency
  • updating JS doc to reflect the SimplePush specific ‘simplePushEndpoint’ URL attribute
  • Build: Remove failOnError causing false failures and remove quotes around stop parameter as they don’t help
  • Build: Add failOnError to grunt-shell commands
  • Build: Pass stop parameter as a string
  • Build: Don’t run integration on default build and don’t mix single and double quotes
  • Build: Remove test config and uncomment
  • Build: Break up integration tests by server type and control their execution from here
  • Build: Try reversing the server start order
  • Notifier Tests: Capitalization
  • Build: Fix shell task to kill java processes after the servers are no longer needed to allow grunt to continue processing
  • Build: Add dev dependency on grunt-contrib-connect for running integration tests
  • Notifier Tests: Add initial SimplePush tests
  • SimplePush: JSDoc tweaks
  • Notifier:SimplePush – Don’t store the pushEndpoint for security
  • SimplePush – Minor API changes for better polyfill behavior
  • SimplePush: Add documentation
  • Build: Remove old integration tests
  • Notifier:SimplePush – Add comments and updated JSDoc
  • Merge branch ‘master’ into Notifier
  • Pipeline: Add getAuthenticator method to retrieve the associated authenticator for a pipe. Fixes AGJS-63
  • SimplePush – Move navigator object modification into the connect callback to prevent accidental early use
  • SimplePush – Use options object instead of individual parameters and add a reconnect method for use when a connection is lost
  • Notifier:SimplePush – Add onClose callback to handle disconnection from SimplePush server and add a timeout to the triggering of registration success messages on previously registered channels
  • UnifiedPush: Use metadata object as argument in registerWithPushServer, more error checking and add JSDoc
  • adding http basic to the unregister()
  • SimplePush: Refactor to use a connect callback to simplify API and elliminate race conditions
  • SimplePush: Clean up hello channel registration and duplicate eventing
  • Fixes irc notifications
  • Build: Add condition to integration test folder removal
  • Build: Add command to remove the aerogear-js-integration folder to get a fresh clone on each run
  • Add the aerogear-js-integration folder to gitignore
  • Build: Add IRC notifications back to Travis config
  • Build: Update shell config to checkout aerogear/aerogear-js-integration master branch
  • Inclusion of missing tasks for travis
  • Initial task to trigger integration tests on Travis
  • Build: Remove integration test option as it will no longer work with the new Travis config for integration tests
  • SimplePush: Always send channelIDs on hello even if empty
  • make travis only build master branch
  • SimplePush: Change channels to channelIDs in hello message
  • Merge remote-tracking branch ‘abstractj/info’
  • Update outdated reference to JIRAs
  • Merge branch ‘master’ into Notifier
  • SimplePush: Refactor to properly handle reregistered channels
  • Build: Config push builds
  • Re-add external UUID lib
  • typo fix
  • Merge branch master into Notifier
  • Add external UUID library for ID generation in SimplePush
  • SimplePush – Remove unnecessary IIFE
  • Build: Fix failed rebase for simplePush concat
  • Build: Add btoa polyfill, base64.js
  • Add Notifier and SimplePush tasks to build
  • Notifier: Remove individual IIFEs which were causing errors by referencing libs that may not necessarily be needed or used at that time. Fixes AGJS-48
  • Remove unnecessary UUID library. Fixes AGJS-49
  • Build: Add Notifier vert.x integration tests
  • Notifier:vertx – Add send method. Fixes AGJS-50
  • Build: Add Notifier STOMPWS adapter integration tests to build and update custom tasks
  • Notifier:StompWS – Add protocol option to be able to specify a STOMP protocol
  • Build: Put integration tests behind a flag to prevent constant CI failures
  • SimplePush: Remove dependency on Unified Push as these should be independent. Fixes AGJS-44
  • Merge master into Notifier
  • Build: Add btoa polyfill, base64.js
  • Adding http_basic to device/channel registration
  • The alias key is no longer named ‘clientIdentifier’, the server is looking for the ‘alias’ key now
  • Removing unneeded check for ‘registered’; We now just perform straight POST, against common URL
  • Build: Add Notifier, SimplePush and Unified Push to Gruntfile
  • Notifier:SimplePush – Fix channel unregistration handling
  • Relax .jshintrc to allow callback creation in a loop
  • Notifier:SimplePush – Throw register and unregister errors
  • Add Notifier and SimplePush tasks to build
  • Merge branch ‘master’ into ‘Notifier’
  • UnifiedPush: Change registration error to a string
  • SimplePush: Add another todo about using native implementation
  • UnifiedPush: Add alias to device registration and require it for non-broadcast message types
  • UnifiedPush: Only use POST when registering or updating device registration
  • SimplePush: Rename pushNetworkURL to simplePushServerURL and add unifiedPushServerURL
  • SimplePush: Use http instead of ws for SockJS
  • Notifier:SimplePush – Convert to use SockJS instead of vanilla WebSockets to work across browsers
  • Adding the new header name for the ag-mobile-variant
  • Move unified push registration/unregistration to separate module. Fixes AGPUSH-8
  • Notifier:SimplePush – Add notification acknowledgments
  • SimplePush: Add ability to re-register endpoints with the unified push server. Fixes AGPUSH-5
  • SimplePush – Cleanup and use re-registration updates made in Notifier
  • Notifier:SimplePush – First pass at uaid reuse and channel re-registration
  • SimplePush: Move config off of AeroGear object to avoid reset and some other minor cleanup
  • Notifier:SimplePush – Build channel from message contents
  • SimplePush: Add unified push server registration
  • SimplePush: Update to use new SimplePush adapter for Notifier
  • Notifier: Add SimplePush adapter
  • SimplePush: Rework and add missing items to further match the SimplePush spec
  • SimplePush: Refactor to follow Mozilla’s API placing SimplePush on the navigator object to act as a proper pollyfill
  • SimplePush – Only store session ID and provide channel prefix
  • SimplePush – Add first draft of SimplePush API

JIRA Resolutions

AeroGear 1.1.2 Release

The latest release of AeroGear.js is out. This release contains some important fixes for the Notifier plugin, the addition of running integration tests to our build process and some general cleanup of the repo. For a complete list of bug fixes and changes see the changelog and list of resolved issues below or just go grab the latest version and try it out!


  • Bumping version to 1.1.2
  • Notifier: Remove individual IIFEs which were causing errors by referencing libs that may not necessarily be needed or used at that time. Fixes AGJS-48
  • Remove unnecessary UUID library. Fixes AGJS-49
  • Build: Add Notifier vert.x integration tests
  • Notifier:vertx – Add send method. Fixes AGJS-50
  • Build: Add Notifier STOMPWS adapter integration tests to build and update custom tasks
  • Notifier:StompWS – Add protocol option to be able to specify a STOMP protocol
  • Remove jQuery from package.json dependencies since it’s already included for our tests and has to be externally included when using the library

Resolved JIRA Issues – AGJS

  • AGJS-45
  • AGJS-48
  • AGJS-49
  • AGJS-50

AeroGear.js 1.1.0 Release

The latest minor release of AeroGear.js is out. This release contains the new Notifier plugin with adapters for communicating with both STOMP over websocket and vert.x based messaging services as well as a number of bug fixes. For a complete list of bug fixes and changes see the changelog and list of resolved issues below or just go grab the latest version and try it out!


  • Bump version to 1.1.0
  • Update jQuery dependency to 1.10.x
  • README: Add Notifier entry and list of dependencies and links for all plugins
  • Build: Add notifier unit tests to build
  • Tests: Add very basic unit tests for Notifier. Real functionality will be tested with integration tests
  • fix grammar
  • Notifier vertx – inline example updates
  • Notifier stompws – inline examples added
  • Notifier vertx: examples added
  • Notifier core: examples added
  • Notifier stompws – remove unneeded onDisconnect
  • Tests: Update to latest version of jQuery
  • use local vars instead of privleged methods
  • Notifier vertx – remove unneeded methods
  • Notifier stompws: add autoconnect
  • Notifier vertx: remove removeAllChannels and call unsubscribe
  • update comment
  • Adding comment to code
  • Notifier stompws: copy channel first
  • Notifier stompws: make connect options an object if it isn’t
  • Notifier stompws: remove unneeded privleged methods
  • Notifier vertx: remove unneeded privleged methods
  • Stomp Adapter: remove sockjs references
  • Merge branch ‘master’ into Notifier-adapters
  • Pipeline:Rest – Add ability to set contentType and dataType during pipe creation. Fixes AGJS-31
  • Update to latest version of mockjax for testing
  • Notifier:stompws – Use straight WebSockets for now
  • Notifier:stompws – First draft of stomp websocket adapter for Notifier
  • Merge branch master into Notifier
  • Updated dist files
  • Notifier:vertx – Add getChannelIndex method to allow checking for existence of a subscription
  • Notifier:vertx – Change default value for autoConnect to false unless channels exist at creation
  • Notifier:vertx – Initial implementation of subscribe, unsubscribe and disconnect
  • Update .jshintrc to add vertx to globals
  • Notifier:vertx – Fix scope issues and error callback name
  • Notifier:vertx – First pass at Notifier with vertx adapter

Resolved JIRA Issues – AGJS

  • AGJS-3
  • AGJS-27
  • AGJS-28
  • AGJS-33
  • AGJS-34
  • AGJS-35
  • AGJS-37
  • AGJS-38
  • AGJS-39
  • AGJS-43

AeroGear.js 1.0.1 Release

The latest maintenance release of AeroGear.js is out. This release contains a number of bug fixes, a fix for the generated source map, Travis CI integration and more. For a complete list of bug fixes and changes see the changelog and list of resolved issues below or just go grab the latest version and try it out!

Changelog -…819af95

  • Add link to JS landing page to the README
  • Update package.json version to 1.0.1
  • Auth:Rest and Pipeline:Rest – Remove Auth-Token. Fixes AGJS-26
  • Pipeline:Tests – Remove stray settings that no longer exist. Fixes AGJS-25
  • Add missing source map options for custom builds and replace banner option with preserveComments to fix broken source maps. Fixes AEROGEAR-805
  • web storage adapter checks for null. AEROGEAR-1076
  • fixing travis links
  • Merge branch ‘travis’
  • add irc notifications
  • Add Travis CI integration
  • Update to latest grunt and grunt-contrib dev dependencies

Resolved JIRA Issues – AEROGEAR / AGJS

  • AEROGEAR-805
  • AEROGEAR-989
  • AEROGEAR-1076
  • AEROGEAR-1080
  • AEROGEAR-1126
  • AEROGEAR-1128
  • AEROGEAR-1143
  • AEROGEAR-1219
  • AGJS-1
  • AGJS-22
  • AGJS-24
  • AGJS-25
  • AGJS-26

AeroGear JS 1.0.0 has landed!

It’s been a long time coming but the AeroGear team is pleased to announce the release of version 1.0.0 of the AeroGear.js library! This release provides simple yet robust and pluggable APIs for a number of the typical tasks developers must do when building a mobile application. From authentication to managing client side data to moving that data between server and client, AeroGear has you covered.


AeroGear.Auth provides simple methods for enrolling users and performing login/logout. Currently, if your server provides a REST interface to authentication, AeroGear.js will work with it.

Data Management

AeroGear.DataManager (clever name, right?) is here to help developers manage their application’s data. Whether you’re data is just stored in memory or if you need a little more persistence with session or local storage, DataManager provides a single, easy to use API for storing, retrieving and querying that data.

Data Transfer

Built on top of jQuery’s rock-solid AJAX method, AeroGear.Pipeline provides a simple, cross-browser API for persisting data to your server and retrieving that data either all at once or in manageable chunks with a standard based paging interface.

A Glimpse into the Future

With the solid foundation of AeroGear 1.0.0, we can now look into building features for more advanced web applications. The team is looking into ways to address important topics like data synchronization, offline access, websockets and push notifications, security, and a number of other things.

Check it Out

So go give it a test drive and let us know what you think! You can get the full version of AeroGear.js from our site or from Bower by running `bower install aerogear`. If you prefer a smaller version of AeroGear.js and only need certain features, check out our custom build tool. We also have a working demo showing off all of the features of AeroGear.js on OpenShift. Please report any issues or feature requests you may have in our JIRA instance.

The Next Page in the Story of AeroGear

As we approach the 1.0.0-M3 release of AeroGear.js (and the 1.0.0-M8 umbrella release of AeroGear), I just wanted to highlight some of the newest editions to the library as well as a new tool to help you get the AeroGear you need for your project.

The biggest update since M2 is the addition of handling paged resources via Pipeline. Now, if the REST endpoint your pipe is interacting with can page the data into smaller chunks and give you information about how to get to the previous and next pages of information, Pipeline can help you easily make those page transitions.

A pipe can be configured to use one of three paging methods. This means that whether the server passes the paging information back to the client via Web Linking headers (default), custom headers or in the response body, Pipeline can handle it. Once you receive a paged response from the server, Pipeline adds a couple of methods (next() and previous()) to the array of data returned. So when you’re ready for more data, it’s as simple as calling .next() and providing callbacks to be run when the next set 0f data is returned.

To get more information about paging with AeroGear.js, specific API documentation and examples check out the following links:

The other big item coming in M3 is a custom download builder. Backed by a node.js app running on OpenShift, you can now build and download a custom version of AeroGear.js from the website. This means you can select only the pieces you need, and our custom grunt build will only combine the dependencies needed for the functionality you want. Though AeroGear.js isn’t a large library now, as it grows this will be a very useful tool to help our users keep their file sizes down. A big shout out to Lucas Holmquist (@sienaluke) for his work on this awesome new tool!

AeroGear from a Different “Angle”

With a lot of talk around the water cooler lately about Angular.js, I decided I would throw together an app using AeroGear.js and Angular.js to accomplish a couple of goals.

  1. My only experience with Angular was playing with it a bit but had not really dove into it nor built anything with it so I wanted to change that.
  2. I wanted to get an idea of how hard it would be to have AeroGear’s Pipeline and DataManager features supplement a framework like Angular.

Angular.js logo

I have to say, learning Angular was pretty easy. Having much more experience with Backbone.js, there was a bit of a learning curve as Angular is more “opinionated” about how you structure your app but once you get the hang of it, it’s actually really nice. The other thing that really  helped me get off the ground with Angular is Yeoman. For those not aware, “Yeoman is a robust and opinionated set of tools, libraries, and a workflow that can help developers quickly build beautiful, compelling web apps.” ( website) Basically, Yeoman does some scaffolding, building and even previewing of your app (among other things) for you so you can concentrate on making your app cool. You should definitely check it out. Also, with the latest release, we have added AeroGear.js to the Bower registry so now Yeoman can keep AeroGear.js up to date in your project and download it for you.

AeroGear LogoOnce I got the basics of the app laid out, it was time to get to the meat of this experiment which was to incorporate AeroGear into the app. Today, we are releasing AeroGear 1.0.0.M7 which includes AeroGear.js 1.0.0.M2. In M2, some things were cleaned up from the previous milestone release, a new sessionStorage/localStorage adapter was added to DataManager as well as some more complex filtering capabilities, and the ability to read data from JSONP endpoints was added to Pipeline. I wanted to make an app that would highlight all of these new features and I settled on a mobile information site for the upcoming DevNexus conference.

AeroGear.Pipeline vs. $http

All of the info about the conference is provided via JSON, and now JSONP thanks to @summerspittman. Normally, with Angular you could use $http directly to access remote resources. What I did was created a Service which contains all of the Pipeline and DataManager instances I would need for the app and I inject that into each controller that needs it. Then, anywhere you would normally use $http, or the $http.get shortcut, to retrieve data, I use the read() method provided by the pipe associated with the data needed at that time. The API’s are actually quite similar but an advantage that AeroGear gives is that I can declare the pipes up front, then using a single Controller I can manage both the speaker and presentation data/views. This is possible because the config for each pipe has already been configured so I don’t need to update the endpoint URL or other parameters on the fly. You could do that with Angular too but to me, this feels cleaner.


The DataManager is where we get some real advantages from AeroGear. The DataManager provides a way to interact with a local copy of your data using a similar API to the Pipeline. So, once we have retrieved the data we want from the server, we can store it in memory, or in the case of this app we use localStorage which is a new feature of DataManager  with this release as an extension to the Memory adapter. Now, even when the app is completely reloaded, we can get the performance increase and http request savings of pulling our data from the local store instead of the remote source. In the future, this will also help in our endeavors to provide simple APIs for taking your apps offline as well.

The other feature added to DataManager was an improvement to the filter() method. Now, filtering on data nested deep within objects is possible. In this app, this allows us to filter presentations based on the speaker and provide proper linking between the two.

Go Play!

Here is a list of links to things you can play with now or ways to get more information. Please check this stuff out and specifically for AeroGear, provide feedback by joining our mailing list or chatting with us via IRC in #aerogear on Freenode!

JBossWorld Keynote Demo

At this year’s JBossWorld Keynote, one of the things we wanted to show was the extension of business logic and business rules into the mobile landscape. The premise of the demo was to have a mobile shopping cart app that the sales team of our fictitious company could use to purchase electronics and swag for their customers. Rules were put into place based on the dollar amount of the order placed which would then trigger one or more approvals which would need to happen before the order was placed.

Image of the Mobile AppThe app was first built as a mobile web app hosted on OpenShift using a combination of jQuery Mobile and Backbone.js. jQuery Mobile provided the structure of the app giving it a mobile-friendly layout and set of controls. Backbone.js was used to provide a clean way to handle data modeling and synchronization, presentation of that data through jQuery Mobile enhanced views as well as the app’s URL based routing. Once the app was a full-featured web app, we used Apache Cordova to wrap it up as a native app that could be installed on iOS, Android and Blackberry devices.

Whether the user was on the mobile web version or the native app, they received the same experience. The user could navigate the catalog, add and remove items from their cart and submit orders. Once an order was submitted, using a similar interface, an approver level user would see the order enter their list of orders. This user could then take control of the order and either approve or reject it. This is when our business rules come into play. After an approver approves an order, depending on its dollar amount and the current rules in place, a high-dollar order may need a vice president level approval. If this is the case, the order is then displayed on the VP’s order list and using the same process as the approver, that user can either reject or give final approval to the order. Once approved, the original order submitter’s home screen is updated to show their new approved/rejected/pending totals and with this demo, other events are triggered which update the leader board to show new totals and other useful information.

To learn about all of the other pieces that went into building this demo, check out this blog post and to view the source, grab a copy of this repo and play with it yourself! To get you started, here are a few of the main areas of the code to start exploring:

  • index.html – Very small, require.js loads the appropriate modules and gets the app going
  • main.js – This is the entry point to the application which defines the router and fires the first route
  • modules – This is where all of the magic happens. Each module represents a model and/or collection and the associated view(s)
  • libs – The external libraries used in the app including backbone.js, jQuery Mobile and others
  • requirejs – This folder includes a copy of Rhino and the r.js optimizer which takes the AMD modularized version of the app and builds and optimized production version with concatenated/minified JS and CSS files

AeroGear Wants You!

It is an exciting time right now on the AeroGear team. For those of you who don’t know, I recently (well, 4 months ago) started working for Red Hat on the AeroGear team where our goal is to provide the tools enterprise developers need to go mobile with everything from web apps, to hybrid applications, to native apps on iOS, Android and more.

That’s where you come in! We are hiring and if you have ever wanted to work for the best open source company on the coolest new technologies, this is the place for you. Take a look at this blog post for more information about the project, the open positions and how you can join the team.

Also, in the interest of supporting the open source ecosystem, JBoss/Red Hat is a sponsor of the upcoming jQuery Conference in San Francisco on June 28-29, 2012. This event has been sold out for some time now but if you want to go, we’ve got your chance.

The AeroGear team has an extra pass* to the conference and if you are in the San Francisco area or can get yourself there for the conference, make sure you are following @AeroGears on Twitter and reply to the original tweet from @AeroGears (don’t reply to someone else’s retweet) announcing this blog post saying you would like the pass and it’s yours. We only have one so it will be first come, first served. It is important that you are following @AeroGears as we will direct message the first person to claim the pass.

There are a number of people that would really like a chance to attend this conference so we do ask that you please only claim this pass if you are sure you can use it.

*This is for one pass to the jQuery Conference. The recipient is responsible for all associated expenses including travel, lodging and any other expense associated with attending this conference.

From Cloud to Mobile and Back Again with AeroGear

Monday, I had the opportunity to speak at OpenCloudConf in Sunnyvale California. I spoke about the new AeroGear project at Red Hat, of which I am a team member, and how we are developing mobile web apps and hybrid apps for JBoss AS7 and how the cloud, in specific OpenShift, play a role in that effort. This post is a brief summary of that talk for those who couldn’t make it to OpenCloudConf, those that were there but may have gone to another workshop at the same time or those that are just interested in mobile development and OpenShift.

In my talk, I gave a quick intro about the AeroGear project. Basically, AeroGear is all about making mobile development as quick and easy as possible on JBoss through community, education and innovation by creating examples and tutorials for people to use and getting feedback from users on what would make mobile development on JBoss easier for them. After that, I did a quick run-through on the tools and technologies we are currently using, a few of which include JBoss AS7, JBoss Tools, RestEasy, jQuery/jQuery Mobile and Apache Cordova. That was pretty much the extent of my slides because I wanted to dive straight into an example application and look at some of the code and techniques we use to mix mobile and cloud technologies.

The first example I did was to quickly run through the AeroGear kitchensink quickstart. Many of the JBoss projects have what we call quickstarts which are a way to quickly get up and running with the particular technology that project is using, building and supporting. Using the steps described in our Get Started with HTML5 Mobile Web Development with JBoss wiki article, I was able to show attendees how to generate a new project in JBoss Tools from our Maven archetype, start up JBoss AS7 locally on their computer and then deploy that generated project to the server and see it up and running in just a few minutes. We then walked through some of the cool features of that web app including its dual desktop/mobile features and how we use some responsive design techniques and jQuery Mobile to make that possible.

From there, we walked through how to deploy this project to OpenShift. For those who don’t know, OpenShift is Red Hat’s free, auto-scaling Platform as a Service (PaaS) for applications. As an application platform in the cloud, OpenShift manages the stack so you can focus on your code. With OpenShift, we can easily deploy our project to the cloud and have it available to the world in just minutes. And with JBoss Tools, it’s even easier because the ability to create and deploy a project to OpenShift is done in just a few clicks. You can get more information about that process in our wiki article titled Converting an AeroGear POH5 Web App to a Hybrid App with Apache Cordova.

The final example was more mobile focused. My last blog post, A Trip Through Cordova, talked about how I took our quickstart and converted it to a hybrid application using Apache Cordova. In that app, I added a very simple bit of code to display the network connection status of the device just to show that we actually had access to native device APIs. What I wanted to do for this workshop was to take that a step further and do a little bit deeper device integration and somehow tie that back to the cloud. What I decided to do was to integrate the device contacts with the member list that was being displayed and updated in the quickstart. I provided both the ability to add a member from the list to the devices contacts, as well as, populate the member registration form with information from a contact in their devices list of contacts. And because the hybrid app still uses the OpenShift hosted version for its data store, anyone who installed the app or used the web based app would have their member lists always stay in sync.

Overall, attendees seemed to enjoy the presentation and hopefully learned a little bit about how to go mobile with JBoss and OpenShift. The few slides I used for this presentation are available on my website and all of the code for the examples I presented are available at the following links:

One final important note. The OpenShift team announced the release of OpenShift Origin, the source behind OpenShift. This is really exciting and gives you the chance to see how OpenShift works and even implement your own PaaS if you want so definitely check it out!