Ambientweet 1.0.1 is out!

This version has a whole raft of improvements, including:

• Reduced the frequency of refreshes, to avoid running over the Twitter call limit.
• Post windows now use the same style as the main tweet window.
• The length of posts is now calculated intelligently to account for link shortening. So if you paste in a long link, it won’t use up all of your character count, as the link will be shortened in the actual post.
• Auto-completion list for @users in post window now includes all users that the app has encountered.
• Now correctly restores cached tweets and users when loading.
• Added subtle gradient to window backgrounds.
• Fixed beta Sparkle feed URL (the app was looking at the non-beta feed instead).
• Updated the manual with screenshots of new posting UI.
• Fixed window resizing.
• Improved sorting, refreshing with new items.
• Changed user guide code to be sandbox-friendly (copies guide into the Caches folder and opens it from there).

There are lots more improvements and new features on the way in a future version, please give 1.0.1 a try!

During a recent submission I came across a problem.

I got an automatically generated email back from Apple with this sort of thing in it:

Invalid Signature - the nested app bundle ECFoundation 
(Ambientweet.app/Contents/Frameworks/ECFoundation.framework)
is not signed, the signature is invalid, or it is not signed with an Apple submission certificate. 
Refer to the Code Signing and Application Sandboxing Guide for more information.

It’s a bit annoying that the email is capable of spotting that I have one of three possible problems, but not narrowing the actual cause down for me. It’s also a bit annoying that this only runs when you’ve submitted, and not when you verify an application with Xcode.

Be that as it may…

A while ago I blogged about how I’d really like Objective-C to have built in support for lazy properties.

My ideal solution would be something like this:

@property (nonatomic, retain, lazy) NSString* name;

The synthesized getter for this property would automatically call a method

 - (NSString*)nameInit 

when the property was first accessed, and would use the resultant value to initialise the property.

This has some advantages over any hand-rolled solution:

• it can remain efficient
• it can support the retain/copy semantics and atomicity of the property
• it avoids the need for boiler-plate code for every property to test if it needs to be initialised

In the absence of this solution in the language, I offered a rather complicated set of macros to attempt to implement something similar.

Since then I’ve thought about it a bit more, and come up with another couple of ways of tackling the same task…

In my previous post I presented a way to implement lazy properties.

It was a bit macro-heavy though, and looked kind of messy. I wondered if there was another way. Objective C is marvellously dynamic and introspective. Shouldn’t we be able to do something clever at runtime to achieve what we want?

In a word, the answer is yes, we can…

In my previous post I showed a relatively clean way to implement lazy properties generically using the dynamic runtime.

So how does this dynamic implementation actually work?