The concept of an address book or contacts feels so lame and dated, it’s like ‘an address book is this little thing with this faux leather cover!
— Matias Duarte

Touché! The Address Book app is a sore point in the iOS (and Mac OS X) experience.

It is a chore to use this application to update contacts information and the “real life” user interface makes it even more frustrating.

⚑

It’s too bad that James Duncan Davidson announced they shut down the Daily Shoot when I finally have a good camera in my pocket all the time everyday.

⚑

The purpose of this post is so that I will have a link to give people when they ask: how do I write an iOS application that pulls data from an RSS feed, displays it pretty and can put things on a map. I’ll show you all of that and more as I rewrite my oldest iOS application from scratch: FuelView.

A recommended article which explains how to design and write a simple but not too simple iOS application.

⚑

At first, I was using Aperture‘s Places to manually locate the pictures but this is a long and tedious process. Sometime, I shot a picture with my iPhone (which contains GPS data) and import them in Aperture to geotag my camera pictures. But more often than not, I forget to do that and have to do it manually.

I could add a GPS device to my camera directly but they are expensive, bulky, and drain the battery. Why buy another GPS device when I always have my iPhone with me?

After some research, I settled on using gps4cam and I am very happy with it.

gps4cam comes in two parts:

• an iPhone app (App Store link)
• a free Mac or PC application (available from their web site)

When I go outside and start shooting, I just need to run the iPhone app and start a new trip. The app supports multitasking, so I can exit the app, put the phone in my pockets and not worry about it anymore. I can focus on shooting instead.

Periodically, the app will capture my GPS location. The app is configurable and you can specify the frequency, to use GSM to triangulate the position instead of GPS (useful when abroad), etc.

At the end of the trip, when I am done shooting, I export the trip which generates a QR Code.

I then shoot this QR code with my DSLR. This picture contains all the GPS information captured during my trip. The fantastic idea of using QR codes is that there is no need to synchronize the iPhone and camera clocks: the QR code generated by the iPhone and shot with the other camera allows to know the clock difference between the two devices and deduce where the camera photography were taken.

The last step to do is to use the desktop application which reads the QR code and put the GPS data in the other pictures’ EXIF metadata¹.

Finally, I can import the pictures in Aperture or any other software and voila! My pictures are (almost automatically) geotagged.

The iPhone is simple, non-obtrusive and a steal at 1.59€ (or $1.99). It is a pleasure to use it and I haven’t noticed a specific battery drain.

On the opposite, the desktop application needs more spit and polish. It is a Java application, I use it on my MacBook and it does not feel at home. The UI is not consistent with the OS (the progress is shown with a modal dialog window instead of a sheet or a progress bar) and it is too slow.

As I understand it, the desktop applications takes 3 steps:

• analyze the pictures (to find which one contains a QR code)
• retrieve the GPS data from the QR code picture
• copy the pictures and store the GPS data in their EXIF metadata

I don’t understand why it should take several minutes to perform these 3 steps (for a trip where I took only 40+ pictures). I suppose the performance could be improved by identifying faster the QR code picture. One way could be to let the user chooses the QR code picture (as I propose in the mock screenshot below by using an Image Well):

This would work fine if there is only one “trip” (i.e. one QR code) in the pictures but this will not work if there are many of them…

The desktop application also needs to improve the user experience. I put GPS data directly in the pictures on my SD card before I import them. Every time, the application asks me if I am sure to do that and I must confirm.
Instead, the application should let me check a box to say that I don’t want to be warned next time and remember it. If anything bad happens, it is my fault, I explicitly told the application to not warn me anymore.

Pros:

• unobtrusive and configurable iPhone application
• trips can be exported as GPX (and visualized in Google Maps, Google Earth, etc.)
• inexpensive

Cons:

• desktop application’s UI needs more attention (I would prefer a native Mac application)
• desktop application takes too long to process pictures and store GPS data

I hope that the cons will be fixed in future releases.
But as it stands now, I heartily recommend gps4cam to any iPhone user who wants to geotag automatically their pictures taken with another camera.

1. I specify the same directories as input and output to store GPS data directly on the pictures on the SD card. ↩

Last time, I created the first version of the Web application to move a piece when the user moves the iPhone and coded a simple Web server on top of node.js.

The Web application works fine but it is not pretty and there are a few things we can improve. Before looking at Web Sockets and other fancy code, let’s make the Web application prettier.

iPhone Standalone Web Application

The major annoyance is that Safari chrome takes a lot of space and hides the bottom of the board:

To display a Web application without Safari chrome, we can make it a standalone Web application.

In index.html, we add some <meta> information to the <head> part:

<head>
  ...
  <meta name="viewport" content="width=device-width, user-scalable=0" />
  <meta name="apple-mobile-web-app-capable" content="yes" />
  <meta name="apple-mobile-web-app-status-bar-style" content="black">
</head>

The viewport meta ensures that the Web page will be sized to the device width and prevents the user to change the page scale (by pinching it).

The apple-mobile-web-app-capable will launch the Web application in full-screen mode (without Safari chrome) to look like a native application. The Web application must be added to the iPhone home screen and start from there to appear in full-screen mode.

Last thing is to render the iPhone status bar in black by setting the apple-mobile-web-app-status-bar-style to black.

With these 3 meta information, the Web application looks better and display the whole board

Offline Support

At the moment, node.js serves only static pages. When the iPhone has loaded the Web application, it no longer connects to the Web server.

Let’s add offline support so that we can run the Web application even when the server is down (or unreachable).

HTML5 supports offline applications through the cache manifest. The best introduction on the subject is the Offline chapter in Dive into HTML5.

For this Web application this means that we must write a cache.manifest file:

CACHE MANIFEST
 
CACHE:
/screen.css
/client.js
/jquery.min.js

This cache manifest tells the Web browsers to call all these files to run the Web application offline.

This cache manifest must be declared in the entry point of the Web application (index.html in this case) with the manifest attribute of the html element:

<!doctype html>
<html manifest="/cache.manifest">
...

Finally, we need to update server.js to send the cache.manifest file with the correct HTTP Content-Type. Only the getContentType()function needs to be modified:

function contentType(path) {
   if (path.match('.js$')) {
      return "text/javascript";
   } else if (path.match('.css$')) {
      return  "text/css";           
   } else if (path.match('.manifest$')) {
      return  "text/cache-manifest";
   }  else {
      return "text/html";
   }
}

With this modification, cache.manifest will be sent to the Web browser with the correct text/cache-manifest Content-Type.

We must restart the server to take into account the server.js modification:

$ node.js server.js
HTTP server running at htpp://0.0.0.0:8080

I can then reload the Web application and add it to the iPhone home screen. With offline support, I will be able to use the Web application even if the server is not running or unreachable.

Here is a small video of the result with the updated Web application:

Note the black status bar and the full screen mode after I started the Web application from the iPhone home screen. It is indistinguishable from a native application but runs on the Web (it’s not obvious from the video but the camera was recording from above: the iPhone was held horizontally)

Source Code

I have pushed the application on Github. You can clone it with Git:

git clone git://github.com/jmesnil/board-node.git

Conclusion

By adding a few meta information to the Web application, it is possible to make it look better integrated to the iPhone.
Offline support is trickier than this simple example make it look like but it gives the right idea to start dealing with it.

Next step is to add Web Sockets support to the node.js to display the moving pieces of other users on the Web application.

Further Reading

• Safari Web Content Guide
• HTML5 Offline Web applications (and its corresponding “Dive into HTML5″ chapter)

On the server, I want to learn more about node.js which is an interesting way to develop server-side applications. On the client-side, I also wanted to check what can be done with HTML5 on iPhone and iPad with the release of iOS 4.2.1.

I will write a simple web application to do both at the same time. The idea is simple enough but will allow me to dive into node.js and HTML5 quite extensively.

The idea is to write a web application that display a piece moving on a board when the user moves its device. Later on, I will expand it so that the user will also see the pieces of all others users connected to the server.

But the first iteration will be enough to familiarize with:

• node.js (to serve static content at first)
• Canvas API (to draw the board and the piece)
• DeviceOrientation Event API (to detect the orientation of the mobile, it was added in iOS 4.2.1)

Web Server

I will use node.js as my Web server (I installed it from Git by following the build instructions on its web site).

The first version of the server needs to serve static files with the correct HTTP Content-Type. At first, it will serve only HTML pages, CSS stylesheets and JavaScript files.

The whole server.js code is:

var http = require('http');
var url = require('url');
var fs = require('fs');
var sys = require('sys');
 
// the HTTP server
var server;
// the HTTP port
var port = 8080;
 
server = http.createServer(function(req, res){
  var path = url.parse(req.url).pathname;
  if (path == '/') {
     path = '/index.html'
  }
  console.log("serving " + path);
  fs.readFile(__dirname + path, function(err, data){
     if (err) {
        res.writeHead(404);
        res.end();        
     } else {
        res.writeHead(200, {'Content-Type': contentType(path)});
        res.write(data, 'utf8');
        res.end();
     }
  });
});
 
function contentType(path) {
   if (path.match('.js$')) {
      return "text/javascript";
   } else if (path.match('.css$')) {
      return  "text/css";           
   }  else {
      return "text/html";
   }
}
 
server.listen(port);
console.log("HTTP server running at htpp://0.0.0.0:" + port );

The code is straightforward: when a request is handled by the server, it looks in the current directory (where server.js is) for a file with the given path and writes its content in the HTTP response body.
The contentType(path) function checks the file suffix to use the correct HTTP Content-Type for the response.

It will serve files from http://<server-name>:8080/.
For the rest of the example, I will use the name of my machine, blackbook.local: to access the Web application from my iPhone, I am using http://blackbook.local:8080.

In future iterations, I will add more interesting code to node.js (to use WebSockets for example) but for the moment this simple server is enough.

Web Application

Let’s now focus on the client-side part of the Web application.

index.html

The Web application is loaded from a single HTML5 page, index.html:

<!doctype html>
<html>
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, user-scalable=0" />
  <title>Board</title>
  <link rel=stylesheet href=screen.css>
</head>
<body>
  <canvas id="board" width="320" height="460"></canvas>
 
  <script src='jquery.min.js'></script>  
  <script src="client.js"></script>
</body>
</html>

The page contains a single <canvas> element named board. All the code to draw on the canvas is in client.js JavaScript file.

client.js

client.js contains code to:

• get orientation information from the device (using the DeviceOrientation Event API)
• draw the board and the piece based on the orientation information (using the Canvas API)

First, it defines a few constants used to draw the board and the piece:

var kBoardWidth = 320;
var kBoardHeight = 460;
var kCircleRadius = 32;

The piece object is defined literally:

var piece = {
   center : {
      x: kBoardWidth / 2,
      y: kBoardHeight / 2,
      xShift : 0,
      yShift : 0
   },
   color: "#000"
};

The piece has a center position with its coordinates (initially at the center of the board) and its acceleration on the x and y axes, and its color is black.

I use jQuery to bootstrap the application when the document is ready:

$(document).ready(function() {
   var board = document.getElementById("board");
   var context = board.getContext("2d");
   window.addEventListener("devicemotion", function(event) {
      var accel = event.accelerationIncludingGravity;
      piece.center = computeCenter(piece.center, accel);
      drawGrid(context);
      drawPiece(context, piece);
   }, true);
});

First we keep a reference on the board canvas that was declared in the HTML page and its associated 2D context. The context will be used to draw the piece and the board on the canvas.

We use the DeviceOrientation API (supported by the iPhone and the iPad since iOS 4.2.1) to detect the acceleration of the device. Periodically, the browser will call the handler associated to the devicemotion event.
When that happens, the handler retrieves the accelerationIncludingGravity property, compute the new center position of the piece and draw the board and the piece on the canvas.

The method to draw the board is using the 2D context (the board is displayed as a grid):

function drawBoard(context) {
   context.clearRect(0, 0, kBoardWidth, kBoardHeight);
   for (var x = 0.5; x < kBoardWidth; x += 10) {
       context.moveTo(x, 0);
       context.lineTo(x, kBoardHeight);
   }
   for (var y = 0.5; y < kBoardHeight; y += 10) {
      context.moveTo(0, y);
      context.lineTo(kBoardWidth, y);
   }
   context.strokeStyle = "#eee";
   context.stroke();
}

The code to draw the piece is also using the 2D context to draw a circle from the piece’s center and its color:

function drawPiece(context, piece) {
   context.fillStyle = piece.color;
   context.beginPath();
   context.arc(piece.center.x, piece.center.y, kCircleRadius, 0, Math.PI * 2, false);
   context.closePath();
   context.fill();
}

Finally, we need to compute the updated position of the piece’s center based on its current position and the acceleration information from the browser:

function computeCenter (oldCenter, acceleration) {
   newCenter = {};
   newCenter.xShift = oldCenter.xShift * 0.8 + acceleration.x * 2.0;
   newCenter.yShift = oldCenter.yShift * 0.8 + acceleration.y * 2.0;
   newCenter.x = oldCenter.x + oldCenter.xShift;
   // use *minus* to compute the center's new y
   newCenter.y = oldCenter.y - oldCenter.yShift;
   // do not go outside the boundaries of the canvas
   if (newCenter.x < kCircleRadius) {
      newCenter.x = kCircleRadius;
   }
   if (newCenter.x > kBoardWidth - kCircleRadius) {
      newCenter.x = kBoardWidth - kCircleRadius;
   }
   if (newCenter.y < kCircleRadius) {
      newCenter.y = kCircleRadius;
   }
   if (newCenter.y > kBoardHeight - kCircleRadius) {
      newCenter.y = kBoardHeight - kCircleRadius;
   }
   return newCenter;
}

To smooth the movement and increase the acceleration when the mobile is moved, I applied a low-pass filter:

newCenter.xShift = oldCenter.xShift * 0.8 + acceleration.x * 2.0;
newCenter.yShift = oldCenter.yShift * 0.8 + acceleration.y * 2.0;

The rest of the method ensures that the piece will remain in the boundaries of the board.

screen.css

Last thing is to make sure that the canvas fills the whole Web page by removing the margin and padding on the body element. This is done through CSS in the screen.css file:

body {
   margin: 0px;
   padding: 0px;
}

All these files are located in the same directory than server.js.

Run the example

Let’s start the node.js server:

$ node server.js
HTTP server running at htpp://0.0.0.0:8080

Now, from my iPhone, I go to the Web page on http://blackbook.local:8080 (if you go on the Web application from your machine, nothing will happen since the devicemotion event is not available on desktop browsers).

As I have not found a way to prevent the iPhone to change the screen orientation when it is moved, I have locked the iPhone in portrait mode before running the Web application.

Here is a small video of the result:

It’s not obvious from the video but the camera was recording from above: the iPhone was held horizontally.

Source Code

I have pushed the application on Github. You can clone it with Git:

git clone git://github.com/jmesnil/board-node.git

The code is slightly different as I have already started the next iteration but the main idea remains the same.

Conclusion

With a few lines of JavaScript on both the client and server sides, it is possible to:

• use node.js to write a Web server returning files
• use the Canvas API to draw things on a Web page
• use the DeviceOrientation Event API orientation to have interaction between the device and the Web page

Next steps will be to improve the user experience:

• make the application appear as a standalone application on the iPhone home screen and remove Safari chrome
• support offline mode to use the Web application even when the server is not running

Further Reading

• node.js
• Canvas API (and its corresponding “Dive into HTML5″ chapter)
• DeviceOrientation Event API

I just received my copy of Cocoa Programming. At first glance, the book seems a good update for Mac OS X development.

It has been quite a few months since I did Mac (and iPhone) programming. I have not looked deeply at Core Data and Grand Central Dispatch yet. I also want to experiment with Objective-C blocks.

I need to find a suitable idea for a Mac application to prototype and experiment. Any idea or suggestion is welcome!

TangTouch and TangTouch Lite are displayed in the grey area at the top of the iPhone shell, below the last two 0 of 10,000+

[via Daniel Jalkut]

For the posterity, the paper prototype for TangTouch‘s main view:

and the 1.0 release available from the App Store:

The Preferences paper prototype:

and the 1.0 version:

TangTouch is now available on the App Store.
It is a Tangram puzzle game for the iPhone or the iPod Touch.

I wrote this game as a way to learn more about Objective-C and Mac/iPhone development. The bulk of the application was written months ago but I waited until I had an iPhone 3G to finish it and test it in situ.

It’s a very simple game but I find it quite fun to play (being the author, it’s possible I’m biased…)

I released 2 versions:

• a commercial version with more than 200 puzzles
• a free version with 32 puzzles

This way you can download the free version with no strings attached. And if you like it, you can buy the commercial version.

Enjoy!