How to learn XML, HTML or for that matter anything in Programming

Over the last several years I continued to buy books on XML and HTML, and all of them went unread. This year I did end up learning both XML and HTML but NOT by reading books but by programming. In my recent hacking & prototyping projects with IOS and OSGi I had to use XML and HTML to exchange information between devices. I had to read and learn how to use NSXMLParser in IOS, it came with an excellent companion guide – “Introduction to Event-Driven XML Programming Guide for Cocoa” which was useful reading. I leveraged the hpple XML parser. Note the real learning came from my own programming, not from the tutorial or examples from books or websites. The real trick to learning XML and HTML was to understand how they are defined by observing the code working, iterating through several failures before I met with success. 

My 2c – yes read a programming, follow tutorials and examples from websites but the real learning comes when you embark on your own project! 

 

Footnotes:

– Google Search, Stack Overflow, Github and many other sites also serve to accelerate your learning only if you understand the solutions put forth by the community and adapt it to your own project. Blind copying never helps!

– Github is awesome!!!

– hpple is a great resource, I learnt the basics from the Ray Wenderlich tutorial: How to parse HTML on IOS by Matt Galloway 

Advertisement

OSGi Bundle Management Code [Part 4, ROM]

In the part 4 of my series I am going to describe the OSGi/Java code on the Plug Computer that implements the bundle manager in the ROM (Remote OSGi Manager) project…. and one of the best parts of doing this particular portion was that I started getting a much better understanding of the XML fundamentals. Notionally I always understood XML, but this was my first time programming with it.

At the simplest level – there is an OSGi bundle that receives network command over a Sockets Interface from the IOS app or a Java Test app, and then performs the appropriate action. These commands are all listed in the overview post. And I did get some good help from my Java programming friends to implement the entire interface along with the Java test application that I used to test the interface and responses. First step to start a TCP server, here is the code snippet to accept a incoming connection and spin it on a new thread:

try {

ServerSocket ss = new ServerSocket(port);

ss.setSoTimeout(soTimeout);

System.out.println("\nSocket Server listening on port "+port);

while (stopFlag == false) {

try {

Socket s = ss.accept();

clients.addElement(new Worker(s,bc));

System.out.println("Worker Thread Created");

} catch (Exception ignore) {

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

}
}

One challenge, that I faced later, was the decision to use UTF8 functions in Java to avoid network ordering issues. This did create problems during the IOS app but it was a good learning experience that was overcome using Google Search and Stack Overflow. The spawned worker thread handles the commands using Switch/Case flow:

public void run() {

String message = null;

String content = null;

int option = -1;

int BId = -1;

String file = "";

try {

message = dis.readUTF();

System.out.println(message);

if (message != null)

option = Integer.parseInt((message.split(","))[0]);

BId = Integer.parseInt((message.split(","))[1]);

file = message.split(",",3)[2];

System.out.println("Recd packet from client Option:"+option+" BID:"+BId + " file:"+file);

} catch (IOException e1) {

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

}

//System.out.print("message: "+message+"\n");

DoOps getb = new DoOps();

switch (option){

case LIST_BUNDLES:

content = getb.getBundleList(bc);

break;

case GET_BUNDLE_INFO:

content = getb.getBundleInfo(BId, bc);

break;

case STOP_BUNDLE:

content = getb.stopBundle(BId, bc);

break;

case START_BUNDLE:

content = getb.startBundle(BId, bc);

break;

case UPDATE_BUNDLE:

content = getb.updateBundle(BId, bc,file);

break;

case SYS_INFO:

content = getb.getControllerInfo(bc);

break;

case INSTALL_BUNDLE:

content = getb.installBundle(bc, file);

break;
}
    try {

    dos.writeUTF(content);

    dos.flush();

    dos.writeBoolean(true);

    this.stopWorker();

    s.close();

    return;

} catch (IOException e) {

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

}
}

All the commands are implemented in the Class DoOps, which perform the command and return the result. The first two commands above in the Switch/Case statements are returning XML schemas. The List of All Bundles returns all the bundles as XML content and the Get Bundle Info returns details of the requested bundle using an XML schema as well. Here is the XML schema/format for the List of Bundles:

<?xml version="1.0" encoding="UTF-8"?>
<bundles>
<bundle id="0">
<name>name of bundle</name>
<status>ACTIVE</status>
</bundle>
</bundles>

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.