AllJoyn
AllJoyn™ is an open source peer-to-peer technology that enables ad hoc, proximity-based, device-to-device communication without the use of an intermediary server.
True peer-to-peer communications without the traditional barriers
- Simple device and service discovery
Broken Links
I’ve been getting madder and madder about the increasing use of dorky web
links; for example,
twitter.com/timbray has become
twitter.com/#!/timbray.
Others have too; see
Breaking the Web with hash-bangs
and
Going Postel. It dawns on me
that a word of explanation might be in order for those who normally don’t
worry about all the bits and pieces lurking inside a Web address.
More Animation Curves than You Can Shake a Stick at
Core Animation is awesome. It makes doing a lot of complex, fancy animations downright easy. One of the really nice built-in features of Core Animation is the ability to use animation curves. These curves let you specify whether the animation happens linearly (at the same pace throughout the animation), or whether the animation eases in, eases out, or does both.
When you have to go closer to the metal and use OpenGL ES, you’re not so lucky. We don’t have animation curves provided for us in OpenGL ES. We have to interpolate ourselves. Fortunately, the math behind animation curves is straightforward. Plus, there are far more curves than just the four Apple offers.
I haven’t run across a good library for generating animation curves, so I’ve decided to release my animation curve functions as public domain (no attribute required, no rights reserved). Here is a graph of all the different animation curves I’m releasing:
Here is the original Numbers.app document that generated the graph, and here is the Xcode project that generated the data. The project also contains all the functions needed to plot these curves.
Apple doesn’t document which calculations they use for easing, but my guess is that they’re quadratic. I’m not sure, though, since many of the curves yield similar results.
All of the interpolation functions included in the Xcode project above take three inputs and return a GLfloat containing the interpolated value. The first parameter, t, is the percent of the way through the animation you want a value calculated for. This is a clamped float that should be in the range 0.0 to 1.0. Values above 1.0 will be treated as 1.0 and values below 0.0 are treated as 0.0. The second parameter, start, is the value when the animation starts. The third parameter, end, is the final value to be animated toward.
If you want to apply a curve to a CGPoint or Vector3D, you have to call the function multiple times for each component (x/y or x/y/z).
Have fun!
Here are the functions included in the project above:
Read more on More Animation Curves than You Can Shake a Stick at…
Just Make It Faster
As a user, how often have you thought “I wish this web service was faster.” As a CEO, how often have you said “just make it faster.” Or, more simply, “why is this damn thing so slow?”
Dealloc
Last week there was a bit of a Twitter in-fight in the iOS community over the “right” way to release your instance variables in dealloc. I think Rob actually started it, to be honest, but I probably shouldn’t be bringing that up.
Basically, several developers were claiming that there’s never a reason to set an instance variable to nil in dealloc, while others were arguing that you should always do so.
To me, there didn’t seem to be a clear and compelling winner between the two approaches. I’ve used both in my career. However, since we’re in the process of trying to decide which approach to use in the next edition of Beginning iPhone Development, I reached out to Apple’s Developer Tools Evangelist, Michael Jurewitz, to see if there was an official or recommended approach to handling instance variables in dealloc.
Other than the fact that you should never, ever use mutators in dealloc (or init, for that matter), Apple does not have an official recommendation on the subject.
However, Michael and Matt Drance of Bookhouse Software and a former Evangelist himself, had discussed this issue extensively last week. They kindly shared their conclusions with me and said it was okay for me to turn it into a blog post. So, here it is. Hopefully, I’ve captured everything correctly.