However, I didn’t just want to rotate each view but instead have a different layout of the view. I didn’t want to hardcode all the positions so I though about something along the lines of creating a second xib file that works as a template to arrange the original xib’s views for landscape.

It turns out that this is actually pretty easy. As long as the views are in the same structure in both xib files, one can just traverse the view tree by iterating over the subviews of a view.

I’ve created a class called BSUIViewRearranger. It can be used pretty easily by calling the following code in your view controller:

[BSUIViewRearranger rearrangeView: self.view

                            toMode: toInterfaceOrientation 

                 usingLandscapeNib: @"MainViewLandscape" 

                       portraitNib: @"MainView"

                   controllerClass: [self class]];

[UIView animateWithDuration:duration animations:^(void) {
 // code here
}];

I’ve released the code on github in case someone wants it.

@_karsten_

Today Peter Hosey asked on Stack Overflow about an interesting stack trace. Obviously the writeWithFormat() function didn’t crash recursively. So it appears that the crashlog is lying to us about the function that makes trouble. No need to panic, there’s plenty of useful information left in the crashlog to help us find the bug. First of all there are offsets:

0   com.growl.GrowlSafari        0x179d383c writeWithFormat + 25

1   com.growl.GrowlSafari        0x179d388e writeWithFormat + 107

2   com.growl.GrowlSafari        0x179d388e writeWithFormat + 107

... 

So the first frame is at offset 0x179d383c and all the other frames are at offset 0x179d388e. The only way to make sense out of these numbers is to use otx to disassemble the binary and look at the offsets to find out what’s really being called (the current svn version of otx is much more current, if you don’t mind compiling the tool yourself).

Before we can start disassembling we first need to know which file to disassemble. Fortunately the crashlog contains that information at the very beginning.

Process:         Safari [2062]

Path:            /Applications/Safari.app/Contents/MacOS/Safari

Identifier:      com.apple.Safari

Version:         5.0 (6533.16)

Build Info:      WebBrowser-75331600~5

Code Type:       X86 (Native)

Parent Process:  launchd [84]

PlugIn Path:       /Applications/GrowlSafari.app/Contents/Resources/GrowlSafari.bundle/Contents/MacOS/GrowlSafari

PlugIn Identifier: com.growl.GrowlSafari

PlugIn Version:    1.2.1 (1.2.1)

So i’m sure everyone agrees that Safari doesn’t need to be disassemble, even though the crashlog says so in the Path. The crashlog is kind enough to tell us which plugin causes the crash, so we can take the plugin’s path as input to otx and pipe it to TextWrangler‘s command line tool:

otx -arch i386 /Applications/GrowlSafari.app/Contents/Resources/GrowlSafari.bundle/Contents/MacOS/GrowlSafari | edit

Another indication to disassemble the plugin are the frames, as they all contain the identifier of their bundle: com.growl.GrowlSafari.

So now we have the disassembly of the plugin, but the offsets of the crashlog cannot be found. The offsets produced by otx start at 0x00000f54 and go to 0x000024f3. That’s not nearly close to 0x179d383c. The reason behind that is simple: the plugin’s code is mapped into the memory where the linker things it got some space left. So we need to find out where the plugin was mapped in order to find the right spot in the disassembly.

Again, the crashlog got all the information that is needed. At the end of the crashlog is a list of all the plugins, frameworks and bundles, that are loaded into the application at the time when the crashlog was taken.

It looks like:

Binary Images:

    0x1000 -   0x526ffb  com.apple.Safari 5.0 (6533.16) <5CC91F2A-7709-6B9E-069D-C6E408F1A14B> /Applications/Safari.app/Contents/MacOS/Safari

 0x1340000 -  0x1340ffc +com.growl.GrowlSafariLoader 1.1.6 (1.1.6) <BF586D9F-39A9-BD06-1C83-6F1E527822CA> /Library/InputManagers/GrowlSafari/GrowlSafariLoader.bundle/Contents/MacOS/GrowlSafariLoader

 0x13b3000 -  0x13b3ff7  com.apple.JavaPluginCocoa 13.2.0 (13.2.0) <6330F04D-3250-2071-42E4-0ABB54216529> /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/JavaPluginCocoa.bundle/Contents/MacOS/JavaPluginCocoa

So the first two numbers are the start and end offsets of the mapped binary. The application itself is typically mapped to the beginning, which always starts at 0×1000. The provided information also includes the bundle identifier, version numbers, a unique id and the path. I have actually no idea what the + before com.growl.GrowlSafariLoader stands for, so if anyone knows, please tell me .

Searching for our bundle identifer reveals this line:

0x179d2000 - 0x179d4ff7 +com.growl.GrowlSafari 1.2.1 (1.2.1) <10F1EF69-D655-CCEE-DF3A-1F6C0CF541D3> /Applications/GrowlSafari.app/Contents/Resources/GrowlSafari.bundle/Contents/MacOS/GrowlSafari

It appears that 0x179d2000 is our base offset. Subtracting that from our offsets gives us the offsets 0x183c and 0x188e. Subtracting is pretty easy in our case, but in general subtracting hex numbers is done easiest in gdb:

p/x 0x179d383c - 0x179d2000

Now that we have our correct offsets, we can have a look at the disassembly of that offset to see what’s going on.

i’ve already added some comments at the two offsets that are shown in the stack trace. First thing that one sees is that the disassembly has proper method names and the offsets both are inside the myInitWithDownload:mayOpenWhenDone:allowOverwrite: method. At offset 0x188e (the offset that all the frames show) there’s a movl instruction, but this is not the instruction we are looking for. The instruction right before the movl is a calll instruction. As the name suggest, it calls a function but on return it continues at offset 0x188e, which is why we see this offset in the stack trace. Otx is kind enough to annotate the calll instruction with Objective-C-like comments that show which function is called. It appears that the function calls itself, thus causing a recursion and the crash. Usually one wouldn’t program a function to call itself, but in that case the method is part of a MethodSwizzle, where this is normal behavior (MethodSwizzling can be done easily with Wolf Rentzsch‘s JRSwizzle project).

So why is the method swizzling not working in our case? The answer is again shown in the crashlog: there are actually two versions of the plugin loaded into Safari at the same time.

 0x140c000 -  0x140efff +com.growl.GrowlSafari 1.1.6 (1.1.6) <1E774BDF-5CC5-4876-7C66-380EBFEAF190> /Library/InputManagers/GrowlSafari/GrowlSafariLoader.bundle/Contents/PlugIns/GrowlSafari.bundle/Contents/MacOS/GrowlSafari

0x179d2000 - 0x179d4ff7 +com.growl.GrowlSafari 1.2.1 (1.2.1) <10F1EF69-D655-CCEE-DF3A-1F6C0CF541D3> /Applications/GrowlSafari.app/Contents/Resources/GrowlSafari.bundle/Contents/MacOS/GrowlSafari

I think the reason for the crash is that both plugins define the same method and when the second plugin swizzles its methods, the original implementation of Safari is probably swizzled out and only the two patched methods are left. I think the older patch is called first, resulting in a call to the new patch, which then recursively calls itself. Maybe before swizzling two methods one should check if there was a swizzle before and reverse it before applying a second swizzle.

But those mind swizzling details are probably not too important for the actual fix for this crash and also don’t have much to do with our little excursus to crashlogs-wonderland. I hope you enjoyed the trip

@_karsten_

The bug is pretty easy to reproduce:

echo "warning: ohoh"
echo "error: meh"

@_karsten_

you can find it at: http://github.com/karstenBriksoft/PlistExplorer

Karsten (@_karsten_)

While this is pretty handy it also ties the created files tightly to your application. If you try to open such a file you need to have all the needed classes at hand. That’s a pretty ugly problem if you just want to know what’s inside the file.

Yesterday I had this exact problem and I’ve played around a bit until I had a tool that allows me to inspect any file that was written with an NSKeyedArchiver. NSArchiver is not yet supported.

Thanks to ObjC 2 this was relatively easy to do: If a class is missing, create it and retry to unarchive. That’s pretty brute force but I didn’t see no other way. With some private methods in NSKeyedArchiver I was also able to get all the keys of an Object. With the classes present and with the keys available I could then read all the Objects.

The tool is available here: PlistExplorer.zip

Usage: PlistExplorer <file>
It’ll write the content to stdout so you might want to pipe it to something like TextWrangler.

The tool comes with no warranty whatsoever. Use at your own risk.

Karsten (@_karsten_)

After reading Pimp My Code 17: Lost in Translation I knew that this was gonna be the way to go for CuteClip’s Localization. I’ve finally had time to implement things. However, it was a bit messy and didn’t work out of the box as I would have expected it. So here’s a small Q/A of the questions that I came up with during the change.

Which strings go to which file?

Strings from the application that are used like NSLocalizedString(“key”,”comment”); go to Localizable.strings. Same as usual. Strings of Nibs however go into NibName.strings.
I.e: MainMenu.nib or MainMenu.xib has its strings in MainMenu.strings.

CuteClips uses plugins a bundles a lot. How are those Nibs looked up?

The lookup-change in DMLocalizedNibBundle.m is implemented on class-side in NSBundle. Every instance call is sent to [NSBundle mainBundle]. So all strings-files need to go to the MainBundle’s Resources folder.
If your plugins have a MainMenu.xib then there’s no separate file. If your plugin has a different name, like in CuteClips, you end up have multiple strings files.
I.e: Here i’ve got Localizable.strings, MainMenu.strings and OldUI.strings

How the heck do I convert my existing localized Nibs to strings files?

That’s a bit tricky! First you need to get the strings out of the Nib, which can easily done by using ibtool:
ibtool —generate-stringsfile MainMenu.strings MainMenu.nib

Not too difficult, but the devil is in the details: If that was a german Nib and you got a button called “Abbrechen” you wouldn’t find a line like “Cancel” = “Abbrechen”; in the strings-file. Instead you’ll have “Abbrechen” = “Abbrechen”. That doesn’t help much when your application tries to translate “Cancel” as it wouln’t find the key. Luckily that’s not the only information that you can find in the strings-file. Each translation also has a comment next to it that contains an ObjectId. Using this ObjectId you can use the english MainMenu.strings to convert the keys of the german MainMenu.strings. That doesn’t work for all translations though, so you need to fix the files by hand as well.

Another problem here is that many translations appear multiple times, so you might want to get rid of the clones.

I’ve written a little Smalltalk tool in VisualWorks but it should work in any Smalltalk Environment. Usage is simple:

    to convert the translation-keys to english:
    Converter new convert: '/Path/To/Project/German.lproj'
    to filter out the clones:
    Converter new filter: '/Path/To/Project/German.lproj'
     

The tool will create *.fixed.strings files by default.

You can load the tool at:TranslationScanner

I think that’s it.

One thing that i’d like to add: One of my resolutions for this year is finally joining Twitter. I did so on the last day of 2009 and my nick is _karsten_.

Happy New Year!

Karsten

This was caused by the fact that we migrated to a new, more powerful server in order to better satisfy the sudden increase in traffic generated by the incredible interest Snapplr caused

I apologize for any inconvenience this has caused you, but now we are Harder, Better, Faster, Stronger

Plans for the future are grand, but of course we cannot reveal anything yet. Stay tuned, and enjoy Snapplr!

In the previous beta one could not make screenshots of menus or utility windows. The problem was that Snapplr always activated and thus deactivated the frontmost application. That was needed because Snapplr needs the keyboard input for best usability. The system’s screen capture tool doesn’t need to activate and still receives the keyboard events. We thought that if this tool can do that, Snapplr can do that as well.

NSApplications can’t capture all keyboard events when they’re not active. This seems to only works for command line applications… and only if you do an animal sacrifice at new moon . So we ended up extracting the screenshot selection into a new terminal tool that is now called by Snapplr upon activation. Unfortunately that also ment porting the NSView UI to a CoreGraphics UI.

During this week we really noticed that it totally pays out if you keep refactoring your code and if you have a good design. We could just drop a couple of classes in the main application and extract their functionality into the terminal tool without much effort.

We also updated the server-side of Snapplr. As of now it is not required to have accounts anymore. We decided that accounts are just too much of an inconvenience for the user.

The new beta is available to all existing beta users. The previous beta should automatically load the new version on launch.

Stay tuned, Snapplr just made a huge step towards final release.

Karsten