Blue Flex

Developing for Apple’s devices can throw up a few little quirks that don’t happen when using Android devices.

This one happens if you are using shared objects to store information between sessions.
Basically, you should always call the flush mechanism whether you are adding more data to the shared object or if you are deleting something from the shared object.

What you find is if you have a shared object ‘shared’ with a value shared.data.firstValue = “something”, then you delete that value using

delete shared.data.firstValue;

if you try to access the value firstValue you will get null.
This is exactly what I’d expect.

Then lets say you exit the app and you either kill the app from running in the background or iOS stops it. Then the next time you load the app and access the shared object shared.data.firstValue you will get back “something” and not null.

You must flush the shared object for it to be stored locally, otherwise when the app is killed, the local storage will not have been updated.

Working on a mobile project I needed to create a renderer for a list, so I choose to look at the IconItemRenderer which extends the LabelItemRenderer. These have been optimised for mobile use so it seemed a reasonable place to start. On the whole they seem like good classes to use, but if you’ve ever worked with the Datagrid/DataGridBase in the past you will probably know about the white square which comes about from the hardcoded #FFFFFF values inside the DataGridBase!

Well the IconItemRenderer and LabelItemRenderer have a similar issue. So lets just say you create a list and you wish to skin the list exactly how you like or use it in a tile layout or something other than vertical then you will find some lines above and below your renderers which look out of place. You can’t get rid of them no matter what property styles you set.

The fix is pretty straight forward but why does there have to be some hardcoded values in something that is meant to be very versatile?

So inside the LabelItemRenderer around lines 881 you will see the following. It uses these values to draw separators whether you like it or not.

// separators are a highlight on the top and shadow on the bottom
topSeparatorColor = 0xFFFFFF;
topSeparatorAlpha = .3;
bottomSeparatorColor = 0x000000;
bottomSeparatorAlpha = .3;

So the quickest way of dealing with this is to override the drawBackground function in your own class which is created in LabelItemRenderer. This doesn’t get called from IconItemRenderer so you can quite simple copy the entire function and just remove the separator chunk and do not call super from your function which overrides the drawBackground.

Better still would be to change the hard coded values to styles from a CSS file.

var topSeparatorColor : uint = getStyle( 'topSeparatorColor' );
var topSeparatorAlpha : Number = getStyle( 'topSeparatorAlpha' );
topSeparatorAlpha = isNaN( topSeparatorAlpha ) ? 1 : topSeparatorAlpha;

If you’re setting a Number just remember to check for NaN’s in case you haven’t set a style, uints default to 0 anyway.

Well this is slightly old news, and a lot of you may well know that the New York Times has released a very good AIR application for reading the news.  You may even recognize it from the demo that was given at Max 2008 (for the International Herald Tribune).

http://www.insideria.com/2009/05/new-york-times-air-reader-rele.html

Well what I didn’t know until today was at the same time the NYT have released a Silverlight kit so that developers can build an app using Silverlight and pull in various articles from the NYT.

http://www.infoq.com/news/2009/05/Times-Silverlight

This just seems like very bad timing and another kick in the teeth for Silverlight (don’t get me wrong I’d like to have as many RIA languages out there to give me a choice depending on the project requirements). So around the same week they release a kit for Silverlight they drop their Silverlight reader in favour of a AIR reader due to issues with Silverlight.

http://firstlook.blogs.nytimes.com/category/times-reader/

I think we still need to wait a while for Silverlight to mature a bit (which I’m sure it will) before using it fully.  

It would be interesting to find out how many of the major early adaptors of Silverlight are still using it. Every now and then you hear of a major Silverlight project being dropped in favour of flash/AIR.  Am I just not reading the MS blogs which have the opposite (i.e. flash/AIR projects being dropped for Silverlight)?