Mixtikl iPhone release soon?

It sometimes feels like I've been working on Mixtikl for iPhone for my entire life. :)

Anyways, we've made a great deal of progress over the past months, and are now aiming to submit the app to the App Store in around 4 weeks. Knowing the way things go, we'll no doubt slip by a few weeks, but it is good to have a date to target.

As for how long it'll take to get the app actually listed on the App Store; well, we'll just have to see what happens!

We'll also be rolling-out Mixtikl 1.5 to all the other platforms at the same time. Much to do! :)

Parallels 4

Last week, I help my brother configure his new Mac Book Pro. On this, we installed Parallels, so he can use Windows XP easily without rebooting from Mac; and sometimes when booted directly into Windows (mainly, for using legacy Windows Audio tools where he wanted minimum audio latency). The whole idea behind this is to help him transition to doing more work on Mac and less under Windows...

I was a bit worried about installing Parallels, having previously had real problems with it; but his installation went fine, and all seems to be working well. Actually, the performance is pretty impressive!

Things went wrong for me a while back when I had Parallels 2; using this, my Windows partition got corrupted pretty early on, so I gave up and moved to a BootCamp solution. I got the Parallels 3 upgrade when it came out, so that I could try to use my Boot Camp partition with Parallels; but this also corrupted Windows for some reason, leading to yet another re-installation and dumping of Parallels. Well, as my brothers installation of Parallels 4 had gone well, I decided to try yet again..!

I bought the upgrade from Parallels 3 to Parallels 4, and converted the BootCamp on my wife's Mac Book to use Parallels (figuring it best to try on her Mac, rather than my main development Mac!). This went well; so I took the plunge and converted my Boot Camp on my Mac Book Pro using a new (non-upgrade) Parallels 4; this also went well. Phew! :)

However... I then found that I'd installed Parallels for Boot Camp slightly wrong for my wife's machine, and had to track-down instructions on how to enable parallels for her when logged on as her (not just when logged-on as me!). The solution was a pain, and required me to change her account to be an admin account (something that is not documented in the instructions I followed...); but at least it all works now and she can do most of her work now in Mac OS!

You might wonder why I went through all this hassle. The primary reasons are that Mac OS is a lot faster to start-up, and the battery lasts longer in MacOS. I have to do a lot of development work in Mac OS and Windows; and it is a pain to have to reboot between the two; so if I can use Mac OS has my main base, and use Windows whenever I need to, then that saves me a lot of time week-by-week. In the case of my wife, she needs to use Windows for only one thing, which is some Internet Explorer magic to do access her office network. We have found that Open Office 3.1 now lets her open and edit all of her work-related documents, without the need for Microsoft Windows; and she can work the same way in both MacOS and Windows.

It seems that in the main, the tools that most people use most often are the web browser and office tools. We use Firefox for both Windows and Mac, and Open Office for both Windows and Mac; so the operating system is less relevant. This brings me back to secondary issues of speed of start-up and longer battery life; where the Mac wins.

I was also pretty impressed to find that even when booted into Mac OS, running Windows XP in the Parallels VM, I can use Visual Studio 2007 running Mixtikl in a Windows Mobile emulator, debugging real-time audio code without any audio break-up. That is partly because my Mac Book Pro is pretty fast, and also because Parallels 4 really does seem to offer great performance. I wonder when I'll next feel the need to boot-up via Boot Camp?

One more reason for using Windows XP under the Parallels VM, is that just last week I discovered the wonderful Spaces mode in Mac OS, which gives me a dead-easy to use Virtual Desktop. This works brilliantly for me, and has already transformed my development process. There is no build-in virtual windowing mode that I can see in Windows XP, which has long frustrated me... anyways, Spaces also works very well with an external monitor, and/or when using Windows via the Parallels VM. Great software!

Running iPhone UI code from other than the main thread

If you've got a relatively complex multi-threaded app, where you need to have something happen in the UI in response to an event occuring in a thread that is not the main thread, then you're going to have to be careful!

Basically, what you need to do is use performSelectorOnMainThread to execute your code that does UI work; as otherwise the UI calls you make will probably cause your iPhone app to crash!

The way to do this is to create an instance of an Objective-C++ (or C!) wrapper class that has a method on it which'll do the UI work for you (and could well have a modal loop within it, like for yesterday's post). That method could be something simple, like:

- (void)DoTheUiStuff
{
  // All the UI code is here
}

Derive this class from NSObject (or maybe UIView, of course!).

You can then invoke this method through a selector, passed to your call on your class instance to performSelectorOnMainThread. When this call returns, you're safe to clean-up your wrapper class instance and get back to whatever your thread was up to in the first place...

Running a UIAlertView modally

The funny thing about UIAlertView (and other iPhone modal interfaces), is that they don't actually run modally; in other words, you can't do something simple like this:

bool bResult = [myUIAlertView runModal];

Rather, the UIAlertView has a show method ... which shows the dialog, but which doesn't simply hang around and give you a result when done.

What you need to do in this situation, is create a delegate to handle the message generated when the UIAlertView button is pressed; and you must then provide you own modal processing loop!

Here is a simplified version of what you need to do. Spot the code loop that makes it all run modally!

// Create an instance of a custom UIAlertViewDelegate that we use to capture
// the events generated by the UIAlertView
MyUIAlertViewDelegate *lpDelegate = [[MyUIAlertViewDelegate alloc] init];

// Construct and "show" the UIAlertView (message, title, cancel, ok are all
// NSString values created earlier in your code...)
UIAlertView *lpAlertView = [[UIAlertView alloc] initWithTitle:title message:message delegate:lpDelegate cancelButtonTitle:cancel otherButtonTitles:ok,nil];

[lpAlertView show];

// Run modally!
// By the time this loop terminates, our delegate will have been called and we can
// get the result from the delegate (i.e. what button was pressed...)
while ((!lpAlertView.hidden) && (lpAlertView.superview!=nil))
{
[[NSRunLoop currentRunLoop] limitDateForMode:NSDefaultRunLoopMode];
MySleepMilli(10);
}

// Grab the result from our delegate (via a custom property)
int nResult = [lpDelegate result];

// Tidy up!
[lpAlertView release];
[lpDelegate release];

Hope that helps!

Vim - easy to install MRU list

If you want an MRU list in your vim window for Windows/Linux (which is very useful, trust me!) then simply follow the instructions you'll find here to install a really useful Vim plug-in:

mru.vim : Plugin to manage Most Recently Used (MRU) files

This works very well with with the vims I've tried it on so far, which are gvim and cygwin vim on Windows, console-based vim and gvim on Linux, as well as console vim and MacVim on the Mac.

Even though an MRU system of sorts is already built-in to MacVim, I still recommend using this vim plug-in as it also works very well with MacVim.

iPhone Ad Hoc Distribution gotcha

Here is a good one - if you forget to update the version number in your iPhone app (through the info.plist file): and then try to install the App to your iPod/iPhone as an Ad Hod distribution, iTunes will prompt you to upgrade your app; but will actually fail to upgrade the app at all. :)

In this case, you could either first delete the app and re-install (but this would lose any app-specific data of course); or re-build with a new version number!

On another note, if you try to just zip-up your app with the Compress feature in Finder, and send that - it won't capture enough information, and will fail to install on your ad-hoc target devices. Instead, you should copy your app file to a folder, use Disk Utility to create a DMG file from that folder, and then zip-up the DMG file; and send that on to your testers. That will work. :)

iPhone - clearing the Bonjour jungle

Phew: the Mixtikl file sharing code seems to be pretty much sorted out now. It has been a lot of work, but it is great to be able to have Mixtikl on the Mac share files with Mixtikl on the iPhone (in both directions!) through the local network.

I like the way that you can copy a Tiklpak from Mixtikl on your Mac, to Mixtikl on the iPhone, and use it immediately on your iPhone without having to restart. Nifty!

I can now get back to tidying-up the skin code to accomodate Tim's latest design. And when that is done: we'll be in a position to submit Mixtikl 1.5 to the App Store...

Just for the record though, if the iPhone allowed the desktop machine to connect to the iPhone, such that the desktop could read/write data into an "public" area specific to each app; that would have made everybody's lives so much easier without breaking the sandbox model.

The approach taken in Windows Mobile is much more flexible - just copy files around as you want, using Explorer and Active Sync ... though of course the fact that Mixtikl for iPhone has an integrated solution will make it really easy for Mixtikl users with a Mac. Windows users with an iPhone will not find things so easy though...

Fun with Bonjour and NSRunLoop

You know, I keep coming back to not liking much of the implementation behind Cocoa, no matter how much I use it!

Here is the sort of thing that irritates me. I create a dialog within Mixtikl (using our own internal GUI framework), and run it modally. Within that Dialog, I use Cocoa services to request to be told what Bonjour-advertised services are available. What do I get? Well, nothing, other than a call through the delegate to tell me that searching has started.

It turns out that the processing behind the scenes works only if the active NSRunLoop is allowed to do processing; so I've had to add-in a call like this in my modal loop:


[[NSRunLoop currentRunLoop] limitDateForMode:NSDefaultRunLoopMode];


So you might ask, what is wrong with this? I contend that for such processing, the system should be smarter and use an approach that doesn't require specific magic within the client code (in this case, a worker thread that does the work without my having to worry about blocking it). Otherwise, people who know a lot less than me might never be able to figure-out what they've done wrong.

Bonjour is a great idea, and is built-in to Mac/iPhone: however, I can't spot any open-source implementation that I can use for other platforms. If any reader would be kind enough to point me to such an implementation, I'd love to take a look!