Toshok Electric Light & Manufacturing

First CoffeeKit Release!

2011-12-22T21:27:00-08:00

Happy Holidays!

CoffeeKit 0.1.1 is ready for download. Release notes can be found here.

I honestly never thought I’d get this out the door. I’ve been swamped with other bits of life, and I was getting really bogged down in the tooling story.

The tooling story is pretty depressing, as there really is no good/easy/popular path to IDE pickup. There are plans in the works, but I’ve decided to punt on it for now and get this in the hands of people who might have an interest (and better, usable feedback for me :) So while the tooling story is less than stellar at the moment, I hope you can see past it to what I consider to be the real interesting bits of the project - the mashup of:

iOS Bindings: UIKit, CoreAnimation, CoreGraphics, GLKit, GameKit, StoreKit, Twitter, etc.
Web Infrastructure: Web Workers, XmlHttpRequest, WebGL, and Typed Arrays, so far

All accessible using JavaScript.

There’s a whole CoffeeKit area to the site now, which will hopefully start looking less like the default octopress theme sometime after the holidays.

Definitely download it and let me know how it goes. If you have any questions or problems, don’t hesitate to get in touch:

On IRC: I’m toshok on GimpNET in all the #mono channels, and I hang out in #coffeescript on Freenode.
Twitter: either @toshok or @toshokelectric works. Or you can just add #CoffeeKit to your tweets and I’ll see them.
Github: If you run into anything, don’t hesitate to file a github issue.
Email: toshok at toshokelectric.com

MonoTouch - more Subviews woes

2011-12-13T10:07:00-08:00

In my last post I explained that it is important to handle memory manually for managed classes that correspond to large resources, and made some pretty vague claims as to potentially large time deltas before objects were finalized. I’ll try to clear this up a bit here.

But first a little background.

Not all managed objects are created equal in MonoTouch. There are basically two classes (not C# classes) of objects: Those that correspond to built-in objective-C types (things like NSString, UIView, UIImage), and those that correspond to user-defined types (ToshokView, MySpecialViewController). The latter class of objects uses a mechanism known as a Toggle Ref.

Toggle References

Toggle references are a handy device for dealing with language bindings where one side of the binding is reference counted and you want the lifecycles of both objects to be the same. In our case the other side is managed by a GC, but there’s no requirement for a GC. The other side could be reference counted too, for instance.

As far as I can figure out about the history, it was introduced by Owen Taylor for inclusion in glib (although in his mail he points out the technique is substantially older), was then used by Mike Kestner in the mono project’s Gtk# bindings , and has since been used everywhere managed code has to interact with a reference counted system (in Moonlight for a long time, and MonoTouch, probably elsewhere).

Toggle references allow either side (managed or unmanaged) to effectively be the owner of the other, depending entirely on the reference count of the unmanaged peer.

The managed peer always refs the unmanaged peer in its constructor, and unrefs the unmanaged peer in its finalizer. So a RC of 1 is special. It means that the only thing referencing the unmanaged peer is the managed peer.

There are just two states:

If RC == 1, the toggle ref holds a weak reference on the managed peer.
If RC > 1, the toggle ref holds a strong reference on the managed peer.

Rule 1 handles the managed ownership case. There are no further unmanaged references to the unmanaged peer, so the unmanaged side of things shouldn’t keep the managed peer alive artificially. There may be other references to the managed peer from roots, and so it can stay alive that way. As long as this managed peer stays alive, the unmanaged one will too.

Rule 2 handles the unmanaged ownership case. If there are unmanaged references, then we know the unmanaged peer must remain alive. This means that the managed peer must also, so we create (in the monotouch case) a GCHandle to keep it alive.

The switching betweek weak and strong references is where the “Toggle” in Toggle Reference comes from.

Toggle References provide a very easy way to bridge between reference counting and GC’ed heaps, but they do have some problems. Cycles are difficult to detect, as they can cross the language boundary, and coupled with C# delegates it’s very easy to create cycles that can’t easily be seen or reasoned about by the user. This was such a problem in Moonlight that we eventually moved away from togglerefs almost completely, and used the GC for everything.

As I said above, MonoTouch uses Toggle References only for user defined classes. For built-in types it simply refs in the constructor and unrefs in the finalizer. There is no toggling. This is due to something else I’m going to gloss over: MonoTouch doesn’t replace the implementation of retain/release for built-in types, but it does supply them for user generated ones.

What’s this got to do with Subviews?

If you have the following view hierarchy:

 Builtin UIView subclass -> 
   Custom UIView subclass ->
     Custom UIView subclass ->
       Custom UIView subclass

and each of the .Subviews properties for each level in the tree has been accessed or modified using the built-in monotouch properties/methods (not the ones listed in my previous blog post), then it will take 4 GC passes (including draining the finalizer queue) for all of those objects to be cleaned up.

Say you clear the last managed reference to the Root UIView subclass. The first GC pass determines that it’s collectible and eventually puts it in the finalizer queue. Or maybe you’re feeling like a good GC citizen and know the hierarchy is gone for good, and you call .Dispose() on the root.

When its finalizer is run it will unref the unmanaged peer. When the unmanaged peer’s RC drops to 0 it will unref all of its subviews. This is the important bit. Since the root UIView has a cached reference to the Custom UIView subclass in its .Subviews cache, the RC of the Custom UIView’s unmanaged peer will be 2. 1 for the managed peer, and one by virtue of being in the unmanaged subviews array. Actually it’ll be 3. The first fetch of the “subviews” property on a UIView creates an NSArray that refs all the elements. This NSArray goes away when the parent object goes away, and as far as toggle refs go, there is no difference between retainCounts of 2 and 3.

When the root view deallocs, it destroys the cached subviews array and unrefs its child view, so it drops from RC 3 to RC 1. Only at this point does the toggle ref for the Custom UIView subclass on line 2 toggle to weak, allowing it to be collected when there are no further managed references to it.

The same process occurs for levels 3 and 4. The GC and toggle refs proceed in lockstep. Given that there are no hard guarantees on when an object will be collected once it is collectible, this seems like a bad situation.

The situation is a bit rosier if the entire hiearchy were builtin-types. Since those types lack toggle refs, there’s no artificial strong references keeping any of them alive, and the GC will collect the entire subtree’s worth of managed objects at once. The unmanaged peers will all be released when the finalizers run.

Now as to how this will affect you: If your memory usage is high, iOS will be nice and give you a memory warning, at which point you’re supposed to do everything you can (as quickly as you can) to reduce your memory usage.

Part of this work is usually cleaning up potentially deep view hierarchies that may be obscured or offcreen - basically you want to clean up anything you can afford to get rid of, things that you can regenerate when you need them again.

MonoTouch is nice and does a GC pass when receiving a memory warning. The problem is that it may take several GC passes to clean things up because of the Subview cache.

One Further Note

The above assumes the boehm collector, where a GC pass scans the entire heap every time. Inefficiencies of that approach aside and modulo conservative GC random bit pattern screwups, you’re guaranteed to clear 1 Subviews level per GC+finalizer pass.

With the addition of Sgen, the situation is likely to become even worse. Assuming that the above hierarchy lives for any length of time, it’s entirely conceivable that the hierarchy will be promoted to the tenured generation, which is collected less frequently, thereby increasing the time it will take to fully reclaim that memory.

No real suggestion here

Unfortunately this post isn’t like the last one, where I offered real, useful alternatives. There aren’t really any good ones here.. I’ve tried coming up with some approaches, but all of them run afoul of the fact that the refcount is always high enough to keep a strong ref around until the parent object is gone, so they retain the lockstep problem.

MonoTouch - paying the bills

2011-12-12T22:01:00-08:00

I worked recently on reducing memory usage in a large monotouch app. Since then I’ve been looking at other ways monotouch either makes difficult or actively hampers memory management.

MonoTouch is garbage collected, which is fantastic. But GC isn’t a panacea, especially in a resource constrained environment like the iphone. Your app can be killed if you use too much memory in the foreground (and don’t respond appropriately to memory warnings), but it can also be killed in the background if it has too many dirty pages which the OS can’t swap out, and the foreground app needs the memory.

You shouldn’t rely on the GC when you’re dealing with large resources, such as images. You should manage that memory yourself, and .Dispose() of it when you’re done. Otherwise you can turn a momentary memory spike into a longer lived plateau because the GC might not finalize the C# peer (and therefore free up the unmanaged resources) for some time.

But images aren’t the only things that keep large blocks of dirty memory around. Every CALayerBackingStore is potentially large (especially if they’re full screen), and UIViews have backing stores. Now, you may say to yourself “Self, I’ll just dispose of all of my UIViews when I’m done with them.” That’s a great goal, but it’s not very performant. And besides, the UIViews your code is dealing with aren’t the whole story.

Caching harmful?

MonoTouch keeps the managed object graph around as long as the unmanaged peers are alive. This is due to some state (event handlers, for instance) existing only in the managed layer. So, if a C# peer for a view is created, it should live as long as the unmanaged peer does. Indeed, there are a whole class of bugs/problems that new monotouch users run into where they aren’t keeping their locally created managed objects around as long as the unmanaged objects. Caching in this case is a necessity.

The MonoTouch framework manages a cache of its own in UIKit (UIView.Subviews), and this is where the problem lies.

The problem, simply, is that any Subviews manipulation performed by the monotouch user (fetching, adding, removing, insertAbove/Below, etc) results in MonoTouch caching references to all subviews. This cache not only forces more objects to be surfaced from unmanaged to managed than we likely need, but it also means that there is a larger delta of time where potentially expensive backing stores (or UIImages if the views are UIImageViews) are kept around. And given the conservative nature of the collector, there is a chance that some large resources may never be cleared.

Imagine loading a nib that has a view with 50 subviews. You dynamically create another subview and add it to this parent view. At that point, monotouch surfaces all 50 existing subviews to C#, even though you never asked for them, and you’ll likely never use them. Caching the reference in managed land to mimic the object graph in objective C is great, but the only reference that needs caching is from the parent to the subview you just added.

Below is a set of operations expressed as extension methods on UIView, that only cache the references they should be caching (the ones on the objects you’re passing in.) There are also a couple of utility methods, such as RemoveAllSubviews, because the alternative (looping over .Subviews calling RemoveFromSuperview) is terrible, as it recaches the Subviews property after every Remove.

Accessing the Subviews property itself will still result in all references being cached, which is unfortunate, but fixing that would require moving away from UIView[] for the type of the property.

Enjoy.

static class UIViewHelpers { static UIView[] GetCachedSubviews (this UIView view) { FieldInfo fi = typeof(UIView).GetField("__mt_Subviews_var", BindingFlags.NonPublic | BindingFlags.Instance); UIView[] subviews = null; if (fi != null) subviews = (UIView[])fi.GetValue (view); return subviews; } static void SetCachedSubviews (this UIView view, UIView[] subviews) { FieldInfo fi = typeof(UIView).GetField("__mt_Subviews_var", BindingFlags.NonPublic | BindingFlags.Instance); if (fi != null) fi.SetValue (view, subviews); } static void AddSubviewToCache (this UIView view, UIView subview) { UIView[] subviews = view.GetCachedSubviews (); UIView[] new_subviews; if (subviews == null) new_subviews = new UIView[] { subview }; else { new_subviews = new UIView[subviews.Length + 1]; Array.Copy (subviews, new_subviews, subviews.Length); new_subviews[new_subviews.Length - 1] = view; for (int j = 0; j < subviews.Length; j ++) subviews[j] = null; } view.SetCachedSubviews (subviews); } static void RemoveSubviewFromCache (this UIView view, UIView subview) { UIView[] subviews = view.GetCachedSubviews (); if (subviews != null) { if (subviews.Length == 1) { if (subviews[0] == view) view.SetCachedSubviews (subviews); } else { for (int i = 0; i < subviews.Length; i ++) { if (subviews[i] == view) { UIView[] new_subviews = new UIView[subviews.Length - 1]; for (int j = 0; j < i; j ++) new_subviews[j] = subviews[j]; for (int j = i + 1; j < subviews.Length; j ++) new_subviews[j-1] = subviews[j]; view.SetCachedSubviews (new_subviews); // null everything out to be a good gc citizen for (int j = 0; j < subviews.Length; j ++) subviews[j] = null; return; } } } } } public static void AddSubview_ (this UIView view, UIView subview) { Messaging.void_objc_msgSend_IntPtr (view.Handle, new Selector ("addSubview:").Handle, subview.Handle); view.AddSubviewToCache (subview); } public static void RemoveFromSuperview_ (this UIView view) { UIView superview = view.Superview; if (superview == null) return; Messaging.void_objc_msgSend (view.Handle, new Selector ("removeFromSuperview").Handle); superview.RemoveSubviewFromCache (view); } public static void InsertSubview_ (this UIView view, UIView subview, int index) { Messaging.void_objc_msgSend_IntPtr_int (view.Handle, new Selector ("insertSubview:atIndex:").Handle, subview.Handle, index); AddSubviewToCache (view, subview); } public static void InsertSubviewAbove_ (this UIView view, UIView subview, UIView subview2) { Messaging.void_objc_msgSend_IntPtr_IntPtr (view.Handle, new Selector ("insertSubview:aboveSubview:").Handle, subview.Handle, subview2.Handle); AddSubviewToCache (view, subview); } public static void InsertSubviewBelow_ (this UIView view, UIView subview, UIView subview2) { Messaging.void_objc_msgSend_IntPtr_IntPtr (view.Handle, new Selector ("insertSubview:belowSubview:").Handle, subview.Handle, subview2.Handle); AddSubviewToCache (view, subview); } public static void RemoveAllSubviews (this UIView view) { UIView[] subviews = GetCachedSubviews (view); if (subviews == null) { // subviews was never created, make sure we don't create it here var array = NSArray.ArrayFromHandle<IntPtr> (Messaging.IntPtr_objc_msgSend (view.Handle, new Selector ("subviews").Handle), delegate (IntPtr i) { return i; }); foreach (IntPtr ip in array) Messaging.void_objc_msgSend (ip, new Selector ("removeFromSuperview").Handle); view.SetCachedSubviews (null); } else { view.RemoveSubviews (subviews); } } public static void RemoveSubviews (this UIView view, UIView[] subviews_to_remove) { UIView[] subviews = GetCachedSubviews (view); int subviewsFoundInCachedField = 0; foreach (UIView v in subviews_to_remove) { if (Array.Find<UIView>(subviews, delegate (UIView obj) { return obj.Handle == v.Handle; }) != null) subviewsFoundInCachedField ++; Messaging.void_objc_msgSend (v.Handle, new Selector ("removeFromSuperview").Handle); } if (subviews.Length == subviewsFoundInCachedField) view.SetCachedSubviews (null); else { // XXX punt here - we might end up surfacing more objects than we mean to.. subviews = view.Subviews; // get the property so the cached property is regenerated. } } }

CoffeeKit Internals Part 2: Autoboxing

2011-12-07T12:17:00-08:00

CoffeeKit provides a method for expressing iOS/OSX delegates in a minimal amount of user code, by dynamically creating proxy objects. This process is called “autoboxing”.

First a little intro material:

It’s difficult, if not impossible, to write a useful iOS or OSX application without having to deal with delegates.

These delegates are not the same as those in .NET-land. In .NET, “delegate” essentially means “anonymous function” or “function pointer”. In iOS and OSX, a delegate for an object O refers to an object that responds to messages that have to do with (and often can change) O’s operation. These messages are usually callbacks to report on changes in O’s state, or methods that O will use to decide which actions to perform.

It’s typical (though by no means required) to define a Protocol describing the interface this object O expects from its delegate. Some types list “delegate methods” in their documentation, but don’t define an actual protocol.

Protocols in objective-c are a lot like interfaces in other languages in that they define members but no actual code. They differ from interfaces in languages like java and C# because subtypes aren’t required to provide implementations for all methods. Everything is optional, even (it seems) when the osx/ios documentation list methods as being required.

So, in order to do anything in the common case, you need to either define a second type (your delegate type) to deal with a given object type (say, a UIAlertViewDelegate to work with a UIAlertView) or you add the methods to the object that’s going to pop up the alert view (that is, you use “self” as the delegate.)

Here’s roughly what the first case would look like for a UITextView and its delegate:

UITextView and delegate type

@interface MyTextViewDelegate : NSObject<UITextViewDelegate>

-(void)textViewDidChange:(UITextView*)textView;

@end

@implementation MyTextViewDelegate

-(void)textViewDidChange:(UITextView*)textView
{
   ...
}

@end

  /* then elsewhere */

@implementation MyController

-(void) doStuff
{
  textView = [[UITextView alloc] initWithFrame:... ];
  myDelegate = [[MyTextViewDelegate alloc] init];

  [textView setDelegate: myDelegate];
}

@end

The second possibility (using self instead of a separate delegate type) looks like:

Same example, but using self as the delegate

@implementation MyController

-(void)textViewDidChange:(UITextView*)textView
{
   ...
}

-(void) doStuff
{
  textView = [[UITextView alloc] initWithFrame:... ];

  [textView setDelegate: self];
}

@end

This code is much more compact, clearly. In this case it makes sense, because there’s only one text view. Imagine a situation where you have many text views, though, with different behavior when they change. You’ll either have to add code to discriminate the instance of textView in -textViewDidChange, or you’ll need custom delegate types.

In CoffeeKit it’s possible to do one better, you’ll see something very close to the second form:

Equivalent form in CoffeeKit

  textView = new UITextView().initWithFrame ...
  textView.delegate =
    didChangeText: -> ...

much more compact, and the use of the anonymous function there allows you to tailor behavior to the specific instance. You can also share a function between multiple delegates:

CoffeeKit with function sharing

  myDidChangeText = -> ...

  textView = new UITextView().initWithFrame ...
  textView.delegate =
    didChangeText: myDidChangeText

  textView2 = new UITextView().initWithFrame ...
  textView2.delegate =
    didChangeText: myDidChangeText

or even share the delegate object itself:

CoffeeKit with delegate object sharing

  myDelegate =
    didChangeText = -> ...

  textView = new UITextView().initWithFrame ...
  textView.delegate = myDelegate

  textView2 = new UITextView().initWithFrame ...
  textView2.delegate = myDelegate
  # or more efficiently
  # textView2.delegate = textView.delegate

The magic responsible for this compact code rests solely in the autobox function:

autobox function github

autoboxCount = 0
autobox = (obj, protocol) ->
  # check if the object (or its constructor) conforms to the protocol.  if it does
  # then we can just use the object, without the proxy
  if (ConformsToProtocolAttribute.doesObjectConformTo obj, protocol) or (ConformsToProtocolAttribute.doesObjectConformTo obj.constructor, protocol)
    return obj

  class ProtocolProxy extends foundation.NSObject
    constructor: () -> super (objc.allocInstance @.constructor._ck_register)

  # now loop over the items that are in obj and match up the names to those in the protocol
  for key, value of obj
    if pv = protocol::[key]
      if pv.method
        addProxyMethod = (k, v) ->
          console.log "adding proxy method for #{k}, v.length = #{v.length}"
          switch v.length
            when 0 then ProtocolProxy::[k] = () -> v.call obj
            when 1 then ProtocolProxy::[k] = (a1) -> v.call obj, a1
                .
            when 10 then ProtocolProxy::[k] = (a1,a2,a3,a4,a5,a6,a7,a8,a9,a10) -> v.call obj, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10
            else throw "addProxyMethod doesn't support methods with #{v.length} arguments."
          new SelectorAttribute ProtocolProxy::[k], pv.method, pv.sig

        addProxyMethod key, value

  new RegisterAttribute ProtocolProxy, "CKProtocolProxy#{autoboxCount++}"

  return new ProtocolProxy

First off, this method is invoked like this, with an object and the protocol type:

  autoboxedObj = autobox obj, UITextViewDelegate

A little explanation is likely required.

autobox first checks to see if the object (or its constructor) has a ConformsToAttribute with the protocol listed already. If it does, it just returns the object. This facilitates the first objective-c style listed way above, with the separate Delegate object; that pattern still works in CoffeeKit.

If the object doesn’t conform to the protocol, we know we need to build up a proxy object for it. We loop over all properties of the object you pass in, and if the property has the same name as that of method listed in the protocol type, we create a proxy method to invoke the one on the object. The switch statement over the number of args on the method may seem rather gross, and it may seem like all we need to do is:

  ProtocolProxy::[k] = (args...) -> v.call ...args

This doesn’t work, though, because of an implementation detail in the coffeescript runtime. If a javascript function is invoked from objective-c, only the parameters declared in the JS function are marshaled. so, the methods:

  (v) -> ...

and

  -> ...

differ in that the first one requires marshalling the first arg, while the second doesn’t. They can be surfaced to objective-c as methods that take any number of arguments, though. The rest are just ignored in marshalling.

Remember in the last entry in this series where I said that the real magic of class registration actually happens in the RegisterAttribute constructor? The last line before we return the proxy is where the objective-c type for this proxy is created from all of our proxy methods.

One last thing: here’s the UITextView binding where you see the actual usage of the autobox function:

UITextView github

class UITextView extends UIScrollView

  # Accessing the Delegate
  ck.addProperty @::, "delegate", { set: (v) -> objc.invokeSelector("setDelegate:").call this, (ck.autobox v, UITextViewDelegate) }

CoffeeKit Internals Part 1: Attributes

2011-12-06T10:23:00-08:00

warning: these internals posts are going to be fairly heavy with the code blocks and assume a fair amount of knowledge of how javascript/coffeescript work. where things are potential unclear (or very, very cool) I’ll add a lot more text, but (hopefully) I’m not writing a book.

Attributes in .NET

I started work on CoffeeKit after a long stint in the .NET world. One of things I loved about .NET – and C# in particular – was its use of (and syntax for) attributes.

Take the following code:

[MySpecialClass]
class Foo
{
  [ASpecialMethod]
  public void DoSomethingSpecial () { ... }

  [ANotSoSpecialMethod ("The reason it's not so special is rather boring as well")]
  public void DoSomethingNotWorthMentioning () { ... }
}

This would create (at compile time) metadata which is attached to the type Foo (and its methods) inside the generated assembly. The metadata can be retrieved at runtime using reflection apis, and after the right incantation you’d have in your hands a nice MySpecialClassAttribute instance. They’re used in many ways, such as directing serialization to include particular members of types, telling the IDE that certain properties should be hidden in the UI, or even signaling tools to ignore particular warnings when performing static analysis on the generated assemblies.

The important bit to remember here is that there’s a separation of code and metadata. The attribute can have properties and constructor arguments that are serialized out to the metadata tables, but the attributes don’t actually perform any action themselves since they don’t have a way to get at the type they were applied to. They are later queried/consumed by other code which performs the action.

Attributes in CoffeeKit

Another note: the syntax shown in this segment is pretty gross, and I consider it to be the biggest wart in CoffeeKit. That said, it’s not everywhere, and I have ideas (which I’ll go into toward the end of the post) for additional new syntax to deal with it.

JavaScript is not a precompiled language, so there isn’t really a useful distinction between code and metadata. While you can come up with code that looks a lot like metadata (and indeed, CoffeeKit strives to make the bindings as declarative and metadata-like as possible), the code is still executed. This affords us a special opportunity to make attributes that don’t act quite like .NET attributes.

The way CoffeeKit would express the above C# example is:

class Foo

  DoSomethingSpecial: -> ...
  new ASpecialMethodAttribute @::DoSomethingSpecial

  DoSomethingNotWorthMentioning: -> ...
  new ANotSoSpecialMethodAttribute @::DoSomethingNotWorthMentioning, "The reason it's not so special is rather boring as well"

new MySpecialClassAttribute Foo

see? told you it was a wart.

Note how the attributes come after the definition. This allows us to access the actual object we’re applying the attribute to (we pass it as the first argument to each of the attribute constructors). This syntax also relies on the fact that the attribute constructor will do 2 things, both optional:

Add the attribute to the object’s list of attributes so that it can be found later.
Any further work at attribute create/apply time the attribute might specify.

Let’s look at a real CoffeeKit example:

A coffeekit type to proxy from an objective-c target/action pair to a JS function

class TargetActionProxy1 extends foundation.NSObject
  constructor: (fn) ->
                 super (objc.allocInstance(@.constructor.name))
                 @fn = fn

  proxyAction: (a1) -> @fn(a1)
  new ck.SelectorAttribute @::proxyAction, "action", "v@:@"
new ck.RegisterAttribute TargetActionProxy1, "TargetActionProxy1"

The target/action pattern is pervasive in objective-c. Instead of a callback function pointer, you register a callback object as well as the selector to invoke on that object. The above class provides an easy way to map from that pattern to a more natural Coffeescript usage - the anonymous function:

  tapProxy = new TargetActionProxy1 (v) -> console.log "you tapped!"
  control.addGestureRecognizer new ui.UITapGestureRecognizer().initWithTarget tapProxy, tapProxy.proxyAction

This syntax is still a little on the objective-c side of things. A better binding would be to expose a “Tapped” event which hides all the proxy stuff from the rest of your code. Several CoffeeKit controls already do this.

Let’s look at the code for RegisterAttribute:

RegisterAttribute github

class RegisterAttribute extends Attribute
  constructor: (obj, name) ->
    super obj
    obj._ck_register = name

    objc.internalRegisterJSType obj.prototype, obj._ck_register, if obj.__super__ then obj.__super__.constructor._ck_register else ''

This is where a lot of the real plumbing in the bindings happens. objc.internalRegisterJSType is a method defined in the CoffeeKit runtime that dynamically allocates an objective-c type and populates it with methods and fields that have been defined in the Coffeescript class. The methods it picks are those decorated with the SelectorAttribute as seen above in the TargetActionProxy1 code, so you can have both methods you expose through objective-c and methods you don’t living in the same class.

The RegisterAttribute code takes care of the second thing attributes are supposed to do (“Any further work…”), but let’s look at its superclass to see how it handles the first thing:

Attribute github

class Attribute
  constructor: (@obj) ->
    Attribute.add obj, this

  @add: (obj, attr) ->
    if !obj._ck_attributes
      obj._ck_attributes = []

    obj._ck_attributes.unshift this

  @find: (obj, attrType) ->
    attrs = if obj._ck_attributes? then obj._ck_attributes else []
    attr for attr in attrs when attr instanceof attrType

Here’s where the list of attributes is built up. The Attribute class also provides a handy method (find) which will return all the instances of the supplied attribute type that have been applied to a given object.

Since the attribute constructor is just code, there’s no limit to what it can do. CoffeeKit contains attributes which actually manipulate the type to which they’re applied (MixinProtocolAttribute and ConformsToProtocolAttribute), which provides for much more compact binding code.

There’s also no limit to when the attribute constructor can do its work. Attributes don’t have to be applied to toplevel classes. Indeed, classes in coffeescript don’t have to be at the toplevel either. But more on that when we get to autoboxing.

This post is already getting rather long, but definitely check out coffeekit.coffee in git, where all the Attribute subclasses (and a lot other cool plumbing) are defined.

A note on syntax

As I said above, I consider this syntax to be wart. But really, it’s the destination syntax for a new piece of sugar. Now it’s just a matter of figuring out which tastes the sweetest.

I have a few ideas bouncing around in my head. The .NET syntax won’t fly because [Foo] is a perfectly legal array in javascript, regardless of where it’s placed.

maybe something like:

attribute syntax experiment #1

# I think the ()'s help set it off a bit?
@attr(MySpecialClass)
class Foo

  # so meybe instead of the ()'s here
  @attr(ASpecialMethod)
  DoSomethingSpecial: -> ...

  # we could do them like?
  (@attr ANotSoSpecialMethodAttribute, "The reason it's not so special is rather boring as well")
  DoSomethingNotWorthMentioning: -> ...

that has issues with the @ syntax because attr could be a function defined at the toplevel scope, which @ would resolve to in the outer context (but not in the inner, where it would result to Foo - ugh).

Or maybe something like (the #[] borrowed from Rust, but it runs afoul of coffeescript’s comment character):

attribute syntax experiment #2

#[MySpecialClass]
class Foo

  # or maybe...
  @[ASpecialMethod]
  DoSomethingSpecial: -> ...

I haven’t even begun to play with the ideas seriously, more than just pushing symbols around. whatever syntax is chosen it can be made to work, and the transformation is very easily understood from the sugar to the resulting form. Please leave comments if you have feelings for/against these ideas, or if you have a better one - or even pointers to other languages that have similar constructs.

ciao for now!

A CoffeeKit Introduction

2011-12-06T08:19:00-08:00

CoffeeKit is where I’ve been putting a lot of my energy recently. It’s a project with a rather simple aim: Let web developers take advantage of native OSX and iOS apis at the same time as they’re able to use the existing browser (and node.js) infrastructure apis they already know.

For example, you can fetch data from webservices the same way you would in a web app, and populate a UITableView with it. You can draw to a canvas using webgl, except that canvas is now a fully-fledged UIView in a native iOS app and can respond to gestures and make use of UIAnimations.

You also open your code up to an exciting amount of reuse. The same business logic can exist in three different places:

On the server, running under node.js
In the browser.
In natively built mobile apps, selling like hotcakes in app stores.

You get to code in JavaScript or anything that transpiles to it (including my personal choice at the moment: coffeescript).

Here’s a list of the web apis presently in CoffeeKit:

And a couple of things that are coming:

enough talk, let’s look at a tiny snippet:

A small example snippet

@primeButton = ui.UIButton.buttonWithType ui.UIButtonType.roundedRect
@primeButton.setTitle "Click to generate primes", ui.UIControlState.normal

@primeTextField = new ui.UITextField().initWithFrame new foundation.NSRect 0, screenBounds.height/2+50, screenBounds.width, 50

@primeCount = 0
@primeButton.clicked = =>
  @worker = new Worker './prime-worker'
  @worker.onmessage = (msg) =>
    @primeTextField.text = "Prime #{++@primeCount}: #{msg}"

This is a pretty simple example that creates a native button and textfield. When the button is clicked a Web Worker is spawned, and whenever that worker sends us a message we update the text in the textfield.

Here’s the JavaScript for the worker:

prime-worker.js

var n = 1;
search: while (true) {
  n += 1;
  for (var i = 2; i <= Math.sqrt(n); i += 1)
    if (n % i == 0)
      continue search;
    // found a prime!
  // postMessage(n); coffeekit only supports string messages for now
  postMessage(""+n);
}

This code was lifted directly from a W3C example for web workers.

In the next post I’ll go over how the bindings are written, and show some of the novel (all JavaScript) goodness CoffeeKit brings to the party.

Writing about writing code

2011-12-05T23:35:00-08:00

It’s time to start blogging again. I’ve been far too quiet on this front for too long, mostly because all time spent in front of the computer has been taken up with generating code, or generating posts that have to fit within 140 characters.

And now that I have an interesting and useful project in the works, expect to see a lot about it here.