Code Completion and Imports
The code completion causally mentions that it works with CamelHumps, but this is a huge factor in completing code. For example, if I wanted an NSMutableArray, in Xcode I must type NSMutableAr before the tab completion results in a single result. If the tab completion is aware of CamelHumps, I must only type NSMAr before the tab completion has narrowed it down to NSMutableArray alone. Furthermore, the tab completion after the insertion of a colon works better than it does in Xcode.

The killer feature in the tab completion is when the class has not yet ben imported. If I were to start typing the name of a class that is not included in the imports, not only can it complete the class name, it will also import the necessary files to satisfy the complier for the choice I made.

Code Generation
Declare Method in Interface: I used this feature a lot. I had long gotten used to copying a method line in the .m file, and then pasting it into the .h file, with a semicolon at the end, to declare it in the interface. Now, I hit option+enter at the method declaration and tell AppCode to do it for me.
Implement/Override: I use this one a lot too. Too often I am making a subclass or implementing a protocol, and I forget all the method name I may want to implement. Now, I just hit the override shortcut, and select the ones I wish to implement.
Change ivar/property to ivar/property/both: I used to use objectivecannotate for this task, but AppCode does it much more cleanly. I can tell it to declare the property for an ivar, or even make it read only in the interface with it being read-write in the implementation.
Live Templates: Yes, Xcode has their snippets, but these are more powerful because you can define what kind of completion to use for variables in the snippet as well as where the snippet is applicable. Thus far, I have only had to add the one that is a typedef of a block to a nicer type name. Such as:
typedef NSComparisonResult (^NSComparator)(id obj1, id obj2);

Refactoring
I have to admit, I’m scared of the refactoring in Xcode; it gets things wrong. I freely use the refactoring in AppCode and it has yet to screw something up. Often, I am renaming a variable or changing a method signature but two important ones must not be overlooked:

• Selecting a section of a line or a line, and extracting the result to a variable.
• Extracting several lines of code into a method

Unit Testing
I have gotten to creating unit tests to test if my code works (yes, not proper unit tests but I have to make sure it works anyway…). Lately I’ve been developing libraries, so testing in the app isn’t as applicable. The unit testing in Xcode is a bit, uh, pathetic. In AppCode, I’m often telling it to run a single test (selector), and then debugging it while it is running the test to see where things went wrong.

Integration
AppCode reads and writes Xcode’s project files. So, going back and forth is a non issue. I modify the project in one, the other sees it. AppCode also can run apps in the simulator or on the device, as well as debug both.

Deficiencies
AppCode cannot edit xib files or a host of other non-text files in a project. It at least will open Xcode to do this task. It is also limited in it’s ability to edit the project as well as missing some of the more specialized functions. The key-mapping is a bit off, making it feel like a windows application, but this can be mostly fixed by changing the shortcuts.

Conclusion
AppCode makes an excellent editor of code as well as debugging. It’s building doesn’t give as much in terms of a progress indicator, but it does work. Since I spent a vast majority of my time writing code and debugging, I spend more than 90% of the time in AppCode. When I’m doing anything else, I tend to use Xcode.

Now, if only Apple would make Xcode a better editor of code…. Nah, NIH syndrome it too well engrained.

The Problem
Why do these fail with Amazon? Amazon has separate vendor IDs for purchases. Purchase made from Amazon are under one vendor where as purchases made from third-parties where Amazon handles the processing is another vendor. While I’ve not seen it myself, I’ve read that Kindle purchases are again another vendor. This means that a single vendor number cannot be used for orders which contain purchases which will be charged by more than one vendor. Furthermore, Amazon likes to save these numbers and if one were to use separate numbers for each vendor, they can easily become confused with one another.

The Solution
I’ve found a relatively simple solution that in my experience seems to solve the problem. Place and pay for orders which would be charged by multiple vendors while retaining the security of not giving Amazon a credit card number that can be used by anyone else.

1. Put items in your cart and build your order to what you want to buy.
2. Do not proceed to the checkout but instead view your cart and click on the link to “Estimate your shipping and tax.”
3. Open a new tab to Amazon’s gift cards, select email, and fill in the amount which will cover your order size. It’d be prudent to add a buck or two extra in case.
4. Put in your own email address and purchase your gift card.
5. When you receive your gift card email, go back to your original purchase and proceed to the checkout. When you reach the payment page, copy and paste the gift card number into the appropriate section.

I’ve placed one order this way and it worked well. Though there was a random fluke where Amazon didn’t ship it for over a week, but they assured me it had nothing at all to do with the use of gift card. In fact, the guy on the phone couldn’t figure out any reason why it was delayed, strange.

I do this because it is an active protection mechanism against theft. Even though I do this most of the time, I did have my credit card number stolen recently and attempted use in Michigan. So, I’ve stepped up my use of single vendor numbers and decided that I will not purchase from Amazon anymore unless I can use them. Does anyone else take these proactive measures to protect their credit card number?

Now, if only this worked with AWS…

I’ve called them at 5-10 times in the past few weeks, and this is still the speed that I get. I have tried changing modems and three separate technicians have said that my connection is good and yet it is no better. This is consistent across nearly every evening. Using these numbers, if I were to extrapolate the speed to the 50Mbps plan, I’d still not get achieve 15Mbps in the evenings.

Just a note for those considering Suddenlink and have a choice with another provider. I used to think that Suddenlink’s service was great, but no longer.

Properties
When properties were first introduced, I read several who described them as simply syntax sugar. While they didn’t initially add much of anything that couldn’t already be done in the language before, they did yield one important feature: generated code. The code necessary in a setter, in particular the releasing of a previous value and setting the new value, was often fraught with errors. Despite code examples on a proper setter from Apple, I saw several cases where a setter failed to release the previous value, or retain the new value, or more commonly, do those two in the correct order. Enabling the compiler to generate this code for the programmer removed many of these errors.

Private Properties
In Java, a programmer can declare a private instance variable and subclasses cannot access it. Furthermore, a subclass can define its own instance variable with the same name and it will be completely separate from the parent’s instance variable. While private instance variables are supported in Objective-C, a child cannot create an instance variable with the same name. Fortunately, an update to properties did bring a way to accomplish the same thing.

A programmer can declare an interface in the .h file, then declare another interface in a class continuation in the .m file. Any properties declared in the .m file will not be visible to other classes, including subclasses. Combine this with the fact that you can create properties which are tied to instance variables which are not declared in the interface, and one can create private instance variables which are not visible to a subclass. There is one caveat though: If a parent class declares a property and a child of that class declares a property of the same name, the “private” property in the parent and the one in the child both reference the one in the child. On the other hand, referencing the instance variable generated by the property references different instance variables, even if the parent and child use the same name.

This little quirk can cause some interesting effects for one who is not aware of how the properties truly work. Accessing properties call selectors, and if a child declares the same property name, it synthesis selectors with the same name as the parent, thus overriding the parent. So, if you wish to have private instance variables which are inaccessible to a subclass, use a property declaration and access the instance variable. Be aware, due to the dynamic dispatch nature of Objective-C, one can still call the setter/getter selectors for the property which cannot be made private. If this is truly a concern, simply override the generated versions to do a different action.

Here is an example of a truly private instance variable.
.h file:

@interface Parent : NSObject
@end


.m file:

@interface Parent ()
@property (strong) NSString *name;
@end

@implementation Parent
@synthesize name = name;
- (id)init
{
    self = [super init];
    if (self) {
        name = @"Parent";
    }
    return self;
}
@end

Do the same in a child class, and you can see that the name instance variables in the child and parent are in fact, distinct.

Blocks
I've derided Objective-C before for its lack of inner classes, but with blocks, it is possible to essentially create an anonymous inner class with a single function. This effectively implements the Java equivalent of Runnable or Callable. I'm not going to go into too much detail, as anyone whose really used inner classes before knows how powerful they can be, but I figured it'd be important to point out that Objective-C has at least obtained some form of inner class. I would like to add that the fast enumeration with a block is really nice because in casses where a programmer needs the index of the current object, the block is given this information instead of having to track it manually.

BTW, I do know a technique for creating an inner class with multiple functions out of a block, but it's just not worth it.

Collection Syntax
I cannot count the number of times I've used [NSArray arrayWithObjects:@"first", @"second", nil], but now Objective-C brings a nicer way to do this: @[@"first", @"second"]. Yes, it is simply just more syntax sugar, but it is really convenient. Note, dictionaries have the same thing, but it is @{@"key":@"value"}

ARC
I saved the best for last; ARC is a big improvement for Objective-C. Not only does it remove a lot of the tedious nature of tracking retain/release, but it also introduces a few new constructs. If one wanted to override the setter for a property, the issue of retaining the new value, releasing the old, and getting the order correct is completely eliminated; ARC does all this busywork for you. Additionally, ARC generates a hard error if a programmer tries to call a selector which is not visible in the current context. So, in the example above, the selector name is implemented by the @synthesize, but it is not declared in the interface. Before ARC, a programmer could go ahead and call it anyway, such as [parent name];, and the compiler would generate a warning but it would work. With ARC, this generates a hard error because ARC needs to know if the selector returns a retained value, an autoreleased value, or no value at all. I view this as a good thing because I have known a few programmers who would call selectors not visible in the current context and then proceed to ignore the warnings. Most of these were simply forgetting the appropriate #include, but in cleaning up these warnings, I often found misspellings just bidding their time, waiting to get executed, so they can spring into action and throw an exception brining down the program. Now, these warnings are errors, so in cleaning them up, programmers should find their true errors more easily and correct them sooner.

ARC also brings in weak references. Just like assignments, weak references do not prevent an object from being deallocated. They are different from assignments in that weak references will never give you an instance which has ben deallocated. I should add that weak references are not as powerful as the ones found in Java, but they do give most of the functionality. I had the task of trying to create a dictionary which holds the objects weakly, but since the keyspace is quite large, it also needs to clean itself up when the objects are deallocated. In Java, this can be accomplished with ReferenceQueues, but Objective-C is missing this feature. I did managed to come up with a more convoluted solution that works, but it's not as pretty nor easy.

Interestingly, ARC now marks the third memory management model for Objective-C. The previous, GC, is now deprecated. I wonder how long till a new one replaces ARC. Maybe it'll be ARC-GC, which combines ARC and GC and eliminates the whole problem of strong cycles.

Conclusion
While I've listed several places for Objective-C's improvement before, it is not remaining stagnant. While I still contend that Java is the superior language, Objective-C does have the ability to change this. I should like to see the language improve even more so it can retain it's position as the most popular langage for years to come.

Mercurial has a tremendous advantage in that it’s command structure is easier to understand. I’ve enjoyed this feature having come from SVN, and every time I have to use Git, it makes me want to scream (and has literally made me do so one a few occasions). The usability of the command line is severely relegated when one starts to use tooling present in IDEs, file browsers, and other UIs. In this case, one needs only to go to the command line for very advance operations, in which case both DVCSs require looking up the command structure to understand how to accomplish the task.

So, how does the tooling compare? I primarily use Eclipse for my development, but I also sometimes use Xcode. I was told by an Eclipse committer, well over a year ago, that the tooling in Eclipse is better for Mercurial than it is for Git, but the Eclipse Foundation had elected to switch to Git (from CVS). I wasn’t actually using either but I didn’t like Git at the time (since using it nearly always required the command line). Lately, at work, we’ve been using Git more and more, mostly due to Eclipse using it. As a result, I’ve become familiar with the tooling in Eclipse. Today I decided that I was going to convert one of my Eclipse-based projects from SVN to a DVCS. I tried out the Mercurial tooling and found it significantly lacking. I decided, that despite the difficulty in the command line, Git would be a better choice since it has less difficulty in the tooling. Lastly, with Xcode, Git is built-in where as Mercurial is not.

So, where does this leave the Mercurial v. Git debate? It looks like Git is going to end up being the clear winner, simply for the fact that Git appears to have better tooling for developers. Git’s command line for basic functionality is atrocious (“git reset –hard HEAD .” vs. “hg revert .” anyone?), but in the presence of good tooling in the IDE, the basic functionality accessing a menu item. Additionally, Git’s shortcomings in the command line can be partially mitigated with aliases (I’ve already made one for revert), though this still doesn’t solve the confusion between fetch and pull. So, with a good GUI to cover up the lousy CLI, Git has finally become a viable alternative in my mind.

PS. For those wanting a laugh, read Git is MacGyver / Mercurial is James Bond (Ok, that’s not really the title but it should have been).

Storage
I’ve written some on my storage setup before, but I’ll describe it briefly here. I bought an Antec 300 case, Intel server-class motherboard, 6 WD 2TB Black drives (before the flood that drove up the prices), and 4G of RAM (later upgraded to 12GB). The machine is booting Ubuntu 11.10 (not yet upgraded to 12.04) off a pair of USB flash drives which are configured in a software mirror. The 6 drives are configured in a raidz2 configuration (raid6 redundancy) yielding 8TB of disk space (or 7.2TB if you count in base 2 instead of 10). The raid contains all the media is an a sub-filesystem so it can be snapshotted/backed up independently (taking advantage of ZFS’s capabilities here).

Content
All the storage in the world isn’t useful if there isn’t anything to put on it. I’ve experimented with several different forms, but I’ve finally settled on ripping my DVDs and BluRays to MKV files. I added a SATA card and a BluRay burner to my storage array for this purpose. Most would rip DVDs using Handbrake, but since I have the space, I’m doing a lossless conversion. I’ve been using MakeMKV to rip the DVD content into an MKV file which contains the original MPEG-2 video, AC3 audio, and DTS audio (when present). I only include the subtitles when I need them. When it comes to ripping BluRays, there’s little choice beyond using MakeMKV for the actual rip process. The resulting file can be run through Handbrake to transcode, but I’m still experimenting with keeping the original file. In that case, it contains the original H.264 video and DTS-HD or Dolby TrueHD audio.

Server
In my case, the server and the storage are the same hardware, but there’s also the software component as well. In the past I worked on a plugin for Frontrow (on the Mac) and the AppleTV. It did a nice job of cataloging my movies and TV shows. I’ve never been happy with any of the other solutions, so I ported this over. In doing so, I realized that I should change it from client-only to a client-server relationship, but a client-server relationship brings it own set of challenges. For instance, it makes little sense to design a server that’s only capable of supporting a single client, so the server has to be designed with concurrency in mind. At first I thought of playing with a C based metadata server, but quickly I realized that I would be far better off using a Java based server due to its superior threading models and concurrency primitives.

I decided to transfer everything over HTTP where the client will make its requests via HTTP GETs and information from the server is transferred via JSON. I also decided that I’d put a majority of the intelligence in the server, so the client only makes requests of URLs which the server provided in a previous response. The initial connection is advertised via mDNS and extra information can be transferred via HTTP headers. So, when the client starts up, it listens for mDNS broadcasts of the server and makes the initial connection. The server tells the client to present the user with a list of items, where each item contains a title, preview information, the URL to access when the user selects the item, and what type of display is contained at that URL. Additionally, there are URLs for the list menu and the contextual menu of each item. So, with a small set of display primitives, I have a fully functional set-top display all delivered by a server. Furthermore, due to having a client-server system, when I get more set-top boxes, the information is automatically synchronized between them. So I can stop playback in one room, and resume it in another.

Client
I spent a while trying to find a good client. I originally looked into a Roku, but I found it terribly lacking. Furthermore bringing up any such deficiencies in the forums brought on the wrath of its fanboys. The final straw was trying to deal with Roku’s terrible programming language, brightscript, and making it actually do something useful (for more info see my post on their forums). The Roku is now a black piece of plastic sitting in a closet, where it belongs.

I later bought a GoogleTV, particularly the Sony NSZ-GT1. It seems to have gone up to nearly $300 which is significantly more than the $170 I paid for mine in Nov. I selected this device because it not only can play high bitrate 1080p content, which the Roku claims but fails to deliver, but it can also play nearly any other content that I have such as AVIs, MKVs, MP4s, FLVs, and even MPEG2. Furthermore, it’ll play the typical codecs found in these files, including passing through the AC3 or DTS to a decoder. In short, it plays nearly everything that I’ve thrown at it, so it makes an excellent set-top box for playback. Soon, more manufactures are supposed to be releasing their GoogleTVs which should drive the price back down.

Since the programming language used on the GoogleTV is Java, I was able to significantly reduce my time spent parsing data from the server. I created a set of Java objects which defined the data I wished to transfer, and simply copied these objects to the client. Then I simply used the Jackson library to serialize and deserialize these objects to and from JSON on both ends. Additionally, the client is powerful enough to do some interesting additions. The GoogleTV is currently lacking the ability to display subtitles, so I added it myself. I currently can display both SRT and VobSub (IDX/SUB) subtitles. I suppose I’ll be adding SUP in the future to support BluRay subtitles, but since its format is similar to VobSub, I expect it to be a simple process.

Conclusion
So, there it is. I have a set-top box from which I can play anything that I own. Whenever I get a new disk, I immediately stick it in the server and rip it without ever playing it in an actual player. I remember seeing a commercial as a kid depicting the future. It had some kids in a household scrolling through a list of movies on the TV, selecting one, and it immediately played. Back then, the idea was not feasible, but now I have it.

Early Days
I’m sure many here don’t know it, but Perian existed previously in several pieces and none of them were called Perian. They were FFusion, AviImporter, and matroskaqt. I had used most of these pieces before the Perian project started, but none were satisfactory. On June 9, 2006, Augie approached me on IM and said “say, any interest in updating the the ffmpeg based quicktime component?” He had already dedicated a lot of work into improving FFusion and the AviImporter, and I decided to join him. I started to setup an SVN repository on my server, where it is still hosted to this day, but I needed a name. Augie was already using the name Perian, so I named the repository that as a temporary measure. The name stuck to this day. At first we built FFmpeg’s libav libraries into raw binaries which we checked into the repository, but we quickly transitioned to using an svn:external and making a build script to create x86 and ppc versions of the library. We even went as far as to patch FFmpeg to improve it’s compile procedures on the Mac and perform cross-compiling.

The Early Announcement
We were starting to prepare for a first release that essentially supported the common AVI files. A few days before the expected first release of Perian, I remember I was getting ready to teach class when I saw some comments that Perian had made digg. I had to quickly re-tune the web server to withstand the load from the story which would eventually receive over 4000 diggs. This was rather remarkable because at the time 4000 earned it a place on the front page and we didn’t have a single downloads to offer. We decided to step up our release date and put it out the next day. Amid preempting announcements and severe issues with sourceforge’s download servers, we had a rather successful first release.

Rising Star
Before the next release, the AppleTV was released, and within one day, it was hacked to get Perian installed (Sorry, original forum post is not publicly viewable). Then, a few months later, we released version 1.0. In this release we integrated mkv support A52Codec, subtitles, and a plethora of codecs and other file formats. Afterwards, we release 1.1 with a great number of speed improvements, most notably marking to QT which frames can be skipped in decoding for cases where a computer is too slow to decode entirely (such as the AppleTV).

During this time, I also started to work on the Sapphire Browser. Combined with Perian, this made the AppleTV a great set-top box for media playback. I proceeded to use this as my media playback for nearly 5 years, working on both the backend (Perian) and frontend (Sapphire).

Barriers
Working on Perian wasn’t without it’s share of problems. The first was a lack of great documentation in creation of a QT component. In some cases we resorted to a guess/check type of system which likely resulted in horrible abuses of the API, but it worked. We also had a problem with high-profile H.264. We noticed that it would crash when using Apple’s decoder, and when they later fixed the crashes, it would display around 1 or 2 frames per second. Perian could be made to decode H.264, but Apple’s codec was faster at main and baseline profile that we could achieve in Perian/FFmpeg. We resolved this by making Perian do the decode of high-profile H.264 but not on main or baseline profile. This was a particularly interesting hack considering the fact that all the profiles are the same codec, and we had to devise means by which to make Perian take priority for some of the profiles but not all. Apple has since corrected high-profile decoding in their codec to have decent speed for all profiles.

By far, the largest barrier was QT’s import limitations. When a QuickTime component imports a file, it must provide a series of location and sizes for each frame in the file (along with it’s associated display times and other information). While AVI has an index which provides this information in a single place, some formats do not. Fortunately, a component can do part of the file at a time, and incrementally import the file. This is what Perian does with MKV, and why it takes so long for an MKV file to become fully available. This still doesn’t handle other formats such as MPEG or ogg. MPEG has a single frame’s data split across multiple packets, meaning that the data is not contiguous. This is not a situation which QuickTime is designed to handle (See our rdar on the subject).

Finished Project
When we started releasing the 1.2 versions, Perian was starting to really look like it was as complete as we could make it. We were quickly hitting the end of what we could still accomplish. The improvements that we most wanted to add were not possible under QuickTime’s current architecture. Apple was promising a new architecture in QTX, but it has yet to be released. In the mean time, the developers started to move on to other things.

Perian accomplished our initial requirements and went beyond that. We could not have imagined a more successful project. Chris predicted that Perian would be bigger than Adium, which was a goal I didn’t see happening. Then Perian 0.5 had a shockingly high download count somewhere near 500,000. The download counts continued to grow, until Perian 1.2.3 came in at, as of today, 7,104,592!

The Future
I cannot speak for other developers, but I’m likely to move away developing Perian any further. Apple is not too likely to break the core functionality in Perian in the future, until they drop the old QT component architecture entirely. At that point, Perian would require a near complete rewrite to make it functional again. I doubt I’ll have the free time to dedicate to such an undertaking.

When Apple made the new AppleTV based on iOS, I knew that Sapphire’s days on the AppleTV were numbered. I predicted that hacking the new AppleTV would not be as fruitful as it was on the previous generation. My prediction turned out to be correct. Instead, I continued to work on Sapphire’s design even more. I soon realized that the AppleTV was a dead end as far as my media player needs were concerned, so I started to look at alternatives. Today, I have ported the core functionality of Sapphire over to the GoogleTV, and it’s a far better device at playback than the AppleTV ever was. The contrast is more visible when one notes that the AppleTV needed to be hacked, but the GoogleTV didn’t need any changes.

And so, here we are, at the end of a wildly successful project. We originally created it to satisfy a need in our own media playback, and gave it to the world. Apparently, millions had the same need. I want to thank Augie for his original concept of the idea and bringing me in on an early stage, Chris for his dedication in managing our little band of misfits and providing some excellent vision, David for bringing in matroskaqt his general cleanup of the code, and Alexander for take the brunt of the work in when others were not available. Finally, Perian, which itself is smaller than most mobile apps, has proven that truly great things can come in small packages. So long little guy, and may you continue to live on beyond after our retirement.

Anyone who programs in Java for a short period of time becomes well aware of Java’s exceptions. To the new programmer, they may be a bit of an annoyance, but to anyone designing enterprise-level code, they are a necessity. Objective-C has exceptions too, but they are so weakly defined in the language and so overlooked, it’s almost as if they were nothing more than an afterthought. In fact, one can argue that the exception handling in C++ is superior to what one would find in Objective-C.

In Java, the exception handling is of the familiar:

try {
  <code that throws exceptions here>
} catch (ExceptionTypeA e) {
  <code to handle exception type a here>
} catch (Exception e) {
  <code to handle other exceptions here>
} finally {
  <code to execute regardless of whether an exception was thrown or not>
}


Of course, in the above, the catch statement is optional if one wants the exception to propagate outside of the block and the finally is optional if one doesn’t have code that needs to be executed in all cases. This block is even more powerful in Java 7, with its try-with-resources ability, but I’ll leave that point out for now. In Objective-C, the block looks like the following:


@try {
  <code that throws exceptions here>
} @catch (ExceptionTypeA e) {
  <code to handle exception type a here>
} @catch (Exception e) {
  <code to handle other exceptions here>
} @finally {
  <code to execute regardless of whether an exception was thrown or not>
}


It looks very similar. At a first glace, one may think that the two are the same, but appearances are deceiving. In Java, there are two different kinds of exceptions, checked and unchecked. Checked exceptions are ones that a function may throw, that all callers must handle. This is the familiar throws declaration. Objective-C only has unchecked exceptions, or runtime exceptions. Additionally, exceptions are heavily discouraged in Objective-C, to quote the documentation:

In many environments, use of exceptions is fairly commonplace. For example, you might throw an exception to signal that a routine could not execute normally—such as when a file is missing or data could not be parsed correctly. Exceptions are resource-intensive in Objective-C. You should not use exceptions for general flow-control, or simply to signify errors. Instead you should use the return value of a method or function to indicate that an error has occurred, and provide information about the problem in an error object.

One part that is missing from the above is that a thrown exception bypasses ARC, meaning that throwing an exception will very likely cause a memory leak. It should be noted that stack objects are freed and even have their destructors called in C++ when an exception is thrown. Here is a case where C++ is superior to Objective-C (I never though I’d see myself write that).

So, from this, one can conclude that the use of exceptions in Object-C is discouraged at best, worthless at worst. Apple’s documentation encouraged using an error object, but this method is very lacking. These error conditions are rarely checked in practice, and the object tends to be used again causing more errors that are not checked, and so forth. In a system using exceptions, where one is forced to handle the exceptions, the error handling can be put in a single location for all the functions in the frame which can throw that exception, avoiding the tedious error checking after every single function call.

Additionally, returning an error code is lacking in terms of context. Java’s exceptions contain stack traces and the ability to nest exceptions. One common method, especially in library code, is to contain a thrown exception inside another exception, providing additional information, and throw the new resulting exception. Then, when this exception is finally caught, a lot more information is available than a simple “this type of error occurred.”

So, what does it take to fix this? The changes are likely very significant. Apple did improve exception handling in Objective-C 2, but they still failed to bring it up to where Java has been in the beginning. Their changes seem to suggest they knew that Objective-C’s exception handling was lacking, but they didn’t invest enough resources to bring it up to par. This either means they don’t care, or that the changes were too significant. I’m going to lean toward the latter since my knowledge of the Objective-C runtimes leads me to believe that it cannot really be made to handle exceptions properly.

Impact on Runtime:
Guessing here: Significant. The runtime would need to be completely reworked to handle exceptions at every stage. ARC would need significant work and throwing/catching exceptions would need to be made significantly cheaper.

Impact on Code:
Adding checked exceptions to the code would require adding more syntax sugar to method calls and a lot of code would need to be reworked to handle exceptions instead of checking error codes. Random errors would be less likely to be swallowed, and users will have a better idea as to the true nature of their problem (no more stepping through assembly in a library tracking down what should have been a thrown exception as I’ve had to do in the past).

So, I changed the server to run Ubuntu. I wanted to be able to make the raid drives spin down, so I needed to boot off different drives. I ordered two USB flash drives, set them up in a software raid 1, and installed the OS on it. I considered running root off ZFS, but the ZFS boot in linux is more primitive. I cannot boot off raidz1 nor raidz2, so booting off the existing raid was out, if I wanted to do so. Additionally, the ZFS boot appears to not be able to boot off USB, so that pretty much killed it. Later down the road, I’ll buy a pair of SSD drives for the boot drive. It looks like there it shouldn’t have issue with booting off ZFS, in a mirror configuration.

In some ways I’m said to see FreeBSD go, but I really need more functionality with the machine. FreeBSD is a nice stable server, but it’s so difficult to make it do anything beyond the standard fair. It’s package management and port system is more difficult to use than apt-get. Also, Ubuntu used by more people than FreeBSD, so it’s a more likely target for peoples’ software development. Lastly, SWT based java projects have no problems running on it, like the one I made to stream to my GoogleTV. So, now my server is running Ubuntu going forward.

So, I bought a Roku a few months ago after my dad bought one. He got one of the first generation devices, as well as a second. It was able to play his ripped media, with a little coaxing, but the feature that caught both of our attentions was the 1080p playback. I decided to buy a second generation as well, since it had the ability to create third-party apps (they call them channels).

I started to program for the Roku, only to be first struck by the programming language. While it has similarities to several other scripting languages, it is a new programming language. Those out there familiar with the realities in computer science are screaming in the heads how this is a poor decision, but they made it anyway. I was then struck by the complete lack of library availability. Unfortunately, I had allowed myself to accept the premise that I had no choice in the matter and tried my best to plow on. My father and I had designed a Java server, which facilitated transcoding of files to be served to the Roku. I then started to add in the metadata features found in Sapphire to this server. I had browsing working from the device as well as playback initiated from the device. It was starting to look like a replacement for my AppleTV running Sapphire.

Then came the updates. Roku issues a firmware update, which caused numerous problems. The most notable was when one would play an MP3 on the first generation device (streaming a radio station for instance), then later played an MP4 with H.264, the device locked up requiring a reboot. This bug took a month and a half to fix. Additionally, the HLS streaming, which is what’s used to deliver the transcoded data to the device, was suffering from numerous audio dropouts. Supposedly, this bug was fixed in the update that was released today, but I’ve found reports of this bug in the firmware betas dating as far back as May. This means that roku was aware of the regression for 5 months before releasing the firmware. Furthermore, try to report this bug on their forums, and the fanbois descend on you like a coming plague, insisting that nothing is broken, or that a fix is coming and you must be patient. I’ve even seen some do both, even though they are diametrically apposed positions. I then noticed a firmware update on my second generation roku including some of the same regressions.

I’ve had it.

I decided to get something else. When I looked at the list of options, I narrowed my choice down to AndroidTV and GoogleTV. AndroidTV is essentially hardware vendors taking the open sourced Android OS (the versions that are), and putting in on their devices. GoogleTV is the Android OS, with some additional addons including a large host of codec/container support. I went with the latter, so I now had to pick which device. Sony makes a BluRay player and several TVs, and Logitech used to make their Revue. I went with the BluRay player since it was not discontinued and I didn’t want to buy a TV right now. Also, the GoogleTV’s new firmware is based on Android 3.1, and the AndroidTV devices are mostly on 2.2 or 2.3.

When the device arrived, I started doing some tests. It played nearly everything I threw at it without issue. I played everything over http, just giving the built-in VideoView class a URL to play, and it played it. I tested MKV, AVI, MP4, and MKV files. All had no issues. It even played the killa sample, which is something that the roku failed to play. The programming language is far better, since they used Java, and the programming environment actually works instead of the occasional lockup of the device in the debugger from which the roku suffers. It’s also much faster, and stable. My dad found that Amazon was still selling the Revue, so he bought one based on these results. I don’t know what we are going to do with our roku devices. I expect I may finish the Angry Birds levels, then call it failed experiment and box it up.

In short, don’t buy from roku. Buy a GoogleTV instead. Yes, they are more expensive, but you truly get what you pay for here. The programming environment is far superior, which means the apps will be better. The device works, and it appears that Google actually does regression testing. Additionally, Google appears to be ambitious in the devices future. It looks like GoogleTV truly is the route to go. I just wish I had seen it earlier.

BTW, I plan on fully porting Sapphire over to work on the GoogleTV in a client-server relationship. I’m doing this because I plan to allow sharing a single library across multiple devices. I don’t know yet whether I intend to release it to the public. Sometimes it is nice not having to deal with “customer” support. Browsing and playback is done, as well as an importer to read the previous version’s metadata. All that’s left is the metadata importing of new files. Time will tell on where I go with this.