Tag: Xcode

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
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
Categories
Computing iphone

UITableView cell recycling: knowing what’s visible

On my iOS app project, I need to know what is visible in a UITableView and what's not. Each cell displays a unique countdown timer which updates the label in the cell. UITableView recommends you let it recycle the cells used to display the table. What I could not figure out is what cell is being recycled out of the table. Still, the documentation for the recycling method dequeueReusableCellWithIdentifier is confusing (to me). 

The method's signature

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];

actually returns you the cell that is being replaced.

Better yet, you can use the cell's properties to find out which cell it was. Not a major revelation but maybe it will help someone out there. You can play with my test project and see for yourself.

Share
Share