Tuesday, January 17, 2012

CoconutKit 1.1 released

Version 1.1 of the CoconutKit library for iOS has been released. The source code and binaries are available from the github project page. This release introduces new features meant to boost your productivity by eliminating boilerplate code iOS developers write all the time.

Easy Core Data validation

Usually, when writing Core Data validation methods, you need to add a lot of boilerplate code to handle error chaining. Not only is error chaining easy to make wrong, it also clutters your precious business logic with Core Data code, making validation methods more difficult to maintain and reuse. Most notably, such validation methods cannot be reused for simple needs like validation of values entered interactively. Core Data validations are namely meant to be triggered by Core Data in a row once an object is saved to the store. It is often not what you want.

CoconutKit 1.1 therefore introduces a new way to write validation methods, without the need to care about the usual Core Data boilerplate code. Your methods now can focus on business logic only, and can be easily called to validate fields individually when needed.

But there is more. If you often write forms for editing Core Data objects (most notably made of text fields), you probably always end up writing the same kind of code:

  • Calling the validation logic when the user exits edit mode for a text field
  • Synchronizing model fields with text fields in both model-to-view and view-to-model directions
  • Writing formatting code if values need to be formatted

  • These days are over. You now simply bind a text field to a model object field (providing an optional NSFormatter if needed), all the rest is handled for you. Your code will be faster and easier to write, understand, and maintain.

    I put a lot of effort to get this feature right, testing it extensively and ensuring it is really easy to use. I sincerely hope it will help you write better Core Data validation code.

    Localization in nib files

    When I identify a tedious task I perform every day, I usually try to find a way to make it as simple as possible. One such task is the creation and binding of label and button outlets just for localization purposes. Of course, tools like Accessorizer make this process less painful, but they do not eliminate all the corresponding code which clutters your view controller interface and implementation files. Wouldn't it be nice if we could directly localize strings in nib files without having to create outlets?

    Well, with CoconutKit 1.1 you can. Add a label or a button in Interface Builder, set its text to "LS/" followed by the localization key, and you are done. This feature also integrates with CoconutKit dynamic localization feature, which means all those labels get properly updated when the localization is changed at runtime.

    To help you when you localize your nib files this way, I added a debugging feature which highlights all labels and buttons for which a localization is missing. There is currently no way to extract localization keys automatically from nib files (like genstrings does for source files), but I should provide you with a dedicated tool in a near future.

    Ken Burns slideshow

    A Ken Burns slideshow (a common screensaver transition) view has been added. Set the array of images to display, start the slideshow, and enjoy!

    Release notes

  • Added easy Core Data validation
  • Added UILabel and UIButton localization in nib files
  • Added Ken Burns slideshow
  • Added categories for UIToolbar, UINavigationBar and UIWebView skinning
  • Various bug fixes
  • 2 comments:

    1. Isn't it risky to use CoconutKit when Apple has rejected high-profile apps solely because they used method swizzling? See https://groups.google.com/d/msg/three20/6mBrQRRWXnU/yxWNZuDrnY0J

      ReplyDelete
    2. Method swizzling has been around for quite some time now (to say the least) and runtime functions are public. Naively, I would therefore say that swizzling isn't against AppStore rules, but it makes sense to think that Apple may have some kind of internal policies regarding the use of method swizzling in iOS apps.

      The case you mention is interesting, but I think (and hope!) that this is the exception, not the rule. I can perfectly understand that aggressive method swizzling (e.g. swizzling of -dealloc at the NSObject level) is a reasonable reason for app rejection, but this is not a reason to be afraid of method swizzling in general IMHO. There is probably a lot of applications which use it, and applications we created using CoconutKit have been successfully validated by Apple.

      Though CoconutKit makes extensive use of method swizzling, I am always extremely careful not to swizzle methods blindly, and to swizzle them well. Where method swizzling is too risky, I use other approaches like dynamic subclassing. Of course, I cannot guarantee you that no application using CoconutKit will ever have to fear from rejection because of method swizzling (after all, Apple could change the rules some day), but I try to make everything to avoid it.

      ReplyDelete