minus zero

The iPhone 2.0 software was recently released, and with it came the ability for users to download native apps (i.e., not web sites) directly to their phones from within the iPhone UI or via iTunes. Developers (anyone who pays Apple 59GBP for the privilege) can then write their own apps and have them available for purchase in the App Store.

One limitation of the Apple-sanctioned SDK is that only one application is allowed to be running at a time. This presents a problem for apps such as IM clients, music players and other programs whose functionality relies on being able to run in the background. Another example (courtesy of James) would be an app that takes advantage of the iPhone 3G's GPS chip to create a log of all the places you visit.

However, there is a neat trick that I discovered: your app will only get terminated if you switch away from it, and hitting the iPhone's power button while your app is in the foreground doesn't count as switching away. The upshot of this is you can create apps which continue to run while the iPhone is in your pocket - perfect for the GPS example.

Achieving this is as simple as implementing two methods in your UIApplication delegate - applicationWillResignActive: and applicationDidBecomeActive:. Here's a simple example to demonstrate the effect.

In your UIApplication delegate header file, add a new ivar: BOOL activeApp. Then, in your implementation, add the following three methods:

- (void)applicationWillResignActive:(UIApplication *)application {
	NSLog(@"resigning active status...");
	activeApp = NO;
	[self performSelector:@selector(sayHello) withObject:nil afterDelay:1.0];
}


- (void)applicationDidBecomeActive:(UIApplication *)application {
	NSLog(@"becoming the active app...");
	activeApp = YES;
}

- (void)sayHello
{
	NSLog(@"Hello!");
	if (!activeApp)
		[self performSelector:@selector(sayHello) withObject:nil afterDelay:1.0];
}

Then run the app on your iPhone, hit the power button, and watch the log fill with pointless but oh-so-cool messages.

Of course, when the phone is put into standby mode by the user the expectation is that barely any juice will be drained from the battery, so it's a good idea for your app to reflect this. Indeed, you can make a big difference by halting your updating of the UI; the user isn't going to see it when the screen is turned off.

This isn't a perfect method, and won't be helpful in situations where the user wants to do other things with their phone while your app continues to run. However it might come in handy for certain scenarios.

While working on a forthcoming project (watch this space...), I decided it'd be a lot easier to test the code on my local machine rather than SUCS's server.

Tiger (yes, I'm a Mac user these days) comes with Apache 1.3, which is rather outdated, so I looked into updating to a more recent release. Fink has Apache 2.0, but I decided to go all-out and try and get Apache 2.2 running. It turned out to be relatively easy.

Here's my setup:

• OS X 10.4.7 on an Apple MacBook
• XCode 2.3
• Python 2.4.3 from python.org

First of all, we need to get Apache compiled and installed.

$ wget http://www.mirror.ac.uk/mirror/ftp.apache.org/httpd/httpd-2.2.3.tar.gz
$ tar zxf httpd-2.2.3.tar.gz
$ cd httpd-2.2.3
$ ./configure --with-mpm=worker --enable-so
$ make
$ sudo make install

That should install Apache into /usr/local/apache2.

Next, download and compile mod_python:

$ wget http://www.mirrorservice.org/sites/ftp.apache.org/httpd/modpython/mod_python-3.2.10.tgz
$ tar zxf mod_python-3.2.10.tgz
$ cd mod_python-3.2.10
$ ./configure --with-apxs=/usr/local/apache2/bin/apxs --with-python=/usr/local/bin/python
$ make
$ sudo make install

That'll build mod_python and put the appropriate files in /usr/local/apache2/modules.

Configuring our newly-compiled Apache to replace OS X's default one is easy enough - a few changes to /usr/local/apache2/conf/httpd.conf and extra/httpd-userdir.conf is all it takes. Download an archive with all the necessary patch files here. Note - these configuration changes don't cause Apache 2 to behave exactly like Tiger's Apache 1.3, and there may be parts I've overlooked that could be exploited.

To apply the patches, run the following as root (from the directory with the extracted contents of the archive):

# patch /usr/local/apache2/conf/httpd.conf httpd.conf.patch
# cp httpd-userdir.conf /usr/local/apache2/conf/extra/.

By now, you should have a working Apache 2 setup on your Mac, but how can we make it start at boot? This is relatively easy - we can use /Library/StartupItems to accomplish this. The zip file contains the files you need to put in this directory to automate Apache's startup.

Unzip the archive and then cp -r Apache2 /Library/StartupItems/. as root.

That's it! To get the server started, you can run sudo /sbin/SystemStarter start "Web Server" and then browse to http://localhost/ to test your new Apache installation! And then, of course, you can dive into the world of Python.

Update - 26^th Jan '07: I had cause to reinstall Apache on a new machine, and the above instructions work perfectly with Apache 2.2.4, mod_python 3.3.0b and Python 2.5. The only change required, apart from the differences in filenames, is to change /usr/local/bin/python to /usr/local/bin/python2.5 on the configure line of the mod_python build stage.

While procrastinating hard in the library, I was taken by a sudden desire to listen to some music from my ever-expanding collection. The only slight drawback was that I'd left my iPod at home, which made it somewhat difficult given that my laptop is devoid of any music.

Realising that my desktop PC has its music shared (using Samba) with the rest of the home LAN, I set about trying to connect to it from my laptop on the University's VPN.

On Windows, the process is as follows:

1. Execute net stop server from the command prompt (Win+R>cmd>OK). This stops Windows' Samba server on the local machine (we're effectively replacing the local server with the remote one).
2. Open PuTTY and select the 'Tunnels' option from the 'SSH' menu in the left-hand pane
3. For each of the following port numbers: 137, 138, 139, 445; enter the port number in the 'Source port' entry box and hostname:X (where hostname is the name of the box with the Samba shares, and X is the same port number you put in the 'Source port' box) in the 'Destination' entry box, and then click the 'Add' button.
4. Return to the 'Session' option at the top of the left hand pane and enter the name of the remote host you're connecting to (in general, the hostname of the internet gateway on the home LAN).
5. It's probably a good idea to save this little setup for future use, so give it a name in the 'Saved Sessions' box and hit 'Save'.
6. Click the 'Open' button, and enter your username and password when prompted (assuming you don't have SSH keys set up...)
7. You should now be able to enter \\127.0.0.1 in the Windows 'Run' box, and after authenticating with a valid Samba username and password you'll be presented with all the visible shares of the remote machine. These can be browsed and mapped to network drives, as with any Samba share.
8. That's it!

Of course, this makes several assumptions - you need to have a machine on the home LAN you can SSH into, for one. But it's a simple hack that seems to work. It's also got the added benefit of being encrypted.

Something like Icecast would probably be a more sensible long-term solution, but for a quick and easy way of listening to your tracks, it does the job nicely. :)