Tag Archives: Xcode

Architecting with Blocks part 2

(Note: This is part 2 of a series of posts about Architecting an application using blocks in objective-c. By no means I am an expert on using blocks, and also it’s not the intention of this series to teach you how to use blocks. You can check this for that. To finalise, I am sure there are better ways to use blocks while architecting an app: use this at your own risk. :))

This is the final post from a 2 parts series that I start a long ago. In this case I won’t show any snippet of code, I will give away an entire sample. My approach about this matter, change in the meantime, nonetheless hope you enjoy it. You can find it here .

Tagged , , , , , , ,

Xcode Hidden features

A nice thread @ stackoverflow about hidden features in Xcode

Tagged , ,

TestFlight + Xcode + Archive Post-Script = win

Imagem

For some time now I wondered how I could do automatic uploads to Test Flight. As you might have guessed, they allow to make builds uploads by using their API, which is quite straightforward. So, I read somewhere that some people already had created scripts to do this automatically for you. A big bonus here, is that Xcode, allows you to run scripts after an archive has been made:

Imagem

This can easily be found when editing your schemas. After that just add this. And the blog post talking about it. I have tried the first  suggestion, but the 2nd one was the most complete. Besides allowing you to select some stuff (distribution lists, Provisioning profile, etc) it also shows you what’s going on the console. So have fun!

Tagged , , , , , , , ,

Solarized Theme

Was actually looking for a new theme for my Terminal, when I found this. In the end I just putted on Xcode, and I might add it looks really nice.

Imagem

Tagged , , ,

Breakpoints fun in Xcode

Xcode although every 15 minutes will crash, gives you some nice features related to breakpoints. One of those things is the ability to based on a given condition do something. Imagine that when a  var inside your code is equal to 50, you want to output the result:

  1. Start by adding a breakpoint where you want.
  2. Right click on it -> Edit Breakpoint.
  3. Something like this will show up:

Screen Shot 2013-04-26 at 08.53.09

So, after this, add the following condition:

x == 50

And the respective action that you want to be produce if that given condition happens, in this case we will just output in the console:

p x

(“p x” means print x. While for objects you would say “po x”, being “po” “print object”)

In the end you will have this:

Screen Shot 2013-04-26 at 09.01.00

And the corresponding output:

Screen Shot 2013-04-26 at 09.01.51

You can also add different actions ( the “p x” is just a simple example):

Screen Shot 2013-04-26 at 09.02.46

Finally, you can add multiple actions to be done at the same time and continue evaluation after the breakpoint is reached. The last one, is uber important, if you don’t want to break the natural flow of your manual debugging, but you want to avoid polluting your code with conditional if’s to Log things.

Tagged , , , ,

Please, don’t crash again.. :(

code_crash

Code crashing, a common problem with normally very good reasons, and, sometimes, very poor ones.

Recently I had a problem where a crash occurred only when an application previously installed and used, would crash once a new update from the App Store would come. It was Google Analytics actually that gave me the bad news. It was something in this order:

NSInvalidArgumentException Trace: 0x0006d6bd MyApp 0x0006f2bd MyApp start_wqthread

What the hell is this, I wonder… In the meantime, someone was able to provide me his device’s crash logs. After trying to re-symbolicate them, nothing came out of them (well, at least the way I wanted…):

Last Exception Backtrace:
0 CoreFoundation 0x3241329e __exceptionPreprocess + 158
1 libobjc.A.dylib 0x3a13b97a objc_exception_throw + 26
2 CoreFoundation 0x3235d8d4 -[__NSArrayM insertObject:atIndex:] + 764
3 MyApp 0x0009985a 0x92000 + 30810
4 MyApp 0x0009b4f0 0x92000 + 38128
5 libdispatch.dylib 0x3a55311a _dispatch_call_block_and_release + 6
6 libdispatch.dylib 0x3a55795c _dispatch_root_queue_drain + 248
7 libdispatch.dylib 0x3a557abc _dispatch_worker_thread2 + 80
8 libsystem_c.dylib 0x3a587a0c _pthread_wqthread + 356
9 libsystem_c.dylib 0x3a5878a0 start_wqthread + 4

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0:
0 libsystem_kernel.dylib 0x3a628eb4 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x3a629048 mach_msg + 36
2 CoreFoundation 0x323e8040 __CFRunLoopServiceMachPort + 124
3 CoreFoundation 0x323e6d5a __CFRunLoopRun + 810
4 CoreFoundation 0x32359eb8 CFRunLoopRunSpecific + 352
5 CoreFoundation 0x32359d44 CFRunLoopRunInMode + 100
6 GraphicsServices 0x35f322e6 GSEventRunModal + 70
7 UIKit 0x3426f2fc UIApplicationMain + 1116
8 MyApp 0x000935fe 0x92000 + 5630
9 libdyld.dylib 0x3a572b1c start + 0

Ok, not too bad now. Still, I was not able to see exactly the issue… I now that the crash is here:

2 CoreFoundation 0x3235d8d4 -[__NSArrayM insertObject:atIndex:] + 764

But, where exactly?? In a code where you have more than 50 addObject: (addObject: is converted to a insertObject:atIndex: under the hood) it’s a bit difficult to actually know where the problem resides, and in what conditions it arises. After a loot of searching:

I gave up. I just wasn’t able to re-symbolicate the damn logs. I found out that the fact of having spaces and special characters on the App name, could produce strange conditions for re-symbolicating. With that knowledge and the hope that I could reproduce the same behavior by using TestFlight, I was able to track more or less the problem (with more than 20 builds, in which build I would comment and uncomment code) I found the issue!

So what it was??? Well, something like this:

NSMutableDictionary *cache = [NSKeyedUnarchiver unarchiveObjectWithFile:cachePath];

Somehow it seems that my local cache get’s corrupted after a legitime update from the AppStore (or other place). To fix this, I used a @try @catch. Again, the problem persisted, and by that time I realized that I had two bugs, because the app started crashing somewhere else… As you might imagine, I was really pissed by now, so I asked for the help of professionals and although they have one of the best costumer support I ever seen (replying to emails at 11pm in a Saturday…) I wasn’t completely able to find the issue. Sure I could track in more detail my fake crashes (that I was provoking on purposes to test the tool), but, unfortunately, not the real problem…

So what now?? I changed the name of my app to something simple (3 letters) uploaded to TestFlight and the goddamnit Xcode was able to symbolicate it. The issue? Don’t add a nil object to an array

Tagged , , , , , , , , , , ,