Objective-C on Thoughts and Ramblings

A Month with AppCode

Mon, 29 Apr 2013 14:45:43 +0000

Anyone who uses multiple IDEs along with Xcode recognizes just how far behind Xcode is compared to others. I would even go as far as to argue it is at least half a decade behind Eclipse. Features which I have long grown use to having are completely absent in Xcode. Then, about a month ago, I discovered AppCode and started using it for my Obj-C development at work. I could repeat the feature set mentioned on their website, but instead I’ll assume you’ve read that and outline the crucial parts.

What Objective-C Has Learned

Tue, 05 Feb 2013 18:14:00 +0000

In a few of my recent posts, I outlined some things which I believe that Objective-C can learn from Java, the most recent discussing error handling. In order to avoid the impression that I may not like Objective-C, I figured I should outline some of what I believe are the most important improvements Objective-C has made.

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.

What Objective-C can learn from Java, Part 5 (Exceptions)

Tue, 17 Apr 2012 02:32:47 +0000

This is one past the last is a series of blog posts I’m writing on things that Objective-C can learn from Java. I’m writing this because I’m seeing a series of ignorant tweets stating how much Java sucks. The other parts can be found here:

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.

What Objective-C can learn from Java, Part 4 (Namespace)

Sat, 08 Jan 2011 21:18:40 +0000

This is the last is a series of blog posts I’m writing on things that Objective-C can learn from Java. The other parts can be found here:

For one who has programmed in other object oriented languages, Objective-C stands out with its complete lack of namespace. As a result, classes have a prefix, such as Apple’s common NS and UI prefixes. On the mac side of things, every class under the sun seemed to start with NS, such as NSString, and confusion is added when on the iOS side, several classes start with UI, such as UIView. This is due to the fact that without a concept of namespace, Objective-C cannot have two classes with the same name, regardless of whether the classes are public or not.

What Objective-C can learn from Java, Part 3 (Single Source File)

Thu, 30 Dec 2010 16:16:28 +0000

This is the third is a series of blog posts I’m writing on things that Objective-C can learn from Java. The other parts can be found here:

Objective-C still retains a lot of its heritage from it’s C beginnings. This includes using two files, a header and a source file, for each class. In a strictly object oriented environment, the header file contains the class definition (super-class and instance variables), public property definitions, and any public function declarations. The source file contains all of the function implementations, including synthesize statements. In contrast, Java contains all the functions of both files in a single file. To one who knows better, as in one who has used the single file environment, the two files for each class becomes a pain.

What Objective-C can learn from Java, Part 2 (Abstract Classes)

Mon, 27 Dec 2010 21:54:20 +0000

This is the second is a series of blog posts I’m writing on things that Objective-C can learn from Java. The other parts can be found here:

When one is using object oriented design, a common practice is to lump similar classes together with a common super-class and include the common functionality in that super-class. In doing such design, a common problem is for the super-class to require some information that can only be computed by the sub-class. The solution is for the super-class to make a function call on itself which the sub-class implements. For example, I recently designed a class which simplifies storage of an object in a SQL row, but it knows nothing about the actual field names or values stored in the database. In this case, I made a function, which subclasses implement, to retrieve this data. In Java, this is simply done through an abstract method in an abstract class.

What Objective-C can learn from Java, Part 1 (Generics)

Sat, 04 Dec 2010 22:38:29 +0000

This is the first is a series of blog posts I’m going to write over the next several days on things that Objective-C can learn from Java. I’ve been programming in Java since 1997, and in Objective-C since 2001. The two languages have a lot of similarities, but there are a few design principles in which Java excels and Objective-C is left behind. This is understandable considering that Objective-C is older than Java, and Java borrowed heavily from Objective-C when it was designed. In this series I’m only going to discuss changes to the language; these items will have very little, if any, impact on the runtime. For the purposes of this discussion, I’m going to use Java’s terminology since it is more familiar with the programming public. This means I’ll talk about functions instead of selectors, and interfaces instead of protocols.

Working With Core Data

Wed, 20 May 2009 21:49:34 +0000

When I redesigned Sapphire, I decided that the metadata back end would be best served by Apple’s Core Data Framework. While the framework has a lot of power, several shortcomings in the implementation hindered its potential.

First, I should start with the many things that Apple did correctly in Core Data.

The whole data model with relationships and properties is quite powerful. With this data model, one can represent many data sets in a simple manner, such as the example below:

core-data-model

This example shows part of the data model within Sapphire pertaining to TV shows, where a TV shows contains multiple seasons, each of which contains multiple episodes. Additionally, an episode contains one or more sub-episodes, to handle the case where a single file or DVD contains multiple episodes. Lastly, the show and season objects extend from a superclass CategoryDirectory, which contains some common properties to all collections.
Since the relationships are defined, they can be automatically maintained. In the above example, if an episode’s show relationship is set to a particular TVShow object, that show’s object will automatically have the episode added to its episodes relationship.
Delete rules can be set such that if an object is removed, the delete can cascade to remove other objects as well. This is useful in the case of removing a directory, and all the files and directories contained within it.
Saving to a file is easy since the details of reading and writing a file are handled by Core Data
While I didn’t use it, undo management is also built into the system.

So, with all these advantages, why is Core Data not used more often. The answer is that it contains numerous short comings.