Categories
Computing iphone Mac OS X

Why I am uninstalling Xcode 4 gm seed Beta

The person who helps tutor me into iOS happiness recommended that I try Xcode 4's beta. He felt is was ripe and ready to go. I followed his advice, installing Xcode in a separate directory than Xcode 3 (.2.5). Today I am uninstalling Xcode 4's beta. Here's are some of my impressions from my experience:

  1. Git integration: great step forward here. Xcode embraces the Git version control system and detects existing command-line setups. Only thing is that Xcode only allows you to commit to your local repository. There is no push capability.
  2. Adding files – source code or images – is a huge issue. Drag and drop does not work properly and mostly ends up with an error message. More crippling is the fact that if you use the navigation menu to import files into your project, it imports them into a purgatory area that appears above the root project icon in the file listings view. What causes the real issue is the fact that if you then try to move those files back into the project by dragging them, they will be copied into the project. There is no way to delete them from the purgatory state inside Xcode. If you try to compile the project, the compiler will complain about duplicate files (even images) with the same name. If you delete the file from the command line or finder, you are stuck with 'ghostly' listings. The project will compile but the clutter grows.
  3. Xcode 4 sets up a new project structure, different than Xcode 3. It has fewer folders and overall seems a bit more cluttered to my newb eyes. Adding groups is also unintuitive as the only way to name a new group is by creating it first, and then single-clicking its name.
  4. Project properties are a huge step forward. Configuring Xcode to use libraries and set up apps on the iPhone and iPad is now outside of the source plists and in a pleasant user experience.
  5. Xcode 4 integrates Interface Builder into the IDE's window; no longer a separate app. It uninstalled Xcode 3's version of Interface Builder and if you try to open xib files in Xcode 3 it opens Xcode 4's version. That would still be cool had it not for the fact that the new Xcode 4 Interface Builder has issues in detecting properties in the files you create in Xcode 4.  

In summary – Xcode 4 works, mostly. It does crash – but gracefully. Yet I would recommend against installing it for serious development and even more, against installing it side by side with Xcode 3. 

Share
Categories
Computing Web Development

Rails HTTP error 406 in response to JSON requests

Had a painful experience last night trying to get Rails to properly handle a JSON request coming from an Objective-C client. Rails was issuing a semi-exotic HTTP error 406. Error 406 means that the user agent – your browser, my iPhone app – cannot handle the response being sent to it. Apparently it all stems from an HTTP request header, Accept, which tells the server what content it can 'digest'.

In any case, to cure this problem I looked at what Accept header Firefox was sending when Rails was successfully handling its requests. By copying Firefox's Accept header and sending it to with my request, I was able to overcome the 406 error and get a happy 200 response.

The Accept string that worked was:

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

If this does not work, also examine the Rails controller. Make sure that all REST methods return JSON representations.

Share
Categories
General

SBJSON: Testing for nil / NULL value

I am playing with a variety of JSON frameworks in Objective-C. All are severely under-documented but then, they are simple to use, right? No. Nonetheless, I am deeply in awe and in debt to the great individuals who invested endless hours of their time to build these libraries and give them to us to use free of charge. Thanks you.

Anyway, SBJSON from Stig Brautaset, which I am examining right now, exposed a relatively weird issue. How do you test for null values in the contents of the parsed NSDictionary at hand? 

Plain old ([dictionary valueForKey:@"key"] == null) will not work. The breakthrough came when looking at the dictionary printout to gdb (Right-click the object in memory and select 'Print Description to Console'). The null value was 'stored' in a CFNull reference. To test whether a pointer is pointing at CFNull, you do this:

myVariable == kCFNull where kCFNull is a special memory address dedicated to hold this special null (nil!) value. 

Share
Share