Learning about iPhone development without the desire for money

I made my last post right after I began learning Dvorak. Now, I am going to give a little update on the experience I had learning it, and the problems that I ran into. First off, let’s get something out of the way: I am typing this article in Dvorak, and I am typing at about 50 words per minute, a speed that I have perceived to be above-average for only 1-2 weeks of practice. So, how did I come this far in such little time? Simple. I immersed myself.

Two weeks ago began my spring break, and, as a programmer with a limited range of interests, I was inclined to spend pretty much all of my time in front of a computer, either typing out code or messaging friends online. Because both of these activities require lots of typing, it is safe to say that I spent at least 10 hours a day pounding away at my keyboard. Of course, being the huge geek that I am, I did not let this time go to waste. Instead, I spent every moment of it with my computer set to the Dvorak keyboard layout, despite the agony that I knew I would experience in the midst of my slowness.

However, such a task as immersing oneself in Dvorak does yield dangerous consequences. There was a point a few days ago when I wondered how my QWERTY typing was being affected, so I flipped back over to give it a try. Now, I may have been a rare case, since I never typed correctly in QWERTY to begin with. I typically find that, when using QWERTY, I use the wrong hand for keys such as Y and B, and I sometimes even use my index fingers in the place of my pinkies. Because of this, touch-typing 100% correctly in Dvorak seemed to have adversely affected my QWERTY muscle memory, leading to the trouble that I encountered. In fact, I could not type anything comprehensible at all. However, after several hours of looking at the keyboard and thinking when I got confused, I completely regained my QWERTY abilities. However, once I proved my ability to recall QWERTY if necessary, I transitioned once again to Dvorak and continued my immersion.

One of the interesting things I found when learning Dvorak was this: there are really three unique stages of learning to type with Dvorak, or any other keyboard layout, for that matter. The first stage is what I like to call the “Visual Stage.” This is the stage when, having been previously unexposed to the Dvorak layout, a typist needs to look at a diagram of the keyboard layout or the keyboard itself for the sake of pressing the right key.

The next stage comes around when the typist comes to know the position of the keys, but still must use some sort of mental process to recall the location of any given key. The time that the typist takes to do this could range from a quarter of a second to 3 or 4 seconds, but the idea remains the same: the typist must think about every individual key. This stage seems to carry the most rapid improvement, and the typist should notice an increase from something like 12 WPM to something more like 25-30 WPM. This change reflects on the decrease in response time for each individual key. Remember, during this stage any improvements are usually on a key-by-key level. However, a transition is made to the next stage when the typist begins to get more used to typing any given sequence of letters at once, and begins thinking more in the context of words than in letters.

When the next phase comes around, which I like to call the “Word Phase,” it is best to practice by thinking of English sentences and typing them out. Once in this phase, all improvement pretty much reflects on the typist’s ability to type a common sequence of letters without thinking about doing so. This muscle memory can only be gained by repetition, and such repetition is easy to obtained by typing sentences, thoughts, words, etc. I found that writing code was not particularly helpful in this stage. Instead, I downloaded a list of common English words and typed them repetitively for several hours, phenomenally increasing my speed for those particular words, and even words with similar patterns to them.

All and all, learning Dvorak was a frustrating yet rewarding experience. I am still nowhere near as good at Dvorak as I am with QWERTY, but I am now to a point where my conversations, programs, and writing is not limited by my keyboard layout. I anticipate that I will continue to use this layout in the future, and that I will someday use Dvorak to surpass my QWERTY record of 106 WPM. I wish any of you out there who attempt to do likewise the best of luck. Such a process is easiest if you think not of the final goal, but instead calmly observe the process through which your skills develop.

If you are unfamiliar, Dvorak is an alternative keyboard layout that supposedly triumphs over QWERTY from an ergonomic standpoint. This weekend I decided to take it for a spin, and was met by a lot of frustration. At this point I can get about 12 words per minute with Dvorak, and plan to continue practicing on a daily basis. I just typed those last three sentences with Dvorak, and it must have taken me at least 5 minutes. I have to say, as a skilled QWERTY typist, it’s going to be difficult to learn a new keyboard layout from scratch. However, I’m sure it will pay off once I do.

I highly suggest Dvorak for any of you out there who are interested in trying something new, or for those of you who consistently experience pain in your hands from typing too much. Even after only a few hours of using Dvorak, it is apparent that typing with it will require much less effort than QWERTY, and that I may ultimately be able to improve my typing speed from what I currently have with QWERTY. At this point I am familiar with the Dvorak layout, and the only thing slowing me down is the time that it takes me to recall where any given key is located. Because of the frustration level, I plan to only use Dvorak for an hour or two a day, which will hopefully be enough for me to become proficient with it.

Recently, I haven’t been programming as much as I should have been, mainly because of school and general overall laziness. There could be many opinions about this change, such as those from educational boneheads who would say something like “yeah, that’s good, what’s the computer gonna do for you anyway?” There are also those opinions of people who would say “well, that’s ashame, but it’s a good thing that you’re focusing on school, anyway.” Well, it’s opinions like these that caused me to dig myself into a psychological rut in the first place. The fact of the matter is, I am not smarter than anyone else, and I am no better at doing things such as studying history, or writing about literature than anybody else. What I am better at is programming, and in general I find that programming is pretty much the only activity that I genuinely enjoy doing.

Last year we took a survey at school that featured questions such as “do you find yourself excelling above your peers in any academic subjects?” It also included other questions such as “do you believe yourself to be a valuable member of society?” The thing is, I answered “No” for the first, and “Yes” for the second. Although I never found myself excelling in any particular subject in school, I programmed a whole lot, and was aware that other people were envious of my programming abilities.

This year, however, I managed to focus all of my energy on school, which in turn lessened the amount of energy that I focused on programming. After a while the pattern of not programming became imposed on my brain in such a way that I no longer had any motivation to program, since I had not experienced the thrill of it for such an extended period of time. I noticed this phenomenon after winter break this year when I looked back on what I had coded during that time, and realized how little I had done compared to last year’s winter break. Given this realization, I began to worry that I was no longer interested in programming, and that the one thing that I was really good at was beginning to slip away.

Unfortunately, right after this year’s break, teachers began piling work on students, which was probably driven by a feeling of a lack of accomplishment that was left from two weeks of not teaching. This made it difficult for me to get any programming time at all. Without anything to turn to for comfort or stability, with which programming used to provide me, I managed to get very depressed during the course of the past two weeks. I won’t go into the details of what I felt, but I can tell you that I would not have felt that way had I programmed more during those two weeks.

Finally, though, this weekend arrived and I saw a great opportunity. Because Monday (Jan 16, 2012) is MLK day, it was a three day weekend, and I was finally able to get in some quality programming time. Starting on Friday night, I worked on a typing test application for Mac, which I had started a few weeks before but had not made much progress on since. I also worked on an iOS application that I called GuessNumber, about which I wrote another post to this same blog. I also worked on a Connect4 application for HTML5, which was a rather moot project as I realized on Sunday morning. But, I didn’t let anything stop me from working on another application. For all of Sunday and into Monday (today), I worked on an application called ABCleaner, that clears out duplicates from the user’s AddressBook. For this app, it was especially fun to design the GUI, which is usually a nice treat, given that I don’t program GUIs regularly.

Overall, I wrote at least a thousand lines of code this weekend, if not more. And, to be honest, it was the most fun I’ve had since the summer. I mean, I probably had some school work to do that I haven’t done yet, but honestly I needed to get school and people out of my mind and focus on what actually makes me happy. Right now I have more self-confidence and feeling of accomplishment than school will ever be able to provide me with, and it’s all because I did something that I love, and that I’m good at. So, my message to all that are reading this is simple: do what makes you happy, even if it’s not what other’s think you should be doing. You’re not going to be able to accomplish anything if what you’re trying to accomplish won’t make you feel good about yourself, because even if you do “accomplish” an uninteresting task, did you really accomplish anything?

We’ve all seen this trick before. A magician lays out several cards, each with 50 numbers on them, and asks you to think of a number between 1 and 100. You then tell the magician which cards contain your number, and, magically, he tells you what your number was. Anybody who has any sense of statistics understands that there is no magic going on here, and rather that enough pointers given will allow the number to be singled out. In this case, the cards are setup in a way that the magician simply has to multiply the first number on every card that contains a number, and the product will be the number in question. As a programmer, I began to come to the realization that a machine would be much better at performing such a trick, since a machine could work perfectly, and would be able to compare the numbers on all of the cards in order to use brute force to locate the user’s chosen number. Such an idea is easy enough to implement in an iOS application, so I went ahead and did just that.

Taking me about a day to implement, GuessNumber is a small iOS app that presents the user with several cards containing an array of numbers, and requires that the user tap either “Present” or “Absent” with respect to their chosen number. After doing this several times (usually 5-7 times), the app shows the user what it believes their number to have been. Of course, the app only has a 100% accuracy rate if the user is honest, and usually I find that they aren’t, intentionally or not. The source code for the Xcode project is on Github, and a demo is available on Youtube:

Many years ago, a young and curious version of myself took an interest in calculators, and with such an interest, I felt that it was necessary for me to own every different kind of calculator that I could get my hands on. After expressing my interest to my father, he went out and bought me a Casio fx-9750G PLUS programmable calculator. At the time, however, I was not that big into programming, and thus the calculator was left to collect dust in my closet.

Recently, however, I decided to take it out again, simply because it had advanced expression parsing that I believed to be necessary for certain subjects in school. For instance, the calculator allows the entry of expressions such as “(((2.5*9.81)^2 + 2) – 32)/(64^2)”, making something that would otherwise be a hassle to calculate into a piece of cake. At first, my only ambition was to be able to do such calculations with ease, which would lessen my anxiety on science and math exams. Being a programmer, though, I soon discovered the underlying delight of my calculator, the BASIC programming environment. The fx-9750G PLUS includes an environment in which you can enter programs in Casio’s BASIC language, using one of many built-in functions and operations. I quickly began to write programs that helped me with problems on tests, and other programs that really weren’t useful for school at all.

Pretty soon, I realized that entering programs on my calculator before I planned them wasn’t the best practice, since I would then have to modify the program on my calculator in order to fix bugs. I took to the habit of writing programs in my notebook before entering them on my calculator, which did ease some of the pain, but also left something to be desired. The problem was, I could think through programs all I wanted to on paper, but how could I test them? That’s when I made the decision to make a custom BASIC interpreter for my computer that would allow me to enter and test BASIC programs on the fly, with the joy of typing on a qwerty keyboard instead of Casio’s poorly thought out keyboard layout.

Since I did not plan on fully recreating Casio’s language, I decided to call my mutated spin-off ANBasic. Before I even set out on this project, I’d been dreaming for a long while of making some form of proprietary byte-code, just because I liked the idea of creating data that is unreadable to humans but easily understandable to machines. So, it was my decision early on that my ANBasic interpreter would process a script, compile it to ANBasic byte-code, and then would be able to execute this byte-code at a later point in time.

The first step to implementing this project was to design a simple tokenizer for the ANBasic language. This tokenizer would read a raw script file, split it up line by line, and pick out tokens, such as mathematical operators, function and variable names, etc. Once the tokenizer was done, I created a “grouper,” a small set of subroutines that processed control-flow statements, applied the order of operations (PEMDAS), and grouped functions with arguments. The grouped script would then be written to a binary byte-code file in my custom byte-code format. The runtime would then load this grouped script from a file, and execute the grouped script using a series of Objective-C categories on different code objects.

Although the compiler itself generates a grouped script, and could easily execute it without writing it to a file, I already had my mind set on designing a byte-code format, so that is what I did. And, if I do say so myself, the final product is pretty nifty. Although my ANBasic project isn’t quite done as of yet, it can currently compile a variety of control-flow statements, functions, expressions, etc., and can execute them. I have tested it with some of the programs that I wrote for my calculator, and it works like a charm. You can check out the ANBasicCompiler Github repository for yourself and see what I’ve been working on. At this point, I’ve already pretty much lost interest in my Casio, as I’ve recently obtained a new TI-Nspire calculator. Despite this change, I still stuck to finishing my ANBasic project, which ended up teaching me some valuable lessons about tokenization and lexical analyzation, not to mention the fact that I simply had nothing better to do.

In computer science, a queue is an abstract data structure that, when used correctly, can be used to search through nodes in an efficient and exhaustive way. This kind of search is also known as a Breadth-first search. A queue is made with a stack that can push and pop “nodes.” A node can be expanded into zero or more sub-nodes, which are then pushed to the end of the stack. Every time a node is popped from the front of the stack, checks are made to see if it is the search destination. If it is not, it is expanded, and the sub-nodes are pushed to the end of the stack. If there are no items left to pop from the stack, the search has been completed with no results.

This search algorithm can be applied to many things, one of which being unit conversions. In science and throughout one’s life, units are used for different things. One might use meters for distance, kilograms for weight, or minutes for time. Most units can be linked to other units with equivalencies. For instance, one foot is equal to 12 inches, meaning that there is an equivalency between feet and inches. Further more, one yard is equal to three feet, meaning that a yard is 36 inches. A conversion like this can be done by following an equivalency chain. Although there are multiple ways to implement something that does these kind of conversions, I chose to use queues, creating an interesting and thought-intensive programming exercise.

I designed a unit converter in Objective-C that uses queues for unit conversion. The converter runs with a pre-compiled list of pretty basic equivalencies. From these, it can convert any compatible units that were programmed in before hand. For example, it knows that one foot is 12 inches, and that one yard is three feet. So, in order for it to convert from inches to yards, it must follow this equivalency chain, in this case using a queue.

First, the queue starts out with one node, or the starting point. In this case, we are starting with inches. It then pushes the available equivalencies that it knows for inches. Since the pre-programmed equivalencies are pretty bare-bones, the inch unit only has one equivalency, stating that there are 12 inches in a foot. So, the new feet node is pushed to the queue, and the inches node is removed. It expands and pops the feet node, which has an equivalency to yards. When it gets around to popping the yards node, it realizes that yards is the unit that it wants, and traces back a history data structure to figure out the equivalency chain that it has followed.

On Github, I have posted a sample project that allows the user to enter two units. It then tells you the final equivalency (e.g. inches to yards), as well as the equivalency path that it took to get that answer. Here is an example of the usage:

Have: km
Want: inch
1 kilometer = 39370.078800 inchs
kilometer -> meter -> yard -> foot -> inch

As you can see, the user entered the “have” and “want” units, and the program did the rest. The framework for unit conversion is pretty easily expandable, having a simple ConversionConst.h file where equivalencies and units can be added/removed. This file gives the program its intelligence. I worked hard to make the API able to convert units without being given very much equivalency information. It can do its job as long as the equivalency chain between two units exists in the pre-compiled information.

For the past couple of days I have been investigating Automatic Reference Counting (or ARC) that comes with LLVM 3.0. This compiler takes memory management off the developers hands, provided that a few simple rules are followed, and that conventions are kept.

I decided that the best way to get used to ARC would not be to write a new project using ARC, but instead to port some existing code to ARC. One of the libraries that I maintain, ANImageBitmapRep, seemed like a good candidate, since it is used in a number of projects that, in the future, may be ported to ARC themselves.

Realizing that ARC is not yet widely used, I decided to add conditional statements to the code that would allow it to be compiled with ARC, while still being able to work with old compilers, or with ARC disabled. I did this using the __has_feature(objc_arc) macro in conjunction with the #if compiler directive.

One of the confusing pieces to the migration to ARC was that ANImageBitmapRep, using underlying CoreGraphics objects, has many functions that return Core Foundation types such as CGImageRef. Because of this, I had to figure out how to autorelease a CF type manually, without directly calling the now forbidden autorelease instance method. In order to trick ARC to doing this, I created a function marked with __attribute__((ns_returns_autoreleased)), indicating that the return value should be retained and autoreleased. This helper function took a CGImageRef and returned an object (the result of a bridged cast from CGImageRef to id).

Besides this, all that I really had to do was remove all of my retain/release calls, and fix a couple circular retain cycles. Finally, I got a compiled version of ANImageBitmapRep and an iOS demo app to compile and run using ARC. Testing for leaks on the final product was a success, revealing that ARC had done it’s job of releasing everything that it aught to. This port was a great success, and I suspect that in the future I will be writing more code for ARC only, despite the fact that I will not be able to use the __weak ownership qualifier for compatibility issues.

Apple recently released Xcode 4.2, complete with the LLVM 3.0 compiler. This new compiler includes better optimizations than LLVM-GCC had in Xcode 4.1, and comes with some pretty nifty features. The most notable new feature is ARC, or Automatic Reference Counting. If you are not familiar, Objective-C is a language based heavily on retain counts for manual memory management, and therefore ARC is quite a big deal.

Every (good) Objective-C programmer knows how to keep track of his retain counts in a manageable way. Using good conventions, it’s possible to make your app leak-free, but it certainly does take a lot of work, and seems like a rather pointless practice in this day and age. Objective-C, C++, and C are pretty much the only languages that still emphasize memory management as a major concern, making them seem rather obsolete when compared with languages such as Java or PHP.

Luckily, the new LLVM compiler does away with all of this. By automatically tracking objects’ lifecycles, the compiler can intelligently insert memory management code at compile time. One of the major downsides is that, in order for this to work properly, one must follow a set of new conventions. For instance, there are several __attribute indicators that may sometimes need to be put in different functions, specifying the retain lifecycle that a given object should have.

For initializers, there is a special __attribute for objects that will be “consumed” by the class. This is to say that, when passing object X into an initializer, the caller agrees that X had a +1 retain count, and that it is passing ownership to the callee.

Return values can be marked with __attribute((ns_returns_retained)) to indicate that the object has a +1 retain count, and that the ownership is to be passed to the caller.

Another thing that ARC enforces is that, in order to store Objective-C objects as C pointers, bridging must be used. This seemed like an obvious tactic to me, knowing all too well how the NSArray implementation must look. I figure that, if I were to see the code for NSArray, I would see something along the lines of a void **, allocated with malloc(), and populated with pointers to Objective-C objects. When casting a retainable object to a C pointer, one should use the (__bridge_retained T) op cast. This retains op, then casts it to the given type, T. To cast back from C pointer to Objective-C object, (__bridge_transfer T) will cast the pointer back to an Objective-C object, noting to release the object when it goes out of scope, or after the last place that it is used. Plain (__bridge T) will simply cast between object or pointer, without worrying about retain counts.

One more notable feature of ARC that I noticed is the __weak and __strong ownership qualifiers. If a variable has the __strong ownership qualifier, all objects assigned to that variable will be retained. Unlike with __strong, __weak variables do not retain/release values. Instead, every __weak variable is set to nil whenever the object that they referenced is deallocated. This will prevent invalid access of dealloc’d objects, which tends to be a pretty common issue in Objective-C code. Each of these qualifiers can be used for instance variables, local variables, and even function arguments.

What do you use when you want a server to communicate with a client over TCP? Some people would tell you to use HTTP. Some people would write their own binary protocol. A friend of mine is actively developing an IM client which communicates with a server using JSON. Unfortunately, some of this data needs to be raw binary, such as buddy icons, etc. Along with that, he uses JSON-framework for encoding and decoding.

JSON (JavaScript Object Notation), is a lightweight, human-readable way of representing dictionaries, arrays, strings, and numbers. For instance, a dictionary containing a single key might look something like this: ["myKey":999999]. You may immediately notice that the data could be smaller. There are two bytes already taken for the open and close brackets. Another two taken by the quotation marks. A few wasted bytes where a four-byte binary integer could be used to represent the number 999999. To some, this is fairly irrelevant. But consider the same amount of overhead for a very large amount of data. A more efficient binary storage method would be nice, and very handy to many.

I created a project called KeyedBits, a binary archive format. First I started off by writing a very simply Objective-C encoder and decoder that I called KBKit, which used some fancy object orientation to achieve its goal. Unfortunately, benchmarking this implementation gave unpromising results. Although it appears that KeyedBits saves an average of around 13%, KBKit was almost two times slower than JSON-framework. My natural reaction was not to optimize my Objective-C implementation, but to write another one in C.

I had already sacrificed the elegance and beauty of JSON, instead using a rather ugly binary format that only looks good when viewed in a hex editor. Now, I had to sacrifice the elegance of KBKit and instead write a C framework. For lack of a better name, I decided to call this C framework KBCKit.

It turns out that encoding was neck-and-neck between JSON-framework and KBKit. The real tie breaker was decoding. After I implemented both the encoder and decoder for KBCKit, and had written an Objective-C wrapper for each, I found that I was successful. KBCKit now is able to encode and decode almost twice as fast as JSON-framework. This, on top of the fact that there’s little overhead, makes KeyedBits a great alternative to JSON in Objective-C applications.

The lesson to be learned here is that sometimes beauty is not better than efficiency. Sure, my C implementation isn’t as fancy as my Objective-C implementation, but it certainly has a better end result. There are times when it’s okay to use a high-level language, but there are also times when it’s simply not appropriate. Imagine if the Linux kernel had been written in C++ instead of C. It would probably be a lot easier on the eyes, but ultimately easy on the eyes isn’t its purpose. Things like kernels, video decoders, and KBCKit were made to be used, not drawn on paper and hung in an art museum. The user doesn’t care how elegant the code is, they just want something with raw speed and power.

Recently I have been spending much time programming an operating system in C and assembly, using simple data structures and calling function after function.  I have decided to take a break from OS development, and instead work on some more high-level stuff in Objective-C.  I am currently working on an app called SuperLists, but today I wasn’t in the mood to work on an iPhone app.  Instead I decided to put some object-oriented programming to work in a mathematical expression parser.

A long while ago I wrote something very similar to this.  You can see the post for that here.  That expression parser didn’t correctly utilize the object-oriented programming model, and certainly wasn’t neat and organized.  The parser that I wrote today has the same final result as the old one, but is structured in a much better and more elegant way.

When parsing human readable text, the first thing your parser should do is convert a human-readable string into a data structure that the program can understand.  This stage is actually the definition of parsing, whereas calculating the result of the expression is known as evaluating.  So, I planned out a structure that would hold different operators, numbers, variables and functions.  This structure contains a base class, EPToken, with subclasses like EPOperator and EPNumericalToken.

After parsing the string given by the user, it is up to the evaluator to use the parsed tokens and calculate an end result.  The evaluator must follow the order of operations, whereas the parser simply reads the sequential tokens from the string.  To achieve this, the evaluator first recursively evaluates the “sub-expressions”, which are potential expressions contained within ( and ).  Next, all functions such as sin and sqrt are evaluated.  Finally, the evaluator evaluates different operators, such as ^, +, -, etc.

Every time a part of the expression is evaluated, that part is replaced by the numerical result.  For instance, when evaluating the ^ expression in 3x + 10^2 + sin(y), the result would be 3x + 100 + sin(y).  Once all operators, functions, and variables are evaluated, the only thing left in the expression should be a numerical constant.  This constant is the final result of the expression.

I finished the parser in only a few hours, and posted the code to a Github repository.  The project includes a demo of how to use my NSNumber additions to parse expressions with custom variables.  Custom functions can be used, but not when using the NSNumber convenience methods.