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?