Writing iOS or Cocoa apps does require a Mac with XCode, but you can learn Objective-C (and work on libraries and command-line apps) on Microsoft Windows.

GCC includes an Objective-C compiler. You can install GCC on Windows via Cygwin or MinGW.

You can also get the GNUStep implementation of the OpenStep libraries which includes the same core libraries as Cocoa — including Foundation which contains NSString, etc.

GNUstep includes a graphical environment GWorkspace which is a clone of the NeXT workspace manager. I haven’t gotten GWorkspace (or Backbone and alternative) to work on Windows or any other graphical apps, but you can use graphical GNUstep apps on Linux.

What this means is that the core libraries and command line apps can work on Windows — which is good for learning basic Objective-C concepts.

In order to use GNUstep on Windows install the GNUstep MSYS System — which gives you the core unix-like tools you know and love.

Next install GNUStep Core. You should be able to open a Shell window and execute commands.

Then install GNUStep Devel which will give you GCC with Objective-C and the GNUStep libraries which allow development.

Gorm is an interface builder for GNUStep which allows you to create (admittedly ugly) GNUstep user interfaces via drag and drop — but I couldn’t get it to work on Windows.

Once you have MSYS, GNUStep Core, and GNUStep Devel, launch the shell from your Windows Start menu.

Using a text editor, write a hello world app:

Voila, you’re coding in Objective-C on Windows with GCC!

You can see that your managing memory the old fashioned way. You don’t have ARC, but you can get modern features using clang which is the compiler used by XCode.

Directions for installing clang on Windows are available here:

http://solarianprogrammer.com/2012/03/21/clang-objective-c-windows/

Basically:

1. Checkout LLVM
2. Checkout clang into the llvm/tools folder
3. Edit llvm/tools/clang/lib/Frontend/InitHeaderSearch.cpp

Look for // FIXME: temporary hack: hard-coded paths. (on line 223 currently)


// FIXME: temporary hack: hard-coded paths.
AddPath("C:\\GNUstep\\include", System, true, false, false);
AddPath("C:\\GNUstep\\msys\\1.0\include", System, true, false, false);
AddPath("C:\\GNUstep\\lib\\gcc\\mingw32\\4.6.1\\include", System, true, false, false);
AddPath("C:\\GNUstep\\lib\\gcc\\mingw32\\4.6.1\\include\\c++", System, true, false, false);
AddPath("C:\\GNUstep\\GNUstep\\System\\Library\\Headers", System, true, false, false);
//AddPath("/usr/local/include", System, true, false, false);
break;


4. Compile

cd llvm && mkdir build && cd build
../configure --enable-optimized --enable-targets=host-only
make && make install

An error is expected and not a problem groff: command not found

Now you can use ARC in your Objective-C on GNUstep compiled with clang:

Here’s a sample GNUmakefile:

Now run:

make CC=clang

Now, using a plain text editor (even Sublime Text) for writing code isn’t always fun..But you can use Eclipse.

Install the Eclipse CDT (C/C++ Development tools) and follow the directions here to set up Eclipse for using Objective-C:

http://wirecode.blogspot.com/2007/11/objective-c-and-eclipse.html

I haven’t yet gotten Objective-C to compile with Eclipse CD% yet but I’ll post more when I’ve got it working.

tl;dr

This post describes the construction of a simple, lightweight geospatial data service using Node.JS, PostGIS and Amazon RDS. It is somewhat lengthy and includes a number of code snippets. The post is primarily targeted at users who may be interested in alternative strategies for publishing geospatial data but may not be familiar with the tools discussed here. This effort is ongoing and follow-up posts can be expected.

Rationale

I’m always looking for opportunities to experiment with new tools and the announcement of PostgreSQL/PostGIS support on Amazon RDS piqued my curiosity. Over the past six months, I have run into the repeated need on a couple of projects to be able to get the bounding box of various polygon features in order to drive dynamic mapping displays. Additionally, the required spatial references of these projects have varied beyond WGS84 and Web Mercator.

With that, the seeds of a geodata service were born. I decided to build one that would, via a simple HTTP call, return the bounding box of a polygon or the polygon itself, in the spatial reference of my choice as a single GeoJSON feature.

I knew I wanted to use PostGIS hosted on Amazon RDS to store my data. Here are the rest of the building blocks for this particular application:

1. Node.js
2. Express web application framework for Node
3. PG module for accessing PostgreSQL with Node
4. Natural Earth 1:10M country boundaries

Setting up PostGIS on Amazon RDS

Setting up the PostgreSQL instance on RDS was very easy. I simply followed the instructions here for doing it in the AWS Management Console. I also got a lot of use out of this post by Josh Berkus. Don’t forget to also set up your security group to govern access to your database instance as described here. I prefer to grant access to specific IP addresses.

Now that the Amazon configuration is done, your RDS instance essentially behaves the same as if you had set it up on a server in your server room. You can now access the instance using all of the standard PostgreSQL tools with which you are familiar. This is good because we need to do at least one more thing before we load our spatial data: we have to enable the PostGIS extension. I find that it is easiest to accomplish this at the command line:

psql -U {username} -h {really long amazon instance host name} {database name}

Once you’ve connected, issue the command to enable PostGIS in your database:

CREATE EXTENSION postgis;

You may also want to enable topology while you’re here:

CREATE EXTENSION postgis_topology;

This should complete your setup. Now you are ready to load data.

Loading Spatial Data

As I mentioned above, we are now dealing with a standard PostgreSQL server that happens to be running on Amazon RDS. You can use whatever workflow you prefer to load your spatial data.

I downloaded the Natural Earth 1:10M country polygons for this effort. Once downloaded, I used the DB Manager extension to QGIS to import the data to PostgreSQL. I also did a test import with OGR. Both worked fine so it’s really a matter of preference.

Building the Application

I chose to use Node.js because it is very lightweight and ideal for building targeted web applications. I decided to use the Express web framework for Node, mainly because it makes things very easy. To access PostgreSQL, I used the node-postgres module. I was planning to deploy the application in an Ubuntu instance on Amazon EC2, so I chose to do the development on Ubuntu. Theoretically, that shouldn’t matter with Node but the node-postgres module builds a native library when it is installed so it was a factor here.

After building the package.json file and using that to install the Express, node-postgres, and their dependencies, I build a quick server script to act as the web interface for the application. This is where Express really excels in that it makes it easy to define resource paths in an application.

1
2
3
4
5
6
7
8
9
10
11
12

var express = require('express'),
    geo = require('./routes/geo');

var app = express();

app.get('/countries/:id/bbox', geo.bbox);
app.get('/countries/:id/bbox/:srid', geo.bboxSrid);
app.get('/countries/:id/polygon', geo.polygon);
app.get('/countries/:id/polygon/:srid', geo.polygonSrid);

app.listen(3000);
console.log('Listening on port 3000...');

The four “app.get” statements above define calls to get either the bounding box or the actual polygon for a country. When the “:srid” parameter is not specified, the resulting feature is returned in the default spatial reference of WGS84. If a valid EPSG spatial reference code is supplied, then the resulting feature is transformed to that spatial reference. The “:id” parameter in all of the calls represents the ISO Alpha-3 code for a country. You will notice that the application listens on port 3000. More on that later.

The next step is to define the route handlers. In this application, this where interaction with PostGIS will take place. Note that each of the exports correspond to the callback functions in the app.get statements above.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79

var pg = require('pg');
var conString = "postgres://username:password@hostname.rds.amazonaws.com:5432/database"; //TODO: point to RDS instance

exports.bbox = function(req, res) {
    var client = new pg.Client(conString);
    client.connect();
    var crsobj = {"type": "name","properties": {"name": "urn:ogc:def:crs:EPSG:6.3:4326"}};
    var idformat = "'" + req.params.id + "'";
    idformat = idformat.toUpperCase();
    var query = client.query("select st_asgeojson(st_envelope(shape)) as geojson from ne_countries where iso_a3 = " + idformat + ";");
    var retval = "no data";
    query.on('row', function(result) {
      client.end();
        if (!result) {
          return res.send('No data found');
        } else {
          res.setHeader('Content-Type', 'application/json');
        //build a GeoJSON feature and return it
          res.send({type: "feature",crs: crsobj, geometry: JSON.parse(result.geojson), properties:{"iso": req.params.id, "representation": "extent"}});
        }
      });

};

exports.bboxSrid = function(req, res) {
    var client = new pg.Client(conString);
    client.connect();
    var crsobj = {"type": "name","properties": {"name": "urn:ogc:def:crs:EPSG:6.3:" + req.params.srid}};
    var idformat = "'" + req.params.id + "'";
    idformat = idformat.toUpperCase();
    var query = client.query("select st_asgeojson(st_envelope(st_transform(shape, " + req.params.srid + "))) as geojson from ne_countries where iso_a3 = " + idformat + ";");
    var retval = "no data";
    query.on('row', function(result) {
      client.end();
        if (!result) {
          return res.send('No data found');
        } else {
          res.setHeader('Content-Type', 'application/json');
          res.send({type: "feature",crs: crsobj, geometry: JSON.parse(result.geojson), properties:{"iso": req.params.id, "representation": "extent"}});
        }
      });
};

exports.polygon = function(req, res) {
    //TODO: Flesh this out. Logic will be similar to bounding box.
    var client = new pg.Client(conString);
    client.connect();
    var crsobj = {"type": "name","properties": {"name": "urn:ogc:def:crs:EPSG:6.3:4326"}};
    var idformat = "'" + req.params.id + "'";
    idformat = idformat.toUpperCase();
    var query = client.query("select st_asgeojson(shape) as geojson from ne_countries where iso_a3 = " + idformat + ";");
    var retval = "no data";
    query.on('row', function(result) {
      client.end();
        if (!result) {
          return res.send('No data found');
        } else {
          res.setHeader('Content-Type', 'application/json');
          res.send({type: "feature", crs: crsobj, geometry: JSON.parse(result.geojson), properties:{"iso": req.params.id, "representation": "boundary"}});
        }
      }); };

exports.polygonSrid = function(req, res) {
    var client = new pg.Client(conString);
    client.connect();
    var crsobj = {"type": "name","properties": {"name": "urn:ogc:def:crs:EPSG:6.3:" + req.params.srid}};
    var idformat = "'" + req.params.id + "'";
    idformat = idformat.toUpperCase();
    var query = client.query("select st_asgeojson(st_transform(shape, " + req.params.srid + ")) as geojson from ne_countries where iso_a3 = " + idformat + ";");
    var retval = "no data";
    query.on('row', function(result) {
      client.end();
        if (!result) {
          return res.send('No data found');
        } else {
          res.setHeader('Content-Type', 'application/json');
          res.send({type: "feature",crs: crsobj, geometry: JSON.parse(result.geojson), properties:{"iso": req.params.id, "representation": "boundary"}});
        }
      }); };

The PostGIS spatial SQL for each function is shown in the “client.query” calls in the code above. This approach is very similar to constructing SQL calls in a number of other application environments. You will notice that a coordinate reference system object is constructed and attached to each valid response, which is structured as a GeoJSON feature. The code currently assumes EPSG codes but that may be addressed in a future version.

The above modules do most of the heavy lifting. The full code for this sample is available here.

To test the application, simply issue the following command in a terminal:

node server.js (this assumes you are running from the same directory in which server.js resides. The file extension is optional.

Your web application is now listening on port 3000. In a browser, visit the following URL:

http://localhost:3000/countries/irl/bbox

This should return a GeoJSON feature representing the bounding box of Ireland in WGS84. You can then test the other three calls with appropriate parameters. To get the bounding box in Web Mercator, go to:

http://localhost:3000/countries/irl/bbox/3785

Deploying the Application

The application should now be ready to deploy. In my case, I created an Ubuntu EC2 instance (free tier). Using SSH, I made sure Node and git were installed on the machine. Additionally, I installed Forever which allows a Node application to run continuously (similar to a service on Windows). This can also be done using an upstart script but I chose Forever. I may switch to using PM2 at some point.

Now, it’s simply matter of installing the application code to the instance via git, wget, or the method of your choice. Once installed, be sure to go to the folder containing the code and issue the “npm install” command. This will read the package.json install Express, node-postgres, and other dependencies. Since some native code is built in the process, you may need to issue the command under sudo.

I mentioned above that the application listens on port 3000. The Ubuntu instance, by default, will not allow the application to listen on port 80. This can be mitigated in a number of ways but I issued the following command to redirect traffic from 80 to 3000. Since this instance is single-use, this approach is sufficient.

sudo iptables -t nat -A PREROUTING -p tcp –dport 80 -j REDIRECT –to-ports 3000

Once you are ready to go, you’ll want to start the application with the following command:

forever start server (again assuming you are executing from the directory containing server.js)

A couple of Amazon notes: 1) You may want to assign an elastic IP to your instance for a persistent IP address and 2) you’ll want you remember to configure your RDS security group to allow access from your instance’s IP address.

Conclusion

If everything has gone correctly, you should be able to execute the above URLs (using your instance IP address) and get a response like the following, which you should be able to load directly into QGIS or another GeoJSON-literate client. Altogether, I was able to assemble this in one evening. This small collection of open-source tools, combined with the Amazon infrastructure, seems to provide a straightforward path to a hosted geodata service. This example is intentionally simple but PostGIS provides a robust collection of functions that can be exploited in a similar manner, leading to more advanced processing or analysis. I will continue my experimentation but am encouraged by what I have seen so far.

Sample Response

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

{
  "type": "feature",
  "crs": {
    "type": "name",
    "properties": {
      "name": "urn:ogc:def:crs:EPSG:6.3:4326"
    }
  },
  "geometry": {
    "type": "Polygon",
    "coordinates": [
      [
        [
          -10.4781794909999,
          51.4457054710001
        ],
        [
          -10.4781794909999,
          55.386379299
        ],
        [
          -5.99351966099994,
          55.386379299
        ],
        [
          -5.99351966099994,
          51.4457054710001
        ],
        [
          -10.4781794909999,
          51.4457054710001
        ]
      ]
    ]
  },
  "properties": {
    "iso": "irl",
    "representation": "extent"
  }
}

this ‘map’ is actually a static image

The parties example bundled with Meteor is a nifty demonstration of the framework’s core principles, but it uses a 500 x 500 pixel image of downtown San Francisco as a faux map. This means that we cannot pan or zoom the “map,” and when we double-click the image to create new parties, the circle markers are drawn at the position of the clicks in relation to the image element in the browser window, and not at geospatial coordinates.

circles drawn over the static image

I decided to update the example to use Leaflet.jsto make a real map that looked and felt as close to the original example as possible. In particular, I wanted to preserve the color-coded circles (red for private, blue for public parties) labeled with the number of RSVPs, and the larger animated circle indicating which party is currently selected, with its details displayed in a section outside the map. This is a useful pattern for displaying individual marker details without using a popup that occludes part of the map.

Here is the end result with source code. In the next two posts, I will go over the changes I made to the original example. I won’t be covering how Meteor works, and will assume you have some understanding of how the parties example works as well.

Setting the Stage

First off, I created the example and added leaflet to the project using Meteorite.

1
2
3
4
5
6

$ meteor create --example parties

$ cd parties

$ mrt add leaflet
leaflet: Leaflet.js, mobile-friendly interactive maps....

I then edited the page template to use Bootstrap’s fluid classes to generate a responsive page layoutand added a window.resize() handler to adjust the map’s size as the browser is resized. I use this pattern when creating responsive Leaflet maps, and it’s not specific to Meteor.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<div class="container-fluid">
  <div class="row-fluid">
    <div class="span4">
      {{> details}}
      {{#if currentUser}}
      <div class="pagination-centered">
        <em><small>Double click the map to post a party!</small></em>
      </div>
      {{/if}}
    </div>
    <div class="span8">
        {{> map}}
    </div>
  </div>
</div>

1
2
3
4
5

$(window).resize(function () {
  var h = $(window).height(), offsetTop = 90; // Calculate the top offset
  $mc = $('#map_canvas');
  $mc.css('height', (h - offsetTop));
}).resize();

Map Initialization

Stamen Design’s toner themed map tiles make a nice replacement for the black & white map image in the example. I disabled double-click and touch zoom when initializing the map since those actions are how users create new parties, and I increased tile opacity to lighten the overall background and improve the visibility of markers on the map. Leaflet initialization code goes into the map template’s rendered() callback.

1
2
3
4
5
6

map = L.map($('#map_canvas'), {
  doubleClickZoom: false,
  touchZoom: false
}).setView(new L.LatLng(41.8781136, -87.66677956445312), 13);

L.tileLayer('http://{s}.tile.stamen.com/toner/{z}/{x}/{y}.png', {opacity: .5}).addTo(map);

The next significant change was to replace the map template’s event handler from the original example with Leaflet’s "dblclick" event handler to manage the creation of new parties. The Leaflet version conveniently returns a LatLng which I saved to a Session variable before triggering createDialog. The mechanism to trigger dialogs by setting the associated Session variables Session.showCreateDialog and Session.showInviteDialog is unchanged from the original example, and it works because Meteor Session variables are reactive.

1
2
3
4
5
6
7

map.on("dblclick", function(e) {
  if (! Meteor.userId()) // must be logged in to create parties
    return;

  Session.set("createCoords", e.latlng);
  Session.set("showCreateDialog", true);
});

1
2
3
4
5
6
7

<template name="page">
  {{#if showCreateDialog}}
    {{> createDialog}}
  {{/if}}
  ...
  ...
</template>

Creating and Saving a Party to the Database

This part of the application is also more or less unchanged from the original example except that I passed the party’s LatLng (instead of click position) along with other details from the createDialog template to the Meteor.methods() call to createParty. If the callback is successful, the new party’s _id is saved to another reactive Session variable Session.selected, which drives the details template on the left.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

var title = template.find(".title").value;
var description = template.find(".description").value;
var public = ! template.find(".private").checked;
var latlng = Session.get("createCoords");

Meteor.call('createParty', {
  title: title,
  description: description,
  latlng: latlng,
  public: public
}, function (error, partyId) {
  if (! error) { //party was successfully added to the server's mongo collection
    Session.set("selected", partyId);
    ...
  }
});

Adding Markers to the Map in Realtime

As soon as a new party is added to the Parties mongo collection on the server, behind the scenes, Meteor transmits it back to a client-side minimongo collection with the same name on all connected and authorized clients. This can be verified by typing Parties.findOne() into the JavaScript console. This is well and good, but the next task is to replace the D3 code to draw circles from the original example with code to add Leaflet markers to the map.

To do that, I hooked up a cursor.observe() added() callback to create the map marker and I added a click handler to the marker to update the Session.selected variable with the party’s _id. As users click on different parties, this reactively triggers the context for the details template on the left. I also saved a reference to the marker in a local markers hash to efficiently access the marker for future changes. Since we only need to set this up once, I put this code into the maptemplate’s created() callback.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

var map, markers = {};

Template.map.created = function() {
  Parties.find({}).observe({
    added: function(party) {
      var marker = new L.Marker(party.latlng, {
        _id: party._id,
        icon: createIcon(party)
      }).on('click', function(e) {
        Session.set("selected", e.target.options._id);
      });
      map.addLayer(marker);
      markers[marker.options._id] = marker;
    },
    ...
    ...
  });
}

The final bit of fanciness here is my createIcon() helper function to create a lightweight DivIconthat uses a simple div element instead of an image icon. I used CSS border-radius to style the div as a circle of the appropriate color and set CSS line-height to the height of the div to vertically center the text. The attending() helper function from the original example returns the number of Yes RSVPs.

1
2
3
4
5
6
7
8
9

var createIcon = function(party) {
  var className = 'leaflet-div-icon ';
  className += party.public ? 'public' : 'private';
  return L.divIcon({
    iconSize: [30, 30], // set size to 30px x 30px
    html: '<b>' + attending(party) + '</b>',
    className: className
  });
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

.leaflet-div-icon {
  border-radius: 50%;
  border: none;
  line-height: 30px;
  font-family: verdana;
  text-align: center;
  color: white;
  opacity: .8;
  vertical-align: middle;
}

.leaflet-div-icon.public {
  background: #49AFCD;
}

.leaflet-div-icon.private {
  background: #DA4F49;
}

Now I can log in and create a few parties, and they all show up as markers with the appropriate color and label. When I click on a marker, its details are automatically rendered into the details template on the left. But there’s no visual indication on the map as to which party is currently selected — I just need to remember which marker I clicked on last! As it turns out, this usability quirk is easy to address.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

{
  _id: "22dQwpajD64LCv4QW",
  title: "1871",
  description: "Party like it's 1871!",
  latlng: {
    lat: 41.88298161317542,
    lng:  -87.63811111450194
  },
  public: false,
  owner: "52xdsNjprquesL2tQ",
  invited: ["52xdsNjprquesL2tQ", "ci7bzkJCpH9R7HCZK", "5qhRdKFcsmPnxZKBr"]
  rsvps: [
    {
      rsvp: "yes",
      user: "52xdsNjprquesL2tQ"
    },
    {
      rsvp: "maybe",
      user: "ci7bzkJCpH9R7HCZK"
    }
  ]
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

var map, markers = {};

Template.map.created = function() {
  Parties.find({}).observe({
    added: function(party) {/* see previous post */},
    changed: function(party) {
      var marker = markers[party._id];
      if (marker) marker.setIcon(createIcon(party));
    },
    removed: function(party) {
      var marker = markers[party._id];
      if (map.hasLayer(marker)) {
        map.removeLayer(marker);
        delete markers[party._id];
      }
    }
  });
}

1
2
3
4

L.divIcon({
  iconSize: [50, 50], // set to 50px x 50px
  className: 'leaflet-animated-div-icon'
}

1
2
3
4
5
6

.leaflet-animated-div-icon {
  border-radius: 50%;
  border: none;
  opacity: .2;
  background: black;
}

I recently wrote a blog post on the ShinobiControls blog about using ReactiveCocoa with a ShinobiChart. It’s great – you should go and read it. I was also invited to give a talk at #bristech around the same time, and thought that this blog post would make a really interesting topic. The audience at #bristech is not an iOS audience. Not even mobile-focused. It’s very much a mixed discipline event, with a heavy focus on javascript (lowest common denominator etc.). Therefore I decided a general talk on functional reactive programming, with ReactiveCocoa examples would be a great place to go.

One of the things non-Cocoa developers complain about is the somewhat alien appearance of objective-C. Now, I don’t really think this is a valid complaint, but in the interests of making my talk more accessible, I decided that if the examples I gave were in Swift then fewer people would be frightened off.

And so begins the great-swiftening. I took the original project which accompanied the previous blog post, and swiftified it. There were a few things I thought might be useful to share. This post is the combination of those thoughts.

Bridging Headers

Bridging headers are part of the machinery which enables interaction between swift and objective-C. They’re well-documented as part of Apple’s interoperability guide. Essentially, there is a special header inside your project (specified with a build setting) into which the objective-C headers for the classes you wish to use with Swift should be collected.

The ReactiveWikiMonitor project uses 3 objective-C libraries:

• ShinobiCharts
• SocketRocket
• ReactiveCocoa

Therefore, the bridging header looks like this:

1
2
3

#import <ShinobiCharts/ShinobiChart.h>
#import <SocketRocket/SRWebSocket.h>
#import <ReactiveCocoa/ReactiveCocoa.h>

It’s actually that easy! I love how simple interoperability is at this level. However, if you try and compile this (with your Podfile created correctly and pods installed) then you’ll run in to some problems within the ReactiveCocoa source.

Compiling ReactiveCocoa in a Swift Project

If you try to build a project now, then the compiler will first attempt to compile your pods – including ReactiveCocoa. Do it. You’ll see that it doesn’t work – you get a compiler error around the methods and, or and not on RACSignal+Operations. This is because of a compiler bug, which will hopefully be fixed in a future release, but until then we can work around it by renaming those methods in the ReactiveCocoa source.

Find the RACSignal+Operations.h file in the CocoaPods project, and rename the aforementioned methods to rac_and, rac_or & rac_not. You’ll have to repeat this in the related implementation (.m) file as well. You can then find all the places that use these methods, by attempting a build (there are only about three places in the RAC source). Fixing each call by changing its name will work. Note that it might also be possible to do this using Xcode’s refactor tools, but I’ve not had the most success in the past.

Now your project will build, yay!

Using generics to improve syntax

One of the things I like about objective-C is the implicit casting available in the arguments to blocks. By this I mean the following is the signature for a map function in RAC (defined on RACStream):

1

- (instancetype)map:(id (^)(id value))block;

Which means that when creating a map stage in your pipeline, it would look like this:

1
2
3

map:^id(id *value) {
     return value[@"content"];
 }]

The block returns an id, and takes an id for the value parameter. This is so that in objective-C you can build a functional pipeline which can process any datatypes (since generics don’t exist). However, the syntax allows you to specify (and therefore implicitly cast) these parameters, by defining your block like this:

1
2
3

map:^NSString*(NSDictionary *value) {
     return value[@"content"];
 }]

Although not strictly necessary (since the compiler will allow you to call any methods on an id), it just allows you to have additional type checking at compile (and writing) time.

And now we move our attention to the world of Swift. The Swift equivalent to id is AnyObject, so the map function now looks like this:

1
2
3

.map({ (value: AnyObject!) -> AnyObject in
  return value["content"]
})

If you attempt to build this code then (as of beta2) the compiler will crash. In order to make this work you might think that the following would work:

1
2
3

.map({ (value: NSDictionary!) -> NSString in
  return value["content"]
})

However, Swift’s type system doesn’t like this (with a somewhat cryptic and misplaced error message). Therefore you need to explicitly cast:

1
2
3
4
5
6

.map({ (value: AnyObject!) -> AnyObject in
  if let dict = value as? NSDictionary {
    return dict["content"]
  }
  return ""
})

You have to do this every time you want to call a map function, which in my opinion is a little bit clumsy.

Which brings us to Swift’s generic system, and type inference.

A generic version of map

The syntax I’d like to use is:

1
2
3

.mapAs({ (dict: NSDictionary) -> NSString in
  return dict["content"] as NSString
})

So how do we go about building this mapAs() extension method. Well, extending a class in Swift is easy:

1
2
3
4
5

extension RACStream {
  func myNewMethod() {
      println("My new method")
  }
}

We’re going to create a generic mapAs() method, which includes the explicit downcasting and the call to the underlying map() method:

1
2
3
4
5
6
7
8

func mapAs<T,U: AnyObject>(block: (T) -> U) -> Self {
  return map({(value: AnyObject!) in
    if let casted = value as? T {
      return block(casted)
    }
    return nil
  })
}

This specifies that the mapAs method has 2 generic params – the input and output, and that there is a requirement that the output be of type AnyObject. The closure we pass to the mapAs() method takes the first generic type and returns the second.

All the mapAs() method does is call the underlying map() method, but performs the downcasting as appropriate.

We can write a similar method for filter:

1
2
3
4
5
6
7
8

func filterAs<T>(block: (T) -> Bool) -> Self {
  return filter({(value: AnyObject!) in
    if let casted = value as? T {
      return block(casted)
    }
    return false
  })
}

This obviously can be extended to all the methods on RACStream, RACSignaletc.

I find that using these generic methods (combined with Swift’s type inference), leads to a much more expressive pipeline:

1
2
3
4
5
6
7
8
9
10
11

wsConnector.messages
  .filterAs({ (dict: NSDictionary) in
      return (dict["type"] as NSString).isEqualToString("unspecified")
    })
  .mapAs({ (dict: NSDictionary) -> NSString in
    return dict["content"] as NSString
    })
  .deliverOn(RACScheduler.mainThreadScheduler())
  .subscribeNextAs({(value: NSString) in
    self.tickerLabel.text = value
    })

Conclusion

This is very much an interim piece of work. We can expect RAC3 to be swift-focused, and so these techniques won’t be required. However, they don’t just apply to RAC. Using generics to simplify block arguments is especially helpful when interfacing with objective-C which uses id as a type.

As ever, the code for this is available on the ‘swiftify’ branch of the ReactiveShinobi project on my github. If you don’t fancy having to fiddle with the ReactiveCocoa source once you’ve pulled it down, there’s also a swiftify_with_pods branch, which includes the source code changes.

sam