OCaml App for iOS 8.1 (Sources)
I coded up a simple OCaml iOS app to run in iOS 8.1. Instructions for downloading, building, and running the app are here:
You can download the sources directly here:
This is a revamped version of Portland, the first example OCaml iOS app I made a few years ago. For maximum clarity it doesn’t do anything particularly impressive. It really just shows how to code an iOS app in OCaml.
Here are some things I learned while revamping.
Remember to call
caml_main()
in your main program (seemain.m
). If you forget, you’ll get the “undefined atom table” error at link time. I wrote about this in Undefined caml_atom_table.If you keep disembodied OCaml values in the Objective C world, remember to register them as global roots using
caml_register_global_root
. Otherwise you’ll experience chaos at the first GC. I wrote about this in OCaml, Objective C, Rule 4.Automatic Reference Counting imposes some restrictions on what you can do in wrapper code. For the Portland example (and probably for many real-world apps) it’s enough to have a table of Objective C objects that are conceptually referenced from OCaml. That is, the table in the Objective C world references the objects as a proxy for references from the OCaml world. You can see the code for this in
wrap.m
. I hope to write more about this. Maybe you, reader, have some ideas for a better approach.Modern day iOS apps are based on View Controllers rather than on Views. In particular, it’s usual to define a custom subclass of
UIViewController
for each piece of the interface. This is tricky for OCaml on iOS, as it’s not (currently) possible to define an OCaml subclass of an Objective C class. For Portland I’m using an Objective C subclass ofUIViewController
that delegates to an OCaml object. Here too, this is probably good enough for many real-world apps. I hope to write more about this also.There are several cyclic dependencies among the classes of Cocoa Touch used in Portland. To represent them in OCaml I use a common set of definitions named
ui.mli
, where the cycles can be accommodated usingclass type a =
…and b =
… . It seems to me this is a strength of OCaml’s structural typing for objects. That is, it’s possible to define class types independently of particular classes. In this way cycles can be represented without forward-reference loopholes. (However it’s possible that the number of cycles in a full interface to Cocoa Touch would become overwhelming.)
It’s dark, chilly, and wet here by Puget Sound; I’m going to retire now to my tent and my dreams. The next thing on my OCaml-on-iOS schedule is to update to the latest OCaml compiler. I’m getting serious polymathic help on this, as I hope you’ll hear about soon.
If you have any trouble (or success) with the Portland app, or have any other comments, leave them below or email me at jeffsco@psellos.com.
Posted by: Jeffrey