Year In Review: Programming

Beginning of the year I embarked on a getting back in touch with my programming skills… and this year has been really successful. Here is what I accomplished, over the weekends and late nights:

·         I programmed extensively in first of half on the year on IOS, especially IOS5 and iPad. I still need to work on my design skills but I covered a lot of ground Table Views & Controllers, Storyboards, Network Programming, XML parsing, Notifications, Pull To Refresh etc.).

·         I refreshed my programming skills in Java by programming in OSGi Embedded environment…

·         And to complete my journey – I signed up for courses with edX and Coursera on Cloud Programming. I would have liked to do a project or two of mine but I had to be satisfied with the assignments and the tests that were done as a part of the course. I ended up learning about R, Ruby and Rails. I had signed up for a few courses but the three that I completed were:

o   CS169.1x Software As A Service @ edX

o   CS169.2x Software As A Service @ edX

o   Computing for Data Analysis @ Coursera [Data Analysis using R]

Advertisement

SSDP Service using Java/OSGi [Part 3, ROM]

In the last part I talked about how I implemented the SSDP code on the IOS app, to make my device discoverable – it has to be running the “SSDP Advertiser” – or a server that is listening to discovery messages.

The SSDP service runs as a thread when the OSGi bundle is installed and started – “AdvertiseServiceSSDP()”. [The call before that – SocksServer is the class that implements the network interface between the IOS app & the Plug Computer as explained in the project overview.

public void start(BundleContext bc) throws Exception {

    this.bc = bc;

    nServer = new SocksServer(bc);

    advtROMService = new AdvertiseServiceSSDP(bc);

  }

Here is the SSDP code:

public void run() {

String msg = "LISTEN-FOR=THIS MESSAGE";

String chkResponse = "RESPOND-WITH-THIS-MESSAGE";

try {

int port = 1900;

InetAddress listenSSDP = InetAddress.getByName("239.255.255.250");

MulticastSocket ms = new MulticastSocket(port);  // Create socket

ms.joinGroup(listenSSDP);

System.out.println("\n Rcvr started, Ready to Receive... \n");

boolean match = false;

do {

byte[] response = new byte[256];

DatagramPacket rspPkt = new DatagramPacket(response, response.length);

ms.receive(rspPkt);

//System.out.println("\n Done Receiving!\n");

String getResponse;

getResponse = new String(rspPkt.getData());

match = getResponse.regionMatches(0, msg, 0, msg.length());

if (match)

{

System.out.println("Controller found\n");

// Send Response

InetAddress IPAddress = rspPkt.getAddress();

byte[] sendData = new byte[1024];

String sendResponse = chkResponse;

sendResponse += IPAddress.getHostName();

sendResponse += "/:portAddr";

System.out.println(sendResponse);

sendData = sendResponse.getBytes();

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 1900);

ms.send(sendPacket);

System.out.println("Response Sent");

match = false;

}

} while(match==false);

} catch(Exception ignore) {

System.out.println(ignore.getMessage());

}

}

The above code when running on the Plug Computer(s) allows the IOS app to discover them. Of course the beauty is that this will work for all devices that support OSGi/JVM and have multicast networking support.

SSDP Service/Device Discovery [Part 2, ROM]

To begin my project – a Remote OSGi Manager (ROM) as described in my first part here, the first task I picked up was to try developing  a very rudimentary app that would discover the RTCOA Thermostat using the SSDP protocol. As you can see from the screenshot – it is really rudimentary user interface but my focus was to get my MVC right, and more importantly get the network interface going for the project. [BTW if you observe carefully – you can see the “Marvell” code that has been used in the RTCOA Thermostat].

 

 

 

After much searching and reviewing samples, I decided to go with the Cocoa Async Sockets, and I have ended up using them for all of the network interface in my iOS/iPad app. I got started with the AsyncUdpSocket to leverage it for running SSDP based discovery of the RTCOA Thermostat. The screenshot above was the start. I took the SSDP objects (serviceSSDP.m, serviceSSDP.h) and moved them to the bigger project. Also as a first step – the SSDP discovery code stopped after discovering the first controller. Given that in my project I was going to support multiple controllers, I ended up modifying the code to take into account that I should be able to discover multiple controllers (or devices) and then add them to a NSMutableArray.

 

 

//

//  serviceSSDP.h

//  SimpleSSDPDiscovery

//

//  Created by Ashu Joshi on 3/1/12.

//  Copyright (c) 2012 Movinture, LLC. All rights reserved.

//

 

#import <Foundation/Foundation.h>

#import “AsyncUdpSocket.h”

#import “connectedLifeController.h”

 

@interface serviceSSDP : NSObject

 

// This is the string that is Multicast to Discover the Controller

@property (strong, nonatomic) NSString *discoverControllerString;

// The Controller would respond with the string below upon discovery being received

@property (strong, nonatomic) NSString *responseStringFromController;

// The list of discovered controllers

@property (strong, nonatomic) NSMutableArray *controllerList;

 

@property (strong, nonatomic) connectedLifeController *currentController;

@property (strong, nonatomic) AsyncUdpSocket *ssdpSocket;

 

– (BOOL)startControllerDiscoveryProcess;

– (BOOL)startControllerDiscoveryProcess:(NSMutableArray *)listOfControllers;

@end

 

Once I got the Thermostat to discover using SSDP discovery code using iOS/iPad, I turned my attention to the Plug Computer. I created the framework for my bundle (OSGi terminology for an application). And the first thing I did was to implement code built out code in Java to run a SSDP “advertise” service on the Plug Computer. Before even migrating or trying the code on the Plug Computer I tried the code on my PC/Mac using Eclipse, once it was working I migrated it as a bundle/service in the OSGi framework on the Plug Computer. This code uses threading so that it is always running on the Plug Computer.

 

In the next part I will give an overview of the Java/OSGi code and the network interface implemented….

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.

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