I’ll be doing the bulk of my blogging on that site from now on but I’m still unsure whether to maintain a separate blog for more technical geeky stuff on this domain. This site will certainly stay live for a little while but it’s possible I will look at setting up a Tumblr blog in the future. I’m already using a Posterous blog for leeprobert.com and this is great and has a nice iPhone app.

WordPress running on my Media Temple server started to become a real headache with attacks and spam. It does look like they’re getting on top of this but as I seem to move more and more of my life in the cloud it made sense to do the same with the sites.

Also, as my work moves further away from coding and more towards user experience and digital strategy it seems that anything I have to say will most likely be appropriate fare for my main site.

So, for the time being … goodbye blog dot lyraspace.

I’m not too concerned about the rounded corners but the lack of precision is an issue if you intend to create dynamic skins and want some control over the positions and dimensions of your composition.

Take a look to see my results :

Uploaded with plasq‘s Skitch!

Uploaded with plasq‘s Skitch!

Uploaded with plasq‘s Skitch!

You may need to jump to Skitch for that last one but basically if you have four squares in a HGroup with a 4 pixel gap and the square is defined as 30 pixels in width then you would expect an overall width of 132 pixels. You will actually get 140. This could be a big problem. 8 pixels is a big discrepancy.

Uploaded with plasq‘s Skitch!

Uploaded with plasq‘s Skitch!

Uploaded with plasq‘s Skitch!

Uploaded with plasq‘s Skitch!

I drew this up recently to illustrate a proposed workflow for a project I’m working on. This is similar to the workflow as proposed by Adobe but with an extra level of responsibility on the Interaction Designer. This being the requirement to adapt their Catalyst work in Flash Builder. This, in my opinion, is a more realistic overview of how most Flex framework projects actually play out nowadays.

Flash Catalyst is not quite powerful enough at the moment to produce flexible, bespoke skins. The chances are you’ll need to build components that aren’t just button skins. You need to write your own SkinnableComponent classes with custom skin parts that resize dynamically etc etc.

I’m afraid, if you want to be a shit-hot Interaction Designer and need to build amazing, re-usable prototypes that can quickly be integrated into the final architecture then you’re going to need to think outside of the Catalyst and get your hands dirty with Spark and the skinning component life-cycle.

Good luck!

There’s a PDF of the images on this post here.

Ok, so this is nothing new but I thought I’d log a couple of things that caught me out as a NOOB to the whole iPhone development malarky.

First off archiving your objects is a way of saving them to a property list file that sits on your device and can be unarchived the next time your app loads as a way to persist data locally on the device. Very handy it is too. Now there are better ways to manage data in Obj-C … CoreData for a start. This is a much more powerful way to persist data to a SQL lite database and allows you loads more freedom in what you can actually archive. There are limitations to the property list method you see. You can only archive NS objects and simple scalars so your class structure needs to compensate for this. The ‘plist’ objects you can archive are … NSArray, NSDictionary, NSString, NSNumber, NSDate and NSData along with their mutable subclasses. The scalars are int, float, double etc.

I don’t want to write a massive chapter on this and there’s loads of information online about the technical ins and outs of what’s happening behind the scenes. What I do want to do is share the classes I’ve used in a recent project and explain in basics what’s happening.

Firstly we’ll create the object we want to be archived. Any object that needs to be archived and is a subclass of NSObject must adopt the NSCoding protocol. Take a look at this object …

DataModel Object for archiving

This object also references another object called FaveVO this is an object that I’m feeding into an array and also adopts the NSCoding protocol so you can see that you can archive quite a complicated object overall.

The important stuff is after the line that says “#pragma mark NSCoding”. These methods (using Actionscript terminology but I don’t care) handle what happens when the encoder and decoder go to work on your object.

- (void)encodeWithCoder:(NSCoder *)encoder
{
 [encoder encodeObject:favesArray forKey:kfavesArray];
 [encoder encodeObject:currentFave forKey:kCurrentFave];
 [encoder encodeInt:faveIndex forKey:kCurrentFaveIndex];
}

The encodeObject message takes each of my class variables and copies them into an NSData object using the keys which I defined in the interface. These are unique identifiers that I can use when I want to decode them later like so :

- (id)initWithCoder:(NSCoder *)decoder
{
 if (self = [super init])
 {
  self.favesArray = [decoder decodeObjectForKey:kfavesArray];
  self.faveIndex = [decoder decodeIntForKey:kCurrentFaveIndex];
  self.currentFave = [favesArray objectAtIndex:faveIndex];
 }
return self;
}

And that’s all you need to know about the Object you want to archive. Next comes the class that I’m using to do the archiving and unarchiving.

Here’s the class :

Archiving and Unarchiving DataModel Object

The initDataModel method looks for the property list and then uses the NSKeyedUnarchiver object to decode the objects. When the application terminates the objects are encoded using the NSKeyedArchiver object. The class listens for the ApplicationWillTerminate notification using the NSNotificationCenter object. This is similar to the Actionscript event model that uses listeners. The NSEnumerator object is used to step through an array of objects. The decoded FaveVO objects are then sent through to my DataModel class and passed to the createNewFaveVOFromFaveVO method which is where the objects are re-created as shiny new objects. Remember the NSKeyedUnarchiver object is released so you need to retain the objects you need … usually better to create new ones within the correct scope.

The DownloadProgressBar component allows you to view the progress of the runtime shared libraries but be aware that it can only tell you about the RSL as it loads and as there may be more than one it is practically impossible to get any indication of how many bytes in total the app is going to load. For this reason you may have seen erratic preloaders out there at the moment using all kinds of colourful language to tell you what it’s doing … “loading assets”, “modules”, “opening the champagne” etc. This is all done to keep the user occupied while each of the elements are loaded.

Then there’s the actual SWF file. Thankfully there are separate events to handle this so if you prefer you can still display the progress of the main SWF and then when it is completed change your display to inform the user that you are “initialising” which shouldn’t be too long after the main SWF has finished. Indeed your dependencies may have finished before the SWF.

I guess the only way to do this accurately is to know up front exactly how many bytes your application is going to load and then as you get the information from ProgressEvent.bytesLoaded from both the SWF and the RSL you can adjust your percentage calculation accordingly. If anyone does know how you can programmatically detect this I’d love to hear it.

Thanks to Bernhard Hirschmann and Jesse Warden for the work they’ve done and purely for my own reference here’s the class …

Custom Preloader for Flex with RSL support