Saturday, April 21, 2012

Flashcards for iPad: Status

Flashcards for iPad is doing well. The beta test has started approximately one week ago. Flashcards for iPad is more or less feature complete and with the help of the beta testers I am able to work out the rough edges. Once Flashcards for iPad has been released I will work on a major new version of Flashcards for Mac in order to enable iCloud syncing.

Thursday, April 12, 2012

Creating an iOS based Core Data Editor project (Video Tutorial)

I got it. The setup of an iOS project in Core Data Editor is not obvious. I promise to make it easier is one of the next releases of Core Data Editor. But until the improvements are released I don't want to leave you alone. This is why I made a short video tutorial that shows how to create an iOS project in Core Data Editor. So here it is:

I will release more video tutorials of this kind so if you want to know something particular let me know.

Tuesday, April 10, 2012

Objective-C needs Java's Annotations

TL;DR: Java's annotations feature allow a developer to annotate code. These annotations can be used either at run-time or compile-time to do awesome stuff. Objective-C needs this as well so that we can let mogenerator and other cool tools do its work more efficiently.

I am addicted to Objective-C. In my opinion Objective-C is a very nice and pragmatic language with a neat syntax and I have used it a lot during the last eight years. Lately I had to use Java a little bit. It was fun but I still like Objective-C more – although there is one thing about Java that I fell in love with and would like to see in Objective-C as well: Annotations.
First I will try to explain what Java annotations are and then I will describe which problems could be solved by having something like Java's annotations available in Objective-C.

Java Annotations

Java annotations allow a developer to add metadata to the code (e.g. to classes, methods, fields or packages). Every annotation has a name and the actual metadata in the form of key-value pairs. An annotation can be processed either at run-time (by using Java's reflection capabilities) or at compile-time (by providing a compiler plug-in – a so called annotation processor)). When an annotation is being processed a developer can do all sorts of things like executing existing code (at run-time) or by creating new code (at compile-time).

Annotations could be useful in Objective-C as well

Now it's time to talk about how annotations could be used to solve Objective-C related problems.

Eliminate the need to write boilerplate code
Writing code makes fun as long the code is not trivial. When working with Core Data (an object graph management framework used to persist data) a developer usually has to write a lot of boilerplate code. This (boilerplate) code is used to avoid compiler warnings, improve the performance, make your application code more read/writable and make it easier to debug. So usually a developer wants to have the benefits of the boilerplate code without writing it. This is why there are tools like mogenerator which generate the boilerplate code automatically. This is cool but manually generated code is a bad practice when developing an application: You have to manually regenerate the code when the model changes and new team members have to get familiar with the generator. It would be ideal to let the compiler generate the code that is usually generated by mogenerator. This would be possible if we had annotations. An annotation processor is basically a compiler plugin that can generate code, as already mentioned. You still get all the benefits of manually generated code (code competition, higher performance, ...) but without the drawbacks.

Remark: Core Data can also be used without the generated or handwritten boilerplate code. The framework generates the code at runtime but in order to avoid compiler warnings one usually writes/generates the code.

Typos are found by the compiler
Java has a few built in annotations. One annotation I found quite useful is the @Override annotation. You attach it to a method you intent to override. Why is this useful? Imagine you have a typo in the name of the method you intent to override: Your implementation never would get called. This is a problem that is also acknowledge by Apple in the form of a technical Q&A: "Common mistakes with delegation in Cocoa":
Capitalization errors are often the hardest to catch. Any of the methods of the NSTableDataSource informal protocol are likely candidates for subtle miscapitalization. For example, numberOfRowsInTableView: is often mistakenly entered as numberOfRowsInTableview:.
Apple goes even further and suggest to copy & paste code in order to prevent these errors:
Perhaps the safest habit to develop is to simply always cut and paste the method selector.
Wait. Using copy and paste to prevent errors in code? Questionable… That's where a @Override-annoation would come into play. The annotation could check at compile time if one is actually overriding a method or not. My friend Stefan Reuter told me about another benefit of @Override: Imagine a developer is overriding a method of a class provided by a third party. A few months later the third party decides to remove this method. If the developer annotated the method with @Override then the compiler will complain about a method that is overridden but which is no longer present. Sweet isn't it?

Remark: I think that in the case of Objective-C protocols we already have something similar. Starting with Objective-C 2.0 a message defines in a @protocol definition can be marked as required (@required) or as optional (@optional). If a class declares that it conforms to a protocol the developer is warned if the class does not respond to the messages marked as required.

We already have annotations!

Objective-C already had an "annotation-like" feature: properties:
@property (key1=value1, key2=value2, ...) Class *name;
With @property we tell the compiler how @synthesize generates code. So what I want to see in Objective-C is a generalized way to do the same thing @property/@synthesize does.

Tuesday, April 3, 2012

Core Data Editor 4.2

I am pleased to announce the release of Core Data Editor 4.2 - finally after a three month long journey of submitting, rejection, re-submitting, … (you get the idea). So what is new with 4.2?


I have improved the most important shortcuts:
  • Create a managed object by pressing ⌘N
  • Create a new project by pressing ⌘⇧N
  • Reload the store file by pressing ⌘R
  • Delete a managed object by pressing ⌫
So creating a new project in Core Data Editor has the exact same shortcut than in Xcode.

Entities Table View

Some of you have very long entity names. Now you can make the entities table view wider than before. Have a look: Big Table


In addition I have also fixed two annoying bugs:
  • Date attribute text field now responds to the tab key.
  • Refreshing the editor view (by clicking on the refresh button in the lower left corner) is much more stable.
Thank you all for your patience and stay tuned for the next release of Core Data Editor which will actually bring new features and more bug fixes. And a special thanks goes to everyone who reported bugs and provided freed back.

Happy Coding.