OS X iMIDIProbe Launches!

Now for OS X!

(Cross-posted from The Lone Wolf...)

After quite a bit of work Synthodeon, LLC has finally launched the Mac version of MIDIProbe (its officially called iMIDIProbe in the Mac App store).


To see it you'll have to open the OS X App Store program and search for iMIDIProbe or use the link at the right.  (It's called iMIDIProbe because apparently you cannot have Apps with the same name in both stores - though I am not 100% sure on this.  I had to create the App in the store a couple of times to get things to work and I may have screwed this up myself.)

So if you don't have a Mac you are pretty much SOL at this point as far as this post is concerned...

Basically the Mac version is identical to the iPhone/iPad version - the code base is almost exactly the same.  The only real difference is related to the code that makes it work on OS X.

So at the end of the day this gives me the ability to write non-trivial applications that are the same on both iOS and OS X.

I tried to create an iPhone-like simulation under OS X so the app would like like its running on an iPhone/iPad.  This was tricky because there would no doubt be a legal problem duplicating the appearance of the iPhone Simulator (a tool available to iPhone developers).

I came up with a strategy to make it "look" okay.  I chose the layout above and placed the logo of the app in the upper right corner - that way if you had multiple apps running as simulated iPhone's you could tell which window was which kind of app.

I wanted to use different icons for closing and hiding the app - but the App Store wouldn't allow it so I used the standard OS X red and orange circles.

The core application consists of eleven common Objective-C files: all related to the functionality of the app.

I have ten common Objective-C files that make up the various controls (buttons, etc.).

A dozen or so common files related to MIDI.

And another dozen related to audio stuff.

So a total of about 50 or so Objective-C files that work on OS X and iOS - eleven of which make up the actual app functionality.

The Mac side has about ten more Objective-C files that make up the "container" that manages the Chameleon library, the "window" code that makes the iPhone-like border, the code for managing the App store receipt, and so forth.

The iOS side has far fewer files as the basic code was designed to fit that environment: basically four for everything.

I did not want to move forward beyond this app until I knew what was involved across the board for the OS X and iOS side: I could have done something wrong on either side that would have made the app not work in either store.

But I was successful and now its time to move ahead.

The next project I plan will be in the same order of magnitude as this - with different functionality.  But at least now I know what to do and not do to get things through the store.

In thinking ahead I've been wondering what it would take to move these apps to Windows.  There's a lot involved to do this and I am going to punt for now...

All things considered selling this way is probably going to be the wave of the future and at least now I have a mechanism to do this on multiple platforms.

MIDI Probe Launches...

The first Synthodeon, LLC app has hit the iTunes store.

Read more here.

XCode Problems Again...

The latest XCode periodically displays this message before it crashes:

The document “Foo.m” could not be saved. The file has been changed by another application.


Click Save Anyway to keep your changes and save the changes made by the other application as a version, or click Revert to keep the changes from the other application and save your changes as a version.

Then XCode in its entirety hangs.

A summary of the call back is here:

[NSDocument performAsynchronousFileAccessUsingBlock:][0x7fff8ca40fa1]
[NSDocument _fileCoordinator:coordinateReadingContentsAndWritingItemAtURL:byAccessor:][NSFileCoordinator _coordinateReadingItemAtURL:options:writingItemAtURL:options:error:byAccessor:][NSFileCoordinator(NSPrivate) _invokeAccessor:orDont:thenRelinquishAccessClaimForID:][NSDocument saveToURL:ofType:forSaveOperation:completionHandler:]
[NSDocument saveToURL:ofType:forSaveOperation:completionHandler:][NSDocument saveToURL:ofType:forSaveOperation:completionHandler:]
[IDEEditorDocument saveToURL:ofType:forSaveOperation:completionHandler:][IDEWorkspaceDocument performBlockAfterPreBuildSave:]
[NSDocumentController presentError:]

The cause?  Having two projects open that share a file.

Not actually editing the shared file.

Simply having them open.

XCode 4.2 #import FAIL!

(I've probably covered this in another post but I have gotten more details about the FAIL so I am posting again.)

Imagine a project with two folders A and B.  Folder "A" represents one version of some source code and contains files m1.[m/h] and m2.[m/h].  Folder "B" a version that's an update from "A" - same files but they will be modified.

Now create an XCode 4.2 project based on "A."

Build it and make sure it works.

Now add something that the compiler doesn't like to the m1.h file - a duplicate #define or similar.

Next remove the m1.[m/h] files (from the "A" folder) from the project - don't delete them - just remove the "references." 

Now drag the files from "B" with the same name into the project.

What you will find is that XCode 4.2 continues to look at the files from "A" until you physically rename them in the finder. 

After you rename them in the finder it forgets about them - so clearly its keeping some kind of "hard" reference to the original files even after you've asked it to forget the file.

This is a fundamental flaw as far as I can see - no documentation or much on the internet about it.

I suppose it could be an LVM compiler problem - its hard to tell.

Yet it continues to be a problem for me and its frustrating because this is Project UI 101 as far as I am concerned.

XCode should only include/import files explicitly in the project - even if duplicates are present in other include folders.

Yes, XCode 4.2 Just Destroyed Your Source...

No, I am not insane.

I had two projects.  One points to a set of files in directory A.  The files are D.h and D.m.

I had a second, new project open in XCode 4.2.  It points to directory B.  The files are also D.h and D.m.

These files are similar but not the same as I am refactoring the code and upgrading the code from A to B.  So I am moving code from the old files in A to the new files in B.

Simple enough from a developer perspective.

Well good old XCode 4.2 apparently thinks these are (somehow) the same while both projects are open.  (XCode 3.2.6 knew the difference.)  Magically and incorrectly the file hash project mumbo-jumbo apparently tells XCode 4.2 that somehow the files are not different and the content is interchangeable.

So I spent an hour updating the new files in B - flipping between the two projects.  Stupidly believing that saving files in the B-based project were actually updating the file system.

Suddenly, without warning, in the project referencing B all the changes magically revert back to the original files in A.

All the code changes vanished.

Not a single warning.

Nothing.

I guess the idiots at Apple working on XCode 4.2 never have to do something like this and hence this aspect of XCode never got tested.

XCode should never, ever overwrite files without a warning.

Worse, I am running Lion.  So when I do searches for these files, e.g., D.h, good old Lion only shows "Last Opened" dates.  So if I touch the file by opening it I can no longer tell which D.* was created when.

I have to go back to the regular finder and look to see "Created Date."

I have written before how you cannot copy XCode 4 projects - apparently no one at Apple even imagines one has to do work like this.

Come on, Apple...

Stop your slow death spiral into becoming Microsoft circa 1998.

Fail: -D in XCode 4.2, Desktop Sort in Lion

So two gripes today.

First, XCode 4.2.  I go in and try and add "-DMIDI_TUNNEL" to "Other C flags" in the Scheme Edit thing.  The newly added definition (MIDI_TUNNEL) then instead magically jumps over under the "Other C++ Flags" section - which LLVM promptly ignores because my files are .m (I suppose equal to .c) and not .cpp.

No amount of screwing about with the (-) and (+) minus things works either - making it seemingly impossible to delete the define.

I could not get this to work though I fiddled around for a bit trying different options. I finally put the "-D" into a header in order to get around it for now.

Since I am being forced into the new XCode paradigm at least make it work right.

Secondly why, in Lion, is the Desktop special with regard to sorting files by name, date, etc.  in the Finder?  All the other Finder windows you see look like they have for a decade.  But now the "Desktop" is different.

Looks kind of like a search result: things broken down by recent, so many days ago, and so on.  Worse you cannot click were "Today" appears at the top to sort the view by date, for example.  No does clicking on Type or Date work.

Nope.

You have to use a new drop down near the top.

However, this now presents new date/time sort options - Created, Modified, Added and Last Opened.

While you can change these options the display always shows the date column as "Date Added" - though clicking the dialog appears to have some effect on file order.

Various open file dialogs now use this new format too - again only for the desktop - and display so much new an useless info that the name of the file is hard to see or doesn't fit so it gets truncated with dots (...).

Jobs dies and, without the boss, the rest of them all run amuck turning everything into iPhones...

Adding an Application Delegate in XCode 4.2

A lot of time I will create Cocoa projects (iOS is different to some degree) in XCode one way and later realize I need something that's not part of the standard project "Template."  Or, sometimes, you do something in XCode 4 that breaks the project.  For example, removing files the "wrong way" and not being able to get them "reinstalled" without weird compiler or other errors - so its basically faster to "start over." In any case adding an "Application Delegate" is a common need as in needing an App Delegate to handle functions like "applicationDidFinishLaunching:" To do this quickly add a new file with File>New>New File. Create a Cocoa NSObject subclass - call it AppDelegate or something similar. The .h file should look something like this: @interface AppDelegate : NSObject<NSApplicationDelegate> {   // Put your app-level variables here... } @end The .m similar to this: @implementation ApplicationDelegate // Add the code below to handle app startup items... - (void)applicationDidFinishLaunching: (NSNotification *)aNotification {   // Init your app-level variables... } @end In XCode 4.2 a "MainMenu.xib" is (always?) created along with the Cocoa project.  Open it in InterfaceBuilder by single-clicking. Click the "Show Utilities" in the upper right to reveal the integrated Inspector area at the right (it should slide in from the right). At the bottom select the "Object Library" (3-D black cube) and search for "Object."  The blue 3-D "Object" cube should appear along with several others.  Drag the blue object over into the area on the left holding other objects (under the black 3-D object cube with "main menu" and "font manager" under it). Select it and rename its class (using "Custom Class" in the Inspector on the right) to "AppDelegate" or whatever you called your class above.  The object's name should change to "AppDelegate." Right-click on the File's Owner so reveal the "hookup" menu.  Control-clock and drag from its delegate outlet to your newly named object.  If the hookup succeeds the menu will flash. Save, build and go...