Thought I'd offset my love-related etching from yesterday with a Flex rant...

Using Apple's UI development tools has helped to clarify the benefits of a template-based approach to UI development. Under that mantel I include things like Flex, .NET, Java Struts and Tiles - anything where you use a parameterised components to build a user interface. There are two benefits to a system like this:

1. initial speed of development
2. consistency of look and feel between applications

I say initial speed of development because I have always found that as time goes on, these 'easy, fast' systems tend to result in code that is difficult to maintain as the complexity grows (although you could say that about anything really... I'm really saying that the 'easyness' fosters a certain 'bricklaying' style of programming that is tedious to change due to excessive copy-pasting of details instead of OOP centralisation).

The Apple stuff brought point 2 home - it's very important for an operating system to maintain a look and feel between applications. That's where this sort of thing belongs. The good thing about the Apple implementation is that there are lots of very high quality components and integration hooks that can be used to rapidly build a fancy looking application. Also, since Apple themselves use these tools, their construction is optimised for real world use.

Here's the rub: Consistent look and feel is a no-no for Flash applications. The whole point of using Flash is differentiation of UI concepts, creating branded experiences, creating something unique every time. So Flex is generally more of a hinderance than a help when it comes to building RIAs for the web.

Flex MXML source code looks like bad HTML. As a sometime HTML developer, seeing X and Y coordinates hard coded into my view structure makes my blood itch. Seeing visual implementation details randomly mixed in with structural details scares me. I am deeply concerned that the templating language of Flex has learned nothing from all the progress that has been made cleaning up HTML over the years.

I hate the 'data provider' paradigm. It never works. It was never enough for a .NET app, and it won't be enough for a Flex app. There's always something you need to change that the component API doesn't let you change, so you end up jumping through artificial hoops imposed by the incomplete component implementation.

When you develop parameterised components, you are adding redundant functionality to your code. You try to second-guess future implementations, but you never think of everything. The more flexible a component, the fatter it is. Which is why a Flex application takes so long to download. Watching a progress bar on a website before I can do anything makes me want to leave straight away.

The other facet of this sort of encapsulation is the inevitable event maelstrom. To make a component flexible enough for use in a real world app, it needs to be dispatching events all over the place. And in my experience, the one you need is always missing. It's okay if you have the source code - you can add in an event at the point you need it, but it's never quite right.

Another problem with component encapsulation is that when you have a lot of classes going into your component's implementation, you end up having to override a whole inheritance chain to change a small detail. Um... that is, say you want to change the font on a button inside a combo box - you have to override the combo box to use a different list item class that uses a different button component which creates a differently styled textfield. Unless the developer happens to have implemented that all-important 'kerning' parameter that your designer is insisting you perfect...


So yeah. I don't like Flex because it
1) encourages lazy development practices by purporting to be 'fast' and 'easy'
2) mixes view with model with controller in XML files that can only get bigger
3) creates artificial barriers to the level of customisation necessary for any Flash app with the flawed 'state' model
4) has an ugly default look and feel
5) has components that don't quite do everything you'd expect (try using the keyboard or mouse wheel on some things and you'll see what I mean)
6) results in a lot of tangled up event listeners

I see all of these problems as coming from the parameterised component paradigm, although if the implementation was as good as Apple's then I might be a bit more interested. However, even with Apple's implementation I quickly found myself wanting to return to a code-based UI construction process, cos, you know - why hard code x and y coordinates all over the place when you could have a couple of static constants in your source and work everything else out at runtime?

Tags: programming

Apple Instruments comes bundled with Leopard. It's part of the whole developer toolkit that Apple give you for developing OS X Applications. All their tools are somewhat beautiful (the only real omission as far as I'm concerned is tabs in XCode).

I am doing some Flash work and realised there was a major memory leak and realised that I could use Instruments to track stuff in the Flash Player same as anywhere else.

All you need to do is Launch Executable->/Applications/Flash Player.app, and put the path to your swf in the arguments box in the Select Executable window.



You can monitor and record memory usage, file access, cpu use, beachball-time, and even get screen captures of user interface events on the chart. This is just excellent.

Tags: programming

My Audio Unit development exploits went on deep into the night yesterday. But that's how it goes when you're making progress with software development :)

I have managed to make a Cocoa UI work (although there are some vagaries of the event system that I am yet to get my head around - the examples are very inconsistent) and I've actually created the DSP for a passable 'turntable stop' effect - i.e. a progressive slowing down of the sound until it stops. I antialiased the waveform and everything! It's a bit clicky when the buffer loops and needs some work to abstract the effect code into a more dedicated class, and I need to practice up on my C++ a bit more (can I even make small private methods?! Does it even work that way?? Darn it if you can't!). I'm having lots of fun with it though. Even if I'm basically having to work out how to achieve audio effects by.. well - just thinking about how to do it.. because I still need a book, and I have no internet at home (Blackberry Browser notwithstanding) when I'm working :S

Tags: programming

I have one more week at LBi. Then I will have time for my own projects.

My current project (that I spent all of yesterday with) is to learn how to program AU plugins for OSX. So I'm doing a LOT of learning. This is mainly because I can't use http://illformed.org/blog/glitch (the best plugin ever made ever by anyone) on the Mac. So I have to work out how to make it myself.

I'm not particularly experienced with audio DSP programming but I think I'll work it out. Just a bit of resampling from a stream and then making it last longer or less long. For..next etc... how hard can it be?? :)

Actually I still haven't managed to a get a Cocoa view working. I've run through a tutorial though - got that working. Refined my workflow too (tip: put killall AU\ Lab && open /Developer/Applications/Audio/AU\ Lab.app and make it restart the AU Lab utility with each build, with a project saved so your plugin comes straight back up). I have a vague idea of how I'll achieve the effects I want but the practice of parsing the buffer contents and transforming stuff that relies on temporal information is going to make my head hurt for a bit. But then I'll know how to make my own plugins!!

Tags: programming

Remind me to talk to you about 'bricklaying' code versus proper code some time. People don't appreciate the artistry involved in writing code. I literally get endorphins sometimes when I am making progress - it's fun. Really. And the output is completely objective - if your code doesn't work, it's obvious.

This channels me into talking about inner beauty automatically creating outer beauty. If something is beautifully constructed then it will work better. I believe this principle operates on everything from software to other forms of engineering to music to the attractiveness of a human.

A girl can look nice in the distance but if, when you start talking to her, she is not very bright, the attraction (for me, certainly) fades rapidly. If you do not have consistency or morals or intelligence or humour your face begins to look like a confusion of rubber and I need to go and talk to someone else.

(P.S. I'm loving posting to this blog via the livejournal robot! Finally - pith without having to wait for a browser...)

Tags: programming