Edify Friday: GPS Using MonoTouch Tutorial

As readers of this blog know, we at the Institute for Cyber Security are enjoying developing .NET applications for the iPhone using MonoTouch. Since GPS information is so intrinsic to privacy in cyber security, today's Edify Friday covers how easy it is to incorporate GPS data from your iPhone into your MonoTouch applications.

To start off, we'll create a new iPhone MonoTouch Project called HelloWorldGps, which gives us a simple project to start from. To keep things simple, we'll just add a button and label to our MainWindow.xib in Interface Builder. If you're unfamiliar with how to do this, there is a great  "Hello World" tutorial found on the MonoTouch site, as well as a whitepaper on using OpenTK with MonoTouch found in an earlier post. We'll call our label "label" and button "button" and give the button a "Click me" text as shown in Figure 1 below:

Figure 1: MainWindow.xib in Interface Designer

Next, we'll click on the "App Delegate" to give the label and button class outlets under the Identity Inspector, then connect the outlets to the UI elements under the Connections Inspector (see Figure 2).

Figure 2: App Delegate Identity and Connection View

That's all we have to do in the Inspector Builder, so we’ll save our file and go back to MonoDevelop. It should compile without issue.

Now we'll want to create our class that handles the GPS updates. We'll create a class called MyLocationManagerDelegate and have it extend one of the MonoTouch.CoreLocation classes named CLLocationManagerDelegate. This is what will give us our GPS functionality and will do our heavy lifting. All we'll do is override the UpdatedLocation method with a message letting us know when we've received a new location (including our first). See Listing 1 below:

using MonoTouch.CoreLocation;
using System;

namespace HelloWorldGps {
  public class MyLocationManagerDelegate : CLLocationManagerDelegate {
    public override void UpdatedLocation (CLLocationManager manager, CLLocation newLocation, CLLocation oldLocation) {
      Console.WriteLine("Found location.");
    }
  }
}

Listing 1: MyLocationManagerDelegate.cs

Finally, in our AppDelegate class in Main.cs, we'll tie everything together. We'll create a CLLocationManager member (also found in MonoTouch.CoreLocation) and in the method, we'll set its FinishedLaunchingDelegate property to our MyLocationManagerDelegate and call its StartUpdatingLocation method. Lastly, we'll add a delegate to our button so that when it is clicked, it updates our field with our location (or a "No location" message if we haven't received one yet). The AppDelegate class is displayed inListing 2 below.

// The name AppDelegate is referenced in the MainWindow.xib file.
public partial class AppDelegate : UIApplicationDelegate {
  private CLLocationManager lm = new CLLocationManager();

  public override bool FinishedLaunching (UIApplication app, NSDictionary options) {
    lm.Delegate = new MyLocationManagerDelegate();
    lm.StartUpdatingLocation();

    button.TouchDown += delegate {
      string message = "No location update yet";
      if (lm.Location != null) {
        message = "I am at " + lm.Location.Coordinate.Latitude + " " + lm.Location.Coordinate.Longitude;
      }
      label.Text = message;
    };
   
    // If you have defined a view, add it here:
    // window.AddSubview (navigationController.View);
    window.MakeKeyAndVisible ();
    return true;
    }
  }

  // This method is required in iPhoneOS 3.0
  public override void OnActivated (UIApplication application) {
  }
}

Listing 2: AppDelegate class in Main.cs

Don't forget to include using "MonoTouch.CoreLocation;" at the top of Main.cs. At this point, our code should compile without issue, and if we compile and run, the iPhone Simulator should fire up, and once the GPS begins broadcasting a message, the application should give you a location similar to Figure 3 below:

Figure 3: GPS Data in your iPhone

That's all there is to it!

Got a topic that you'd like to see covered in Edify Friday? Leave a comment below or email me!

Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu

Edify Friday: Python and .NET Interoperability

At the Institute for Cyber Security, we use develop mobile applications and use Python and .NET Framework for our startups in incubation or in‐house projects, and every once in a while, we need to have them interoperate.

Today's Edify Friday covers how simple it is to use .NET code, either in the framework or in-house, in a Python application. It makes use of the Python ctypes library, allowing one to call functions in DLLs. In the example we walkthrough, we call the MessageBoxA function from WinDLL.

First, we "import" the libraries and Windows types we need. The function prototype WINFUNCTYPE is Windows-only; there are others for Python and C. Next,for ease of use, we're going to create a prototype of the MessageBoxA function, where the first parameter is the return type (MessageBoxA returns an integer) and the remaining parameters mirror MessageBoxA's parameters.

After we create the prototype, we can set named parameters in the usual Python style, giving default values for them if we like. Finally, we'll save this prototype to a variable (think delegates from .NET) we call MessageBox, giving it the class MessaBoxA belongs to, and its parameters.

The example below puts it all together in Python 3.1:

Figure 1: Windows Message Box in Python

Got a topic that you'd like to see covered in Edify Friday? Leave a comment below or email me!

Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu

Edify Friday: Introduction to MonoTouch Development Using the OpenTK Package

We at the Institute for Cyber Security develop mobile applications and use the .NET Framework with for startups in incubation and our in‐house projects, so when MonoTouch was released last week, it seemed like the perfect marriage of those skill sets. Naturally, as we learned more about it, some things were straightforward and other things left us wanting to learn more. This seemed like the perfect time to introduce a new feature to the ICS Blog: Edify Friday, where we'll take a topic related to cyber security, application development, or technology startups and flesh out a walkthrough or tutorial.

Today's Edify Friday is in whitepaper form and covers how to use the OpenTK package for MonoTouch deployment (click here to read).

Got a topic that you'd like to see covered in Edify Friday? Leave a comment below or email me!

9/28/2009 Update: The whitepaper has now been updated to include a second example using the iPhoneOSGameView class, which greatly simplifies graphics programming. An animation example is now included.

Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu

PowerPoint with SmartArt, and Other Videos from "Office Casual"

At the Institute for Cyber Security, our architects and developers have the opportunity to present their ideas to a in a number of venues, whether it's for our security startups in incubation, meetup groups and conferences, and even internal project updates. Suffice it to say, we present a lot of PowerPoint slides, and maybe you do, too!

While checking out blogs.msdn.com I came across this video from Office Casual on how to translate your ideas to slides better and thought it was worth passing on to my staff. The videos are short and a little zany, but Doug Thomas from Microsoft covers everything from slides to resume building to SharePoint, generally using Microsoft Office as a platform in a unique way, and it's definitely worth checking out.

Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu

The Basics of Base64

At the Institute for Cyber Security, much of our work with our startups in incubation or research involves transmitting data using Base64. Whether in the form of files or images, data between machines with incompatible data definitions, or encrypted information, Base64 is used almost as a de facto standard for content transfer encoding.

Almost any high-level language will has a library that will encode and decode data from Base64 and back, but it's worth knowing the underlying principle behind the transform. The way it works is simple: whether text, image, or encrypted information, every bit of data is a number stored in memory. By reading that data in blocks of six bits (2⁶ = 64) and mapping each number to a character (0 = 'A', 1 = 'B', and so on, until 62 = '+' and 63 = '/'; see the figure up above), binary data of any size can be encoded into a string. See Figure 1 for an example, taking a string to its constituent bytes, then reading each group of six bits into a new Base64 character:

Figure 1: Encoding "Hello!" in Base64

Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu

Implementing the Decorator Pattern in AspectJ

Last week we covered how we'd implement the decorator pattern in Java to solve how to modify the behavior of an existing class without modifying or subclassing it. It turns out that implementing this behavior is even simpler in AspectJ.For a refresher on the decorator pattern, read the preceding post.

As before, say we have a Car class which has some functionality we'd like to modify, say by adding a top to the car or an engine. Listing 1 shows a Car interface and SimpleCar class.

Listing 1: Car Interface and SimpleCar Class

To add a top or an engine, we'd need separate classes for each functionality, and an abstract class that they extend. But instead, we can just add two aspects (see Listing 2).

Listing 2: TopAspect and EngineAspect Aspects

Each aspect modifies the code so that it performs some behavior prior to calling drive(), and it modifies the getInfo method. Both aspects total twelve lines of code (not including braces), whereas the equivalent code in Java totals nearly double the lines at twenty-two.

We can view the results of the Decorator pattern by calling the getInfo method, which should return "car, with top, with revved engine".

Listing 3: DecoratedTest Class

Line three is very straightforward, whereas the equivalent line in the Java-only implementation is a bit more convoluted, as each constructor must be called for each class. For multiple classes, it can be quite unwieldy.

This is a bit perfect example of using AspectJ's interception capabilities to add a crosscutting concern. In a more realistic example, Car could be a communication class, and TopAspect could be a logger, while EngineAspect could be an encryption engine. In this way, Car could be written without "concern" for logic unrelated to itself, and these new aspects could be added later.

Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu

Implementing the Decorator Pattern in Java

At the Institute for Cyber Security, our software architects help fulfill the role of CTOs for new security startups, and will work with development teams to come up with technical solutions to existing development problems. In one recent example, one developer had to modify the behavior of an existing code base but could not modify the code due to licensing.

Normally, the solution is to subclass the original class, then add your behavior as necessary. However, in this case, the class was finalized, meaning the class could not be inherited. This stumped our intrepid developer--surely someone must have solved this problem before!

In software engineering, a design pattern is a general reusable solution to a commonly occurring software design problem. As you may have surmised from the title of this post, our architect recognized the issue and recommended the decorator pattern. This allows new behavior to be added to an existing class dynamically (assuming some design work had been done in advance) as an alternative to subclassing.

The decorator pattern is achieved by designing a new decorator class that wraps the original class. This wrapping could be achieved by the following sequence of steps:

1. Create an interface and the base "component" class that implement it.
2. Implement the interface into a "decorator" class.
3. In the Decorator class, add a Component "pointer" as a field;
4. Pass a Component to the Decorator constructor to initialize the Decorator's Component;
5. In the Decorator class, redirect all "Component" methods to the internal Component pointer and override any Component method(s) whose behavior needs to be modified.

This pattern is designed so that multiple decorators can be "stacked" on top of each other, each time adding a new functionality to the overridden method(s).

The above listing is best demonstrated by example.Consider the following: we have a Car class which has some functionality we'd like to modify, say by adding a top to the car or an engine. Listing 1 shows a Car interface and SimpleCar class.

Listing 1: Car Interface and SimpleCar Class

To add a top or an engine, we'd need separate classes for each functionality, and an abstract class that they extend (see Listing 2):

Listing 2: CarDecorator, TopDecorator, and EngineDecorator Classes

Using Listing 3, we can view the results of the Decorator pattern by calling the GetInfo method, which should return "car, with top, with revved engine".

Listing 3: DecoratedTest Class

In some dynamic languages, this can be more easily achieved, but in Java, this seals the deal and our developer was able to walk away, not only with a solution to his specific problem, but with a broader understanding of design patterns in general.

Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu

Aspect-Oriented Programming and AspectJ

At the Institute for Cyber Security, we use many different technologies to help accomplish our goals at ICS Labs and the Incubator. One such technology is Aspect-Oriented Programming (AOP), a programming paradigm allowing the separation of cross-cutting concerns from core concerns. Although many software frameworks such as Spring allow for limited aspect-oriented development, I've always been fond of the AspectJ language as it provides a better pedagogy for aspects and how they differ from objects.

Object-oriented programming (OOP) guides developers into exploiting the expressive power of the object model and uses classes as their fundamental building blocks. Generally, classes may be too specialized for general “drop” reuse, are "tangled" (implementing many requirements of a system), or are used in many places ("scattered" in many classes), such as security or session expiration mechanisms.

Because scattering and tangling defy the OOP paradigm, they are symptoms of “crosscutting concerns”, as they cut across many modules in a program. AOP is an attempt to corral these naturally, with aspects being well-modularized crosscutting concerns. Gregor Kiczales and his team at Xerox PARC originated the concept of AOP and its most popular general purpose language, AspectJ. AspectJ is the most well-known and is a superset of Java (i.e., all AspectJ programs compile to Java bytecode).

In AOP, points in the code where we would want to run our code (instead of writing it in the class itself) are called "join points". A join point can be almost any line of code—a method or constructor call, a field get or set, object initialization, or exception handler execution. AspectJ intercepts program execution flow at these join points and runs the code we want to run instead, called advice, which can happen before, after, or instead of the join point. An aspect describes these join points as pointcuts, which can describe one or more join points.

An example Java program using a simple logging mechanism is shown below. In MainClass.java, two methods are being called, and with code from Logger.java being executed when each method (save the main method) is entered and left.

MainClass class (left) and Logger aspect (right)

In the AspectJ program below, any reference to logging in MainClass.java is removed. In place of the Logger class, the Logger aspect encapsulates the logging concern. It has one pointcut called SayAnything that describes all join points that are methods being called (using the call keyword) that starts with “say” and has any number of parameters. Two advice are associated with the pointcut. The before advice gets the signature of the join point it is in, and prints “Entering” with the signature’s name. The after advice does the same, printing “Leaving” with the signature's name instead. Thus, whenever any of these join point is reached in the execution of the program, it calls the code in the before advice, executes as normal until the end of the join point, and calls the after advice.

MainClass class (left) and Logger aspect (right)

At compile time, the compiler "weaves" the code from an aspect’s advice into the join points their pointcuts describe, leaving .class files that any Java runtime may execute. Because aspects are a superset of classes, they can contain members and methods, and can even extend other aspects or classes, although classes cannot extend aspects. Also, aspects can be quite powerful, able to read and process code with around advice, affecting the execution of the program at runtime in dynamic and very interesting ways. By the same token, AOP and AspectJ's power lend itself to augment code outside its boundaries, possibly leading to software contract-breaking. Like in any paradigm, a little knowledge is a dangerous thing (but a little more knowledge can do wonders).

For more on AOP and AspectJ, the seminal paper on AOP is a great start. There is also a classic series of tutorials on AOP by Ramnivas Laddad online.

Picture at the top shows the difference between core and corss-cutting concerns, pulled from an older version of Apache Tomcat. Red shows the relevant lines of code. The XML parsing capability of the project is well-modularized in one file, whereas the project's logger is used in a large number of places.

Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu

Windows Azure Hello World Tutorial Online

Cloud computing has become a larger reality in web development in the last few years. Units such as Amazon's EC2 Service and Google's App Engine let web developers write web applications that do not reside on a dedicated server, but may move from one physical machine to another (for load balancing purposes) or be "spread" across multiple physical servers (or both). At the Institute for Cyber Security, some of the companies under incubation make use of such services due to cost and ease of use.

Not to be left out, Microsoft has its own cloud computing service it is hoping to deliver to customers in the coming months called Windows Azure. Still in beta, Microsoft offers an SDK and tools for Visual Studio. To some degree, getting an application up and running on Windows Azure is fairly straightforward. Check out the Windows Azure Hello World tutorial online.

Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu

ICS Startup SafeMashups Inc. Adobe Flash Demo Tutorial Online

SafeMashups, Inc., the latest startup from the Institute for Cyber Security to go live, has released a new tutorial on mashing Adobe Flash applications with MashSSL on its YouTube channel. Other demos on mashing MashSSL with OpenAJAX, Kerberos, OAuth, and Cross-Domain XHR, and more can be found there, too.

Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu