Getting Started: IOS-based OSGi Application Manager

I am going to provide more details on the project that I have in of the earlier posts. The objective of the project is to build a network interface between an iOS application & a device running OSGi (it could be any device running OSGi since that lends to portability but I am going to start with a Plug Computer). And using that network interface/protocol  the IOS/iPad application would function as a “Remote Manager” to the Plug Computer. Obviously all code on the Plug that interacts with the iOS/iPad app would be developed in OSGi/JVM.

I had started doing some preliminary design work and thinking through in late January, and to prepare spent last two weeks of December (2011) getting my coding skills comfortable with both Java & iOS/Objective-C. The approach was to build the project incrementally, baby steps at a time. The key was to define the network protocol/interface between the iOS App & Plug. The interface by itself was very simple but I had to decide what it would do and more importantly in the first iteration what it won’t do.

Here is a simple diagram illustrating the protocol/interface, and I had decided to use a Sockets Interface between the iOS and Plug. The Plug and the iPad are both on the same network/subnet.

Using sockets was my first decision – in my next iteration I would move to a REST API between the two. I can comfortably say 3 months into it that the design & implementation is flexible enough where my “network interface” code on both sides is separate from the actual command processing. The next couple of decisions were also what not to take on in the first round of implementation – no TLS/SSL sockets and no authentication. I would take that on once I have the entire interface working. In addition there is no authentication or provisioning for the iPad/iOS app – that is – I have not built in any authorization check before the iOS/iPad app would be allowed to access the OSGi information on the Plug computers.

Advertisement

The Power of Three

There was a time when building a technology product and its functionality was largely contained into itself – ing was an island was perfectly fine. This was true of both enterprise and consumer products. A Set Top Box (STB) had no need for interactive functionality least of all a “companion application”, or a Thermostat in the house was manually operated. The rise of smartphones, increasing connectedness have changed that. The paradigm has changed. When products are designed and developed – it is no longer just about the hardware & software of the product you are building – it is equally important to design interactivity with a smartphone or tablet application and tying the functionality of the product with cloud services. And as I outlined in one of my previous posts – my re-engagement with programming & development would be at the “intersection” of the three elements:

1. Technology Product

2. Smartphone | Tablet Application

3. Cloud Services

This is what I mean by the title – to deliver the best product experien

ce – the product strategy and planning has to be done keeping the three elements in mind – to bring together the  Power of Three. The challenge I had was wh

ere to get started because each of these areas offers attractive options. I had to filter them – and the primary one was that I wanted to make sure that it did not impede or conflict with my day job. So when I started about three months ago I had to stick to products, technologies that are available to mostly anybody and available openly without requiring any NDA. And here are the choices I made:

1. To use a proxy for the ‘technology product’ – instead of choosing a STB or a Gateway (and I have tons of product management experience in both) – I chose an embedded Linux-based device or server – a Plug Computer. It supports an ARM version of Debian or Ubuntu. And for creating applications on the Plug – I chose to go with OSGi running on open so

urce JVM.

2. The choice for Smartphone or Tablet applications was fairly easy – I chose IOS. And I specifically wanted to focus on programming with the large real estate screen of the iPad. Down the line I may expand this to support two more options – Android Smartphones and GoogleTV…

For Cloud Services – I have two choices Google App Engine or Amazon Web Services – but that the choice is still open…

Let me quickly talk about the application I have in mind though or rather what functionality I want to implement. I am going to write basic code on the Plug Computer that would support a network interface to collect data, diagnostics from the Plug by the IOS App. The code not the Plug would be (or is begin developed) using OSGi/JVM. I intend to incorporate addition to diagnostics, use the Plug to connect to some basic sensors such as Accelerometers or Zigbee Switches and using the network API to communicate the data/events gathered to both the IOS app and the Cloud. As I write this I have made good progress on the initial stuff so far and my subsequent posts would talk about them. But I do have a long way to go, and I am looking forward to it….

[Note: Attached a couple of sketches to illustrate my concepts using the great new Paper App for iPad.]