I wrote a guest blog on HTML5′s Drag & Drop for Sitepoint.com. It’s a very simple example that builds a little Scrum Planning Board using a bit of CSS and the new Drag & Drop API. You can view the sample code up on github.

So a pretty big thread has busted open on the Apple Developer Forums on “Why use instance variables if you have properties?”

I thought the answer to this was pretty simple: if you rely on synthesized private instance variables, you can’t see their values when debugging! So as far as I understand, if you do synthesize properties, you had better have instance variables if you ever want to see them in the debugger.

The length and flamey-ness of the thread leads me to believe this isn’t a big enough deal. Am I missing something?

UPDATE!
As pointed out by Jeff LaMarche and Julio Barros, there is an easier way to deal with Booleans in Core Data, and it is using Wolf Rentzsch‘s http://rentzsch.github.com/mogenerator/

Original Post:
There are a couple of things that I had trouble with while using a boolean with Core Data. The first was how to update this attribute, and the second was how to properly test against it.

I have an attribute in one of my Core Data entities that is of type Bool in my .xcdatamodel called isDone.

When I first tried to update the value to YES, I tried to do this:

This, quite rightly, gives the warning: “makes pointer from integer without a cast.” That is because Core Data does not support a boolean type. It will create your bool attribute with a type of NSNumber, which I could see when I looked at the header file for my item:

So the correct thing to do was save the NSNumber value of NO or YES (0 or 1) by using numberWithBool:

The second wrinkle was when I tried to test the value of this attribute. I first wrote:

The problem? This was always returning true! Because it was testing, basically, whether or not the NSNumber stored in the isDone property was nil or not. Even if its value was 0, if (item.isDone) evaluated to true.

What I did instead? Test against the boolValue

Hurray! And now I can get on with it!

In the course of creating slides for my upcoming Animation in iOS talk, I’ve been re-running through relevant WWDC talks (and docs, and sample code, and Nathan Eror’s awesome CA360 project, anything I can get my hands on about CoreAnimation).

I came across a handy illustrative example of how to fade a layer in using an explicit CoreAnimation animation from the “Building Animation Driven Interfaces” talk. In practice, you wouldn’t really do this–it’s much easier to just use UIKit animations. But, it helps as a teaching exercise, so I wanted to include it in the sample code I plan to release for my talk.

This animation ran fine, with one wrinkle. CoreAnimation’s explicit animations do not change the underlying model object. They animate any changes in the presentation layer, but the underlying model is unchanged. Which means, when you are done with the animation, the model’s value is still the same. For the above code, that meant the nice fade-in of a UIImageView I just created disappeared (POOF!) as soon as the animation was done; the UIImageView’s layer still had an opacity of 0.0.
Read more »

I was seeing a very strange description for an NSMutableArray object in XCode.  Instead of viewing the array’s count, as I expected, I was seeing some garbled message that said {(int)[$VAR count]} objects:

A quick google search pointed me to a conversation about this on stackoverflow. The key point in that link is this, made by Quinn Taylor:

it’s possible that the object has been reclaimed (either by -dealloc or GC) so check to make sure it’s retained if needed.

AH-HA!!  I am screwing up my memory management again!

For some context, I went back to the Objective-C bootcamp chapter of the iPhone Developer’s Cookbook, and sure enough, Erica Sadun talks about this on page 112:

Retaining objects set to autorelease allows them to persist beyond a single method.

The problem? My array was created by calling [NSMutableArray array], which returns an autoreleased NSMutableArray object.  Thus, it was disappearing once I left the method where I created it.

Changing my code from:

To:

solved my problem.  Huzzah!

The Erica/Alexis project is going quite well, despite my lack of new posts about it. I have a number of drafts in the queue, but for now, I give you visual evidence of the progress I’ve been making. Yes, I really love mini post-it notes:

I’m on page 58 of the second edition of Erica Sadun’s “iPhone Developer’s Cookbook,” and here are the most important lessons I’ve learned so far:

1. Zombies!
2. What’s inside that XIB?
3. The Clear Log Button

Zombies!
Did you know that, by default, your XCode project is NOT enabled to catch Zombies?  And by zombies, I mean objects that you have released, but then subsequently try to access?  THEY ARE ZOMBIES! They are the dead that still roam.  This is good for horror films, but very bad for your code.  But, by default, XCode’s debugger has no way to catch these nasties.

If you try and access a destroyed or released object, you’ll get back a cryptic objc_msgSend.  But!  If you ENABLE THE ZOMBIES as Sadun suggests, you’ll get back a much better message. In my case, I’m trying to access an array (via this call: CFShow([array self])) that I’ve already released. This gives me the following message in my gdb console:

2010-03-30 21:39:28.180 HelloWorld2[2398:207] *** -[CFArray self]: message sent to deallocated instance 0x1810260

Getting inside those .xib files
Read more »

I recently picked up the Second Edition of Erica Sadun’s “The iPhone Developer’s Cookbook,” that focuses on the iPhone 3.0 SDK.

Now, admittedly, a third edition is now required given that the iPad comes along with SDK 3.2. However, I still feel that completing all 163 recipes outlined in Sadun’s book will bring me from iPhone development amateur to iPhone development expert–and give me a leg up in understanding the next version of the SDK.

So, my goal is to get through all 163 recipes over the remaining 347 days left this year.

Thanks to Julie & Julia for the inspiration on this one.

Here are the notes I took from my first NYC Drupal Meetup.  I highly recommend the group.  I learned an enormous amount, I got to see the legendary Earl Miles, and the space where it’s held is nothing short of breathtaking (think Hudson River views + floor to ceiling windows).    

Drupal NYC Meetup 5/13/09   

 Speakers:

• Ezra Gildesgame
• Earl Miles (merlinofchaos)
• George Weiner, CTO of dosomething.org

 Nodequeue The nodequeue module can:

• Keep track of how to notify users
• Be used for granular permissions:
  • Ex: separate editors for designers, developers, admins
• Works very well with Nodes and Panels
• You can create Views specific to one queue
• Recently added international support
• You can have a MAX SIZE to the nodequeue
  • Once you’ve exceeded the max, the oldest story will be kicked out.
  • That’s why nodequeue works so well for lead stories
• USE CASE: Read more »

There are three main resources I’ve been using to teach myself Objective-C, Cocoa Touch and iPhone programming:

• The iPhone Developer’s Cookbook by Erica Sadun
• The lecture videos from Stanford’s class on iPhone development
• The podcasts available on OS 3.0 from ADC (Apple Developer Connection; only available to registered iPhone developers)

The cookbook is excellent as a reference, and as a human-readable, easy-analogy alternative to the lecture slides.
The class itself holds your hand with their assignments, and I have been slowly builing up my Obj-C development skills through their carefully thought-out assignments.

Finally, the ADC videos provide an excellent window into what iPhone OS 3.0 can do, and code samples to help you start actually doing it.

Now, you may be asking, “that’s all fine and good, but where do the LOLCATS come in?”

SO, you only need look at someone and you can quickly make an assessment if they’re an apple or a PC person.  Apple’s TV marketing depends on it.  But I would like to argue that you need only look at their EDUCATIONAL SLIDE MATERIAL to make the same assessment.

Sure, this isn’t from WWDC, but this is on iTunes to help people understand how to use iPhone OS 3.0.  If I wasn’t a Mac convert before, this truly would have made me a believer:

Brilliant.  Bloody fucking brilliant.