From iTunes Preferences

In iTunes Preferences on the Devices tab you should see a list of all iPhone backups that have been saved on this machine.  The list shows the device name and backup date for every device that was backed up.  When you hover your mouse over the backup, a yellow pop-up will appear with the serial and IMIE number.

Grab it From the Backup File

If you’re more the geeky type, you can also recover this info directly from the backup file.  Go to your User home directory, ~/Library->Application Support->MobileSync->Backup.  The backup folders are long sequences of letters and numbers so you will have to make an educated guess for the correct device based on the backup date.

When you open the backup folder you’ll see more files with long string names, but scroll down and you’ll find a file named Info.plist.  To read this file you will need “Property List Editor” which comes with Xcode, or a third party app. You need OSX to do this, Windows doesn’t support Xcode to my knowledge.

Once you open the .plist file your device Serial Number is listed.  You will also find your IMEI number as well as a bunch of information about your iPhone.

The solution so far is to write a custom authentication plugin plus a component for Joomla.  The plugin handles sign-on and the component allows us to render basically anything within the content area of the Joomla site.  I was able to get proof-of-concept running today and not only does the Phreeze code render correctly inside the Joomla system, it wasn’t even necessary to merge the Phreeze code, it runs just fine with the source code in a separate folder from Joomla.  The component just has to do a little magic and configure some paths to make Phreeze happy.

This seems to be one of those rare moments where strict coding practices actually pays off.  I designed Phreeze to be an extremely modular MVC / ORM with the idea that we might one day use another rendering engine, or switch data engines.  We’re even in the process of swapping out direct database connection with REST services with no change to the views, which will be exciting.  Dependency injection is used for all the various parts so you can swap anything.  But I hadn’t really considered running the entire framework within another system.  So I was somewhat surprised when the code just ran with almost no configuration.

The biggest problem is with relative URLs.  Joomla I must say is pretty great about passing control to a component and then staying out of the way, even if you throw lots of weird querystring parameters on the end of the URL.  However, the relative paths to scripts, styles, images, etc are proving to be problematic.

I haven’t decided on the best approach yet but I’m considering simply writing new Views for Joomla.  This allows us to re-use all of our Model and Controller code.  I’d prefer to just use everything exactly as-is in each application but in some ways it might make more sense for the apps to render themselves differently when inside the Joomla system vs when running stand-alone.

Phreeze has a URL writer class which does help to solve the relative URL problem, however we didn’t use it consistently in all the views and so there is some cleanup to do.  Also this class isn’t accessible from within static JavaScript code, so that might get messy with some of the more advanced pages that make a lot of Ajax calls.

This is possibly my nerdiest post ever but it’s exciting to spend so much effort at writing adaptable code and then finally the day comes where you get to see it work in a totally unexpected way.