Learning about iPhone development without the desire for money

The other day I was talking to a friend of mine who was interested in using SSL to encrypt a socket. The socket would be open between his iPhone App and a dedicated server, and was currently unencrypted but fully functional.  He already had the client code for OpenSSL (using something like AsyncCocoa) but needed SSL code for the server.  A bit interested myself, I decided to investigate OpenSSL, and see just how easy it would be to encrypt a C socket with SSL, using OpenSSL or any other library.

After doing minimal research, I found OpenSSL functions that make SSL negotiation over a file descriptor a five-line process. The functions were basically SSL_accept and SSL_connect, along with other ones that create SSL pointers and contexts. Since OpenSSL is a C library, I found that a lot of my Objective-C code involved calls to magic free functions, which happens to be quite amusing while coding in a high-level language like Objective-C.

I ran into some trouble getting OpenSSL to compile, but eventually figured out that you need to set the -lssl compiler flag in order to get libssl to link with your executable. Originally I was trying to use -lcrypto, which does not include the functions that I was using. As it turns out, OpenSSL is a pretty good library, and is apparently the #1 SSL library that everyone loves.

All in all, I created a few Objective-C classes for accepting and opening network connections, as well as a class for encrypting all network communication through SSL. The code, along with more detail on the project can be found at SocketKit on Github.

For everything that a person learns, there are stages of development that exist in the process of learning. For children, Paiget created a scale that accurately measures the stages through which every individual passes through in their childhood years. For programmers, there is a similar scale that I have found that applies to pretty much everyone. In this article, I will briefly outline all of the stages of development that I thought of:

Pre-Operational–This is the stage in which the developer does not understand sequential operations. A person in this stage wouldn’t understand something like Auomator on Mac, and definitely wouldn’t understand the basics of any programming language (except for markup languages.)

Sequential Comprehension–The stage in which a programmer understands that the computer will execute lines of code in the order that they are written. Someone in this stage might be able to code in Java, C, or anything else, but would not understand functions or jump statements.

Variable-Comprehension–This is when the developer can understand variables, and the concept of storing values in variables.  A developer in this stage understands how to replace expressions with variables, and the other way around.

Fully-Operational–This is the stage in which a developer can create programs that use functions. Someone in this stage can create most things possible in C, but cannot understand Object-Orientation.

Object-Oriented–As the title might give away, this is the stage in which the developer can create programs with classes. Someone in this stage doesn’t understand abstract classes.

Fully-Objective–This is the stage in which the developer can fully understand anything that the Java programming language has to offer.

I personally feel that I am on the Fully-Objective stage.  There are probably more stages that I have yet to pass through, that I will add to this article if I discover them.  If you have any opinions on this article, please leave a comment.

These past few months have been quite enlightening to me. I have learned much about OSCAR, and Jabber, two IM protocols used every day. After learning about these protocols, I have come to the conclusion that there needs to be a new IM protocol. This is why I decided to write the JIMP protocol, which emphasizes ease-of-use for the developer.

The name “JIMP” stands for Jitsik Instant Messaging Protocol. Before I started working on either the server or the client, I made a pretty good outline of what I want the protocol to be like, and posted it here: JIMP Protocol. Once I had the protocol outlined, I started to work on a client and a server.

Since I wanted to try something different for this project, I am creating the server entirely in Java. This will allow it to run on any platform that I please, and makes the development very smooth and easy. I am writing the first client in Objective-C for Mac OS X. This client so far allows sign-up, login, and is well on its way to displaying the buddy list. I am developing the server and the client simultaneously, which is actually good since I can make changes to either one if I need to.

Once I am finished with the basic client and the server, I am going to spiffy up the client, and release it to the Mac App Store. Since the App Store allows anybody to stumble upon your app, I hope that one or two people will try out the client, and tell their friends. After I release the Mac app, I am probably going to work on a libpurple plug-in for the protocol, and release a Pidgin plug-in for it.

As you may know, I have recently been working on an OSCAR library for any objective-c platform.  During this process, I have grown to despise OSCAR, simply because of its complexity, and its unnecessary components.  I decided to have a look at some alternatives to AIM, including Jabber.  Jabber is an open, XML based chat protocol.  It allows buddy lists, file transfers, typing events, and all of the other good features that I could already get from AIM.  The issue with Jabber is that it must be hosted somewhere, unlike AIM which is hosted on AOL’s dedicated server.

Instead of finding a large existing server, I decided to host my own server.  In order to do this, I followed the instructions on this page. I used Openfire, an easy-to-install Jabber server. Unfortunately, it uses Java, which led me to have to install Java6. After I got everything up and running, I opened port 5222 on my firewall so that remote users could use my server. I had to disable Open SSL encryption so that iChat and everything else properly worked with it, but I ran in to very few issues.

Although Jabber is not a total alternative to AIM (since it doesn’t have video chat, screen sharing, etc), it is cool to be able to host your own IM server. My friends and I are definitely going to be using Jabber to IM each other more often, even though it probably won’t completely replace AIM.

As many of you probably do not know, AOL Instant Messenger uses a protocol called OSCAR to transport your IMs, manage buddy lists, etc.  This probably doesn’t mean much to the average user, and it shouldn’t need to.  When you start writing IM software using Libpurple, the protocol seems like it couldn’t possibly be bad, because Libpurple makes it ridiculously easy to use.  I have been recently working with someone who is making an IM application for the iPhone.  The app itself just connects to a linux server that uses Libpurple for AIM and other protocols.  Anyway, I thought it would be interesting to write a native OSCAR library for the iPhone, just to learn more about the protocol that I use every day.

I found this process harder than I was hoping, because it turns out that AOL does not like documenting their protocol.  Even thought the O in OSCAR stands for open, the protocol itself is not open.  A few years ago AOL released documentation for their protocol, but that documentation is no longer available to average users.  It also seems as though AOL has stopped giving out API keys, which is a huge problem.  The wikipedia page for OSCAR has a few links, one of which to the archived OSCAR documentation that used to be on AOL’s website.  I used this to make the entire authorization phase of my OSCAR API work.  The authorization process involves making an HTTP request to AOL’s server, which gives you back a cookie.  You then use that cookie to connect to a BOS server, which allows OSCAR.  For the API key that their HTTP library requires, I ended up just snagging one from Libpurple.

Figuring out the building blocks of OSCAR was easy enough.  It took me about a week to figure out that the “request ID” on a SNAC packet can be random, but cannot have the highest bit set.  This caused my API to work about an 8th of the time, but once I figured it out, the sign-on process was easy to complete.  Right now the API can do this, and maintain the connection forever.  It also manages to fetch the buddy list data, or as AOL calls it, the feedbag.  I am currently working on a set of classes to parse the feedbag, which will then allow users of my library to read the buddy list.  I have not even started to think about messages, but I will definitely have to get to that eventually.  The code for it right now is only on my computer, and I don’t plan on making it open source until I get everything to work properly.  Once I have finished it, I do hope to see a lot more IM apps on the app store!

Anyway, the title of this article suggests that I think OSCAR is a bad protocol.  This is because it frankly is.  OSCAR has lots of unneeded stuff, and a lot of stuff that could be done much better.  I am not saying that it’s not useful, but AOL certainly could have done it better.  Until I actually finish my API, I can’t really bash the protocol that much, because I don’t know everything about it.

The other day I started working on an image editing app for iOS, which uses ANImageBitmapRep to scale, crop, rotate, and invert images.  Unfortunately, I wanted my app to support rotation of any angle.  CoreGraphics comes with a CGContextRotateCTM function.  Unfortunately, this function rotates the image around the bottom left hand corner, moving the entire image off of the screen.

To counter this, I had to translate the context so that it’s center moves back to the center of the screen.  To achieve this, we have to apply some simple trigonometry.  Before we continue, we have to consider the image below:

From that we can note that p will represent our hypotenuse, which is equal to the square root of (w 2)² + (h/2)².  Let newAngle be the amount we are rotating the CTM.  The x coordinate of our center origin will be equal to p * cos(newAngle + 45).  Note that we have to add 45, because by default newAngle is 45 degrees, since the center of the rectangle is at 45 degrees of the bottom left hand corner.  We can subsequently figure out the y coordinate using the sin() function instead of the cos() function.

Once we have the coordinate of the new center, we can use CGContextTranslateCTM to move that point back to the center of the context.  This then allows us to rotate the context, and draw our image back into it.  Once I had all of this together, I created a method on my ANImageBitmapRep class which allows for easy rotation.

As a mac user, I have finally come to realize that there is a standard for mac applications, and more specifically their GUI. Even though Apple has a library for easily making applications for the Aqua design, most expected eye candy is not included in their standard library. This includes gradient switches, menu bars, glossy buttons, glow on everything possible, etc. I decided to make an application with as nice a GUI as possible, and see how it felt to program.

After using a few apps from the Mac App Store, I had a pretty good idea of what a good app should look like. It took me a long while to realize this, but just because it is not in Apple’s Cocoa library does not mean you should not use it. In fact, there are a few UI components in Apple’s library that they do not use themselves, which is a great shock to me. Ultimately, if you want your app to have a good GUI, it seems to me that you have to slave over every detail, making every inch of the interface perfect.

I started out by making a side menu, such as that in Finder, iTunes, Mail, and pretty much every other app that comes with the mac. I first really noticed this when I downloaded Alfred from the Mac App Store, which had a menu bar just like this in its preferences. Seeing this, I wondered if Apple had some sort of API for this kind of thing, but my searches came up negative. I then went on to recode this menu bar in Objective-C, Cocoa, and of course, I used CoreGraphics.

A semi-standard side menu

The thing to note about making something like this is the attention to detail that you must make. The general idea is quite simple, you just need a gradient over an icon, and of course some text. The difficult thing that you don’t consider is focus. When the window is deselected, you have to make everything change. You will notice that when you deselect a finder window, the text, blue color, and everything else on the left changes to gray, and gets slightly darker.

Another thing that I implemented, which is not quite worthy of a screenshot, is a gradient slider.  I saw one of these in the safari extensions preferences pane, and thought it would be a cool thing to implement. I originally considered using a checkbox, but I then decided that something as small as a simple check box would not represent the significance of the flag that was being set. Thus, if you want to enable hidden file showing through my app, you can use a large, extravagant gradient slider.

There are a few other nice things that I created, before I finalized an app that utilized all of these UI features.  Since I did not want to have to write any additional functionality, I made a mash of a ton of different mac utilities I have made in the past, putting them into one application.  I am not saying that this app has a perfect user interface, but it certainly does use custom drawing more than most basic mac applications.  The app I created is called FileTools, and can be downloaded from the macheads101 website.  The source code is also available on my GitHub page, under the Mac-Utils repository.

Another thing to note about this application is that I implemented an update framework called Sparkle. This framework has become pretty standard in mac applications, and is really easy to use. This means that I never have to update the executable that is sitting on macheads101.com, because it will ask you to update once you open it.

Today I was using terminal a bit, and noticed a feeling of helplessness. One of these, is configuring the Dock. Everyone uses the dock, whether it be for launching your apps, or conveniently stacking your folders. Since I have been short of things to program recently, I took on the task of making a terminal command to modify and read the dock.

The command had to have three options: list, add, and delete. List gives you the index of an app on the dock, its name, and its path. Add does what it sounds like, it adds an application to the dock. The delete command takes an index for the item to remove. Although the utility is not rich with features, it is very cool to be able to get a glimpse of something that you would see through the GUI, using terminal.

The way the command works is by reading/writing the preferences file com.apple.dock.plist. This file is encoded as a PList, so I use the NSDictionary class to actually manipulate and process it. There were several attributes which I needed to compute randomly or semi-randomly, but I will not go into those.

As one who always loves GitHub, I bet you can guess where I posted the code. It’s a simply, one class and one main.m program, which is not hard to understand. To install it as an actual command, just copy it into /usr/bin, or any other directory in your path. Oh, and I bet you were wondering where the github link is! Well here it is!. I put it is one of many projects in the Mac-Utils repository, so you can download it’s source code alone as dockrw.zip.

Today I found myself wondering a question that not many people have. How do drawing engines such as OpenGL and CoreGraphics manage to draw polygons? Every polygon is based off of triangles, so it’s easy to draw any geometric shape with triangles. But how do you draw triangles at all? Using the math that I know, I couldn’t figure out a good way to do it, until I started thinking about it.

My original idea was to take the three sides of a triangle, and draw a ray from each of them. I would make it so that I only draw the parts of the rays that intersected. It turns out that this does not draw a triangle at all, and therefore was pointless. I then devised a new method, I decided to create lines from each of the three sides of the triangle, then create further out lines, giving the opposite effect. This essentially meant that I could tell if a point was outside of a triangle, and therefore figured out how to draw inside of one too.

I did all of this in Objective-C, and produced a class that can be used as follows:

CGPoint p1 = CGPointMake(320 / 2, 10);
CGPoint p2 = CGPointMake(320, 320);
CGPoint p3 = CGPointMake(0, 320);
CGPoint tp1 = [self translate:p1];
CGPoint tp2 = [self translate:p2];
CGPoint tp3 = [self translate:p3];
Triangle * t = [[Triangle alloc] initWithPoint:tp1 point:tp2 point2:tp3];
CGContextRef ctx = UIGraphicsGetCurrentContext();
CGContextSetFillColorWithColor(ctx, [[UIColor yellowColor] CGColor]);
for (int y = 0; y < [self bounds].size.height; y++) {
	for (int x = 0; x < [self bounds].size.width; x++) {
		// check the point
		if ([t intersectsPoint:[self translate:CGPointMake(x, y)]]) {
			CGContextFillRect(ctx, CGRectMake(x, y, 1, 1));
		}
	}
}
[t release];

This code, although short, creates a triangle from various points, loops through every pixel on the screen, and draws the ones that intersect the triangle.  You can download the full source code from the blog.  I didn't post it to GitHub, since I don't know of anyone that will want it.  The whole thing is just an exercise in futility, unless you want to do pixel-wise triangle collision detection!

Recently I have been helping someone make an IM client for the iPhone. Their client uses a server that is running libpurple to deal with their actual IM account. Since I needed a way to experiment with Libpurple, I created an AIM bot capable of doing things that he needed to feature in his server. This bot can respond to your IMs with information that you ask for, and can fetch information from the web and give it to you.

If you add purpleh4xor to your AIM buddy list, you will hopefully find that it is online. If you IM it something random, for instance hello, it will reply with a simple set of instructions. If you send it a math expression, such as 3+4, it will tell you the answer. Ask it for the weather by saying weather YOURZIP. It can even tell you stock prices, for instance stock AAPL. Most of the web fetching stuff is done through perl (system calls), but the actual bot is written in C, running on a linux VM.

You will also note that if you have an AIM buddy icon set, then it will take your icon. This means that purpleh4xor’s icon will always be that of the latest person to IM him (if they have an icon). The weather and stock fetching takes place on a separate thread, and calls back to the main thread once it finishes. I posted the code to my website through a zip file. Compiling requires that you have libpurple-dev installed if you are compiling on linux. I’ve been running this in a VM, so I haven’t spent much time making sure that it is secure. If anyone intends on running this on their machine, I would first fix-up the security.

While doing this it was interesting to see how nice a C library can get. Libpurple is a really great set of classes, although doing certain things can be more complicated than one would expect. If anyone ever wants to make an IM app, I would definitely suggest using Libpurple.