How to view XML source in Mobile Safari

I see a lot of XML code at Goodreads while working on their iOS app, but some time ago I realized I didn’t have an easy way to see the XML source of a given API response on the iPad. Incidentally, when I realized that I was in bed, and the iPad was the only device within my reach.

So I found this script on ravelrumba.com which worked fine for HTML pages, but not so much with pure XML content.

Being not a JavaScript expert, it took me a while to make the script work on Mobile Safari, but the following fix seems to do its job. The trick was to replace the usage of document.documentElement.innerHTML with XMLSerializer:: serializeToString(), which serializes a XML tree to a string.

Here’s the whole thing. Just add it as a bookmarklet on your Mobile Safari bookmarks bar:

javascript:(function(){var a=window.open('about:blank').document;a.write('
Source of '+location.href+'');a.close();var b=a.body.appendChild(a.createElement('pre'));b.style.overflow='auto';b.style.whiteSpace='pre-wrap';b.appendChild(a.createTextNode((new XMLSerializer()).serializeToString(document.documentElement)))})();

Advertisement

Steve Jobs

apple.com 2011-10-05 at 10.43.35 PM

When Steve Jobs died, the world lost a complex visionary. The asshole who declared floppy disks obsolete in circa 1989. The weirdo that gave us the NeXT cube, with its absurd magnesium body, its beautifully architected OS and this obscure language no-one else was using, Objective-C. The man who gave a name to those strange devices called “MP3 players” that nobody was using, and who insisted on the necessity of single-button mice. Not forgetting the businessman unafraid to admit his LSD experiences.

You don’t see too many people like that. More holistically, this guy made me understand that engineering and business can meet with art and idealism, and for that I am grateful.

GitHub love

I imported some of my open source code over to GitHub. I have to say I was surprised how easy and smooth the import went from my old svn repository. The whole history seems to have been imported nicely.

Beside importing SimpleTimer (my first Cocoa app: beware, its code might not be the prettiest!), this is the first release of CLutils, my collection of C/C++/Objective-C functions built over the years. There’s not much structure in it, beside subdividing it by deployment platforms (Mac OS X, iOS and cross-platform code) and OS X APIs (Carbon, Cocoa).

http://github.com/ettore/SimpleTimer/
http://github.com/ettore/CLutils/

FlashBuilder quirks

I ran into the following weird compile error recently:

compile error:
1071: Syntax error: expected a definition keyword (such as function) after attribute override, not protected.

in relation to the following code:

override 
protected function createChildren():void {}

The solution?

override protected function createChildren():void {}

Don’t even get me started.

Quickly rebuild your iOS app when Provisioning Profile expires

1. Login into the Provisioning Portal, click “Provisioning” on the left side column
2. Renew your expired profile (or create new one) and download it
3. Drag it over the Xcode dock icon (or add it into the Organizer)
4. Remove old profiles from Xcode Organizer
5. Open your Device target. Select the Build tab -> Code Signing Identity, and make sure the new profile is the one in use.
   Xcode has the habit of not automatically updating its targets to use the newly installed provisioning profile. (Even if you physically removed the old one.)

At this point you should be able to rebuild the app.

“The managed object model version” error

While testing out older versions of a Cocoa app — Smultron, a developer text editor which used to work great but now it’s very buggy — I stumbled upon the error:

“The managed object model version used to open the persistent store is incompatible with the one used to create the persistent store”

Apparently this is a Core Data error. To fix it you will have to remove some files Core Data builds, which are usually stored in ~/Application Support/. Differently from what mentioned elsewhere, they are not always XML files. In the case of Smultron they looked like binary files named Smultron*.smultron.

For free apps that are installed via drag and drop (no installer) it’s probably safe to wipe out the whole $HOME/Application Support/APPNAME folder contents. It wasn’t there the first time you launched the app after all. However, payed apps may install license info there, and apps with installers may install other stuff there as well, so one must be careful.

In my case, I removed the whole content of ~/Application Support/Smultron and the error disappeared once I relaunched the app.

Avoid text editor slowdowns when editing MXML files in Flash Builder

Some time ago I noticed that editing text of a medium sized MXML file had gotten extremely slow in Flash Builder 4. With ‘extremely slow’ I mean a painful lag between key presses: you type (or delete) 3 characters, you see one appearing, wait one second, a second one appears and so on. Unbearable. I had just imported my project from Flex Builder 3 and there were no problems there.

Cause? Workarounds?

The problem was that under the Project > Properties > Flex Build Path > Source Path tab I had added a few paths to the source code of some libraries I am using, including Flex. I was using this to jump into the code during debugging. Turns out if you are already linking to those libraries, you can add the path to their source code in the Source Attachment disclosure field of that library under the Project > Properties > Flex Build Path > Library Path tab.

Then remove it from the Source Path tab: the text editor will all of a sudden become super fast. As it should be. The less source paths you have under the Source Paths tab the faster it will be. You’ll still be able to jump into the library source with F3 when needed.

An Adobe employee on the Adobe forums seems to imply there may be some issues with doing this, but after a few weeks I have seen none.