ActionScript & Android

The stream of tweets this week revealed that Flash Player 11 is out… awesome! Maybe they implemented some really cool new features that I would like to play with…. hmmm…. the list looks small… bummer!

In all seriousness, I think the new 3D stuff is awesome, it’s going to be really amazing. If we can somehow utilise it for user interfaces then we’re off to a winner! That’s one of the major issues that I had and still have is that when it comes to rendering it just doesn’t cut the mustard. Hopefully this will change and it will give one less thing for me to bitch about. It’s sort of a love hate relation ship I have with the ecosystem that is Flash. One things for certain, I’m really thinking of leaving it and moving on to Java/Scala and even dare I say it Javascript (probably using haXe if anything)! Why I hear you cry, here be a list:

• ECMA 4 – I’m guessing Adobe are still in the spoils of the ECMA fallout, where Adobe aren’t 100% sure what to do. If that’s not the case, this is what is perceived from the dwindling hordes of developers. Is Adobe following ECMA Harmony or are they doing their own thing? The latest FP11 doesn’t look like it’s done any sort of move in any direction. The great rival that has appeared in the last couple of years (Javascript) seems to moving lightening fast, ok maybe they’re not all singing from the same hymn sheet, but at least they’re moving when it’s concerning the language (probably excluding MS here somewhat). Things that look appealing to me from a Javascript point of view or even original ECMA 4 document, which I believe should be in FP11. Even if there is no official ECMA 4 now, at least have the balls to follow it through!
  
  • Union types and the set of predefined union types
  • Type definitions
  • Subtypes
  • “like”
  • yield
  • let
  • Iterators
  • Map
• Enums – Why can ActionScript 3 not get enums, they’re basic simplicity that help reduce boiler plate.
• Abstract Classes – With all the functionality that ActionScript 3 is getting, it becomes a necessity to have more help from a language and I consider Abstract Classes part of that. Why can’t the compiler tell me I should override a class if I mark something as Abstract, hell it moans about something when I don’t override something which I should, it’s not like a massive leap?
• Private constructors – Why did we remove these again?
• Generics – Generics in ActionScript 3 is just decent, not good and not excellent, it’s just decent. It’s like they went, “we want to implement generics, but we don’t have the time. I know, lets implement it in a half arsed way!”
• Const – How about const keyword, is it implemented? Who knows? It’s not implemented in the Flash IDE, but is implemented the Flex SDK compiler, but you can create a swc file from the Flex SDK and use it in the Flash IDE? How have they managed to do this without changing the player or the Flash IDE? Well it turns out they only do a compile time (better than not I suppose!) and once the check is done, they use the var AVM2 Bytecode instead.
• Flex compiler – Why oh why is the Flex compiler aka mxmlc and compc two separate entities and why oh why do they not implement some really basic rules of optimisations.
  
  • Inlining
  • Constant propagation
  • Tail recursive optimistations

I really do hope this stuff is coming, because I think it really is make or break time. People that didn’t want to invest that much into Actionscript 3 are now moving or have moved on to other languages (Javascript). The people that are still riding it out for better language expressiveness to get down in code what’s on the tip of their fingers are thinking about it or have already done so!

Edit:
I was speaking with various colleagues about this thread and we all tended to agree, that most of this is syntax sugar. We use this language day in day out, I’ve invested a lot of time into this language and it would be helpful if this language could help us out as well.

You may as an observer say well this looks like language A or like B, I would love to work in A or B, but I’m on a project that requires AS3 and we don’t have to option to move to A or B. In the future though I think A or B is on the horizon, especially in these fast moving times.

As you might have known (previous post), I’ve been tasked to go and learn Android. I’ve mentioned in the last post that I’m not a huge fan of the xml layout capabilities, but there isn’t much I can do with that, you’ve got what’ve got.

Android ListView

So I ran into another problem with ListViews this week, I couldn’t for the life of me get a customised list to run fast. The list in question is like a regular contact list, headers for each letter of the alphabet (where required) and contact rows for the users. Each contact row has a background image, different contact images and various text tweaks.

I didn’t realise at the time, but the getView method which you override to supply the new customised rows has an argument that you should not overlook (I did!). The key to performance lies in the second argument, this passes you a view from the list which isn’t displayed in the screen any more. The ListView is rather clever here and rather than creating new items for every single item in the list, it ask’s you the question “can you reuse this view?”. It’s now up to you to decide if you can reuse the view or not?

The simple answer: You should always reuse the view even if the views are different. In my case the headers are different from the contact rows, because you don’t know the order of the what the ListView is going to pass back the views. Without going down the path of forward look ups (expensive?). In my case I could sometimes get a header and what I really wanted was a contact row, so I would throw that view away. That row would then be left for the GC and I would have to create a new one. Memory allocation on any device is very expensive, be careful how you do it and where you do it!

I worked out for one contact user row we can reuse a lot of the views the more contact rows there is, which normally goes against the grain. The more rows there are the more optimised the code becomes. Unfortunately if you have not enough contacts in the ListView you end up running the worst case, not enough contacts and you run slow and just to many contacts to run slow as well. This isn’t good enough!

Object pooling

At first I thought about creating a pool of rows for both header and contacts. So the creation of the rows are up front, reusing the rows depending on the content required. Except this won’t work because the ListView already manages this and you’ll end up getting into a mess, where you’re doing some pooling and the ListView is doing it’s own pooling. Avoid this at all costs, the next solution is a lot simpler.

Abstract your views

So I was discussing this with a friend of mine and he said I was doing this the wrong way (cheers!). What I should be doing is finding similarities of my layouts and abstracting them into a view. Adding backgrounds and just setting the visibilities to “gone”. Effectively hiding them, when needing them setting them back to “visible” in code. This way, when ever getView passes back a view I can use it! It’s better to add images to a ImageView by code than create a new row.

Inflation of code is expensive, creation of lots of new layouts, views are expensive. It’s far better to create one item than many, it may seem obvious saying it now, but behind all the method calls and other logic it’s hard to see the trees from the wood.

Reuse your views!