iFeedme Blog

It was with great interest that I noticed a new release of the zinc 3 flash projector tool, and looking at the features it would appear to do everything I need.

To explain, the products I work on are distributed and sold in 2 ways, DVD and web access. Previously, we’d had 3 separate distributions in effect : a disk based executable for windows, one for mac, and a server based one for the web site. All did (and still do) use the same assets, but nevertheless it’s a big effort to keep all 3 in sync and up to date (This, of course, costs us money).

So, the promise of one common code base (or, at least, much much further towards one), and a pretty well identical and consistent interface on both DVD and web was a big plus for me to sell to the company when I suggested a flex version.

So far it’s gone extremely well (As I’d hoped). I’ve abstracted out the database access (initially, prior to Apollo/AIR I used a socket server built in haxe for the local version, but now it’s remoting using flourine for web and AIR’s native sqlite access for the disk), and apart from that and a couple of file save classes I do have 2 projects that share 95% of their code. Cross platform. Sorted.

Except for one thing, which is that it’s a requirement to have some sort of copy protection on the disks we sell.
AIR , being a runtime, makes that a little less straightforward to implement than a standalone executable, and I’ve yet to decide quite how I’m going to do it.
The system we use at the moment (Sony’s Securom) relies on the executable being encrypted against the DVD, but of course I can’t do that on the AIR runtime…
I have some thoughts involving protecting the “stub” exe that air seems to use, using a web based licensing system (we tried that before, with no great success), or maybe having a socket based “licence server” that runs off the disk itself. To be honest I don’t much like any of them, being the one who has to answer the support calls when all these schemes fail (Copy protection problems are 90% + of our support calls, and I hate it …).

At this point it’s worth reading this interesting article “AIR is not a projector tool”, which makes the points of difference between AIR and projector tools rather better than I can (and uses zinc 3 as an example).

All of which brings me back to Zinc 3, and in particular it’s sqlite access (since that’s the deal breaker for my application).
I will, however, start with the AIR sqlite implementation, which I have to say is extremely good.
Apart from some early hiccups in the first betas (writing blob binary data and a bug with some null results) plus the decision to remove full text search (quite understandable but a disappointment for me) it’s really well thought out and very usable indeed.
Data comes out typed and ready to use in flex, it deals with binary results, hell you can even specify an object to use as a result format or access fields by their name in the sql query. There’s also a nice api for analysing the database schema now rather than the rather clunky sqlite native method (Yes, I’ve used that and had to parse the results ). And it works, in that I can rely on it 100%, based on experience.

Now, compare and contrast with that in zinc 3, the documentation is here. It’s short (Drill down to Database > Objects > Database.SQLite) …

The first thing that I noticed is that there is no code completion for it in flex builder (I believe it uses some sort of run time resolver package instead, not thought that one through as yet though). Fair enough, I can live with that, so I ignored it and built a quick test using a production database and some very simple queries.

Next it seems that you have to make a call then check if there was a database error rather than a try/catch that one can use in AIR.
Fine, I guess that’s an abstraction that helps make the sqlite access compatable with the 3 others (mySql, Access, and ADO) that zinc supports.
However, I don’t particularly like it.

Next, all your results come back as a multi dimensional array. Of strings. Mnnnnn. So that’s quite a few parseInt()s then and whilst I’ve not tried it I suppose blob data is out of the question. Not only that, but you’re forced to use index based access to the results, which is not especially readable.
I did try the getXML() method thinking that it might bring back field names in the xml but I’m afraid that for me it just returns nothing at all. oops.

There doesn’t seem to be any way to use parameters in the query, rather you have to build the whole query as a string.
Now in this app I’m not concerned about sql injection and having to escape input, but I’d rather it was there for the time that I do.

Still, it did seem to work well enough to consider giving it a go for real, so that what I did. The service in question is roughly 2000 lines of actionscript, I guess it took me about 3 hours to port it over, which was tedious but not too bad.

It didn’t actually work first time (Yes, I expected that!) but fortunately it’s fairly easy with zinc to build a debugging projector and use the flex debugger.

Turns out that it doesn’t do what I can do with AIR, which is to just keep open a database connection for the life of the application (I’m relaxed about doing that in AIR, particularly since I can open the database read only, which I can’t in zinc as far as I can tell).
Instead you need to keep opening and closing the connection to the local file, and once I’d worked that out my results stopped having zero length (Hey, why no error raised? That would make more sense. If I’m stupid enough to query a closed connection then I should be told) and I could correct my own errors (unusually for me, I didn’t have all that many).

I’m happy to say that it does all work as expected in zinc now (which is good, this was not a trivial test, the db gets a lot of use), with a couple of important caveats.
Firstly, it’s slow. Noticeably so. Mainly in deference to the web version, I do regularly pull a large amount of data out of the db that gets sent to the client, which cuts down on the latency of making many smaller queries much more often. In c# or AIR, these big operations occur so fast as to be acceptable in actual use (probably in the order of a second at most, even on our minimum spec clients). In zinc, I’d say about 5 or 6 seconds on the fastest, which you do notice.
I’ve yet to profile it, it’s possible there are improvements to be made (though I did optimise the database open/close as much as I could).
However, the app itself is sluggish compared to both flash player and AIR, even when I’m not touching the database (memory usage appears to be fine, mind you).
The worst point is that the projector will crash, and I just cannot publish an application that does that at all regularly (AIR, by comparison, will not do so).
It may only have been a couple of times in a day or so, but that’s too many to get through QA and I’ve not been able to pin it down on any one particular point.

I think I’ll be waiting a while before giving zinc 3 another go.
Whilst this little review may seem harsh, I appreciate that it’s not easy at all to produce rock solid software at version .0 and I’m actually really glad to see zinc still out there and improving. I’m hoping it improves to the point where I feel that I can use, and quite confident that it will.
There are other features that whilst not must have will help us a great deal, so I’d like to be able to use them.
I should say that (perhaps unfairly) I’ve not contacted multdmedia with any of my concerns before writing this, and I’m very happy to stand corrected if anything is inaccurate, misleading or unfair.

This entry was posted on Monday, February 11th, 2008 at 9:07 pm and is filed under AIR. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.