JVM Languages

Java Meets Objective-C

By By Genadiy Shteyman, May 11, 2011

While Java and Objective C might seem worlds apart, the programming languages and the platform libraries have a lot in common

iPhone: Database Access

Complex applications contain storage of some kind, generally a database. Apple recommends accessing the database via the Cocoa API framework called "Core Data." The Core Data framework directly interfaces with the SQLite database, (which, in our example, is running on your mobile device). Core Data hides the complexity of dealing with SQL. Instead, it provides the very handy NSManagedObject interface, which allows you to directly manipulate an entity object’s instance fields. These fields will automatically be stored in the database. Another convenience of the Core Data Framework is that database table creation (as well as adding relations and constraints to the tables) can all be done within the Core Data User Interface provided by XCode.

[Click image to view at full size]

Figure 3: Core Data stack.

Let’s go back to our social networking app and show how to fetch a friend’s profile from the database. We will use SQLite and the Core Data API, but first we have to slightly modify our FriendProfile class, as in Listing Six:

The difference between the FriendProfile class definition here and the one in Listing One is that here, I’ve included the Core Data framework’s header file. Also, our class now extends from NSManagedObject, which gives it all the basic behavior required of a Core Data object.
Accessors, used in Core Data’s NSManagedObject class, are created dynamically at runtime. If you want to declare and use properties of the FriendProfile class, but want to avoid warnings about methods missing at compile time, you can use the @dynamic directive, which is shown in the implementation class, instead of @synthesize.

Using the NSManagedObject API is a bit complex, but it becomes intuitive once you understand it. Listing Seven is an example method that fetches a friend’s profile from a database table, called FRIENDPROFILE. The table contains four columns: NAME, COUNTRY, CITY, and PHONE­NBR.

Our getFriendProfileObjectbyName method receives the friend’s name as an argument. By using the Core Data API, we specify which table is queried as well as the predicates and sorting requirements. As a result, this SQL statement executes behind the scenes:

SQL>select * from FriendProfile where name = "Albert";

Core Data API contains a lot of boilerplate code to get access to NSManagedObjectContext, NSPersistentStoreCoordinator, and NSManaged­ObjectModel objects (unfortunately, such code exists in this framework). You can easily copy this code from the reference here. Once you fetch the FriendProfile, you can retrieve its properties in this manner:

Overall, Core Data is a useful feature. It allows you to graphically define entities (tables) and relations; and generates corresponding Managed Objects dynamically. Also, there is no need to deal with complex SQL statements. On the negative side, there is a significant amount of "boilerplate" code, which you have to carefully place and test.

Java: Database Access

There are multiple Java persistence frameworks. In my opinion, Hibernate is the Java framework that most closely resembles the Core Data API. Hibernate follows an Object-Relational Mapping (ORM) paradigm. That is, it allows you to persist object data into a relational database by simply setting fields on the object, which is directly mapped to a particular database table. The mapping can be done using either XML files or metadata annotations introduced in Java 5. Listing Eight shows an example of the former.

In this example, the FriendProfile object from Listing Two is mapped to a database table with the same name, which is a conventional way of dealing with data mapping. Four object fields are directly mapped to four table columns with the same names. This mapping allows Hibernate to generate proper SQL behind the covers.

In Listing Nine, we have imported all the necessary Hibernate libraries. Then we created a Hibernate Session and started the transaction. Next, we programmatically retrieved the FriendProfile object by simply issuing a get method on the Session object, and passing the expected object type and query filter — your friend’s name. The same query, which we saw in the Core Data example, will run here as well, and return back a FriendProfile object with all profile fields filled in.

Conclusion

Despite differences in language syntax and underlying runtime platforms, iPhone development with Objective-C and Web Application Development using Java share common traits:

Both languages are object-oriented

Both languages utilize the same Design Patterns, e.g., MVC

Both languages use similar Database Access techniques , e.g., ORM

However, there are things that Java developers have to watch for in Objective-C:

Object creation: Java objects are created at runtime using the new keyword. There is no explicit memory allocation that a Java programmer has to worry about. In Objective-C, an object can be created using one of three keywords: alloc, new, or copy. Each one of these, similar to the retain method, increments the retain count of the object. Retain count shows how many pointers to the object exist, and whether it can be reclaimed by the Memory Manager.

Object destruction: Java memory management is greatly simplified with garbage collecting. Java objects that reference other objects are organized as an object graph sitting in JVM’s heap memory. The moment an object becomes unreachable (not referenced by other objects in a graph), it becomes a candidate for garbage collection, usually after its reference is set to null, or it falls out of its method scope. Objective-C has a memory manager, not a garbage collector. If you allocate an object using one of the four aforementioned techniques, you must release the object by calling the release method on this object. Calling the release method decreases retain count. When the count reaches zero, the object is sent a dealloc method; at which point, the object can release any additional memory and call dealloc on its super class. Failure to release or auto release an object causes memory leaks and unpredictable behavior in the future.

Over-release and premature deallocation: Java programmers are immune to these errors thanks to garbage collection. Objective-C programmers have to remember not to release more than they retain. Over-releasing method calls on already deallocated objects can cause the application to crash.

What is clear from these examples is that Objective-C and Java have many syntactic and semantic elements in common. Moreover, the way in which problems are solved tend to use similar components. If you approach Objective-C with this perspective and bear in mind the differences highlighted in this article (and in the "Additional Differences" section), you’re likely to find the transition fairly smooth.

Additional Differences

iPhone vs. Java comparison:

Objective-C uses the nil keyword to specify that an object reference does not point to any object. This is equivalent to Java’s null. However, the subtle difference is that Objective-C allows you to call methods on nil objects, simply returning nil. Java will throw a NullPointerException that can halt program execution.

Objective-C uses the self keyword to refer to fields and method within the object [self fetchLatestData:dataLocation]; whereas Java would use the this keyword for the same thing.

Objective-C uses distinct data type called id to declare a general type of object. This comes handy when you do not know at compile time what type of object comes back from a method, so we can receive id, and cast it to necessary type:

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!