Thanks for your input, it was very useful to hear some of the issues you encountered whilst developing your framework, I can understand why continuing to develop it or work on documentation didn’t seem the best move.

As we are developing a Flash Lite Application my reasons for developing a framework was to enable us to quickly reuse the code we worked on in other demos or apps we might build, so we will be able to make good use of the framework we develop.

For internal use, we avoid many of the issues you mention as we can easily trim the framework or tailor it to a specific app. However, if we wanted to release this for others to use, I’m sure we would encounter many of the same issues you describe. Perhaps it is best kept as an internal project.

Thanks again for your input – and the great work you’ve done on the framework in the past.

Do I copy Flex’s invalidation model and take the RAM hit? Should I even do invalidation since most mobile apps aren’t that complicated and only use 1 level of composition? Do I support event dispatching, or just call backs?

All these questions I answered multiple ways and eventually decided on using my 3 goals to answer them:
1. work on lowest common denominator device
2. provide common GUI controls & utility classes
3. easy to skin in Flash

This meant no invalidation, no event dispatching (using callbacks instead), and tons of controls. They still use a lot of RAM, but I personally feel there isn’t much more you can squeeze out of them without the API becoming hard to use, or the code hard to read if you have to change things.

Shuriken can still improve massively. It never will, though… at least not by my hands.

Even over 2 years later, there is still no market for Flash applications. I hear more positive things about iPhone dev than I do about Ovi dev. Basically, if you are doing Objective-C, you have generally one platform. If you are doing Flash Lite, you are targetting certain devices. As such, a “component framework” doesn’t really work because some devices, like the Nokia 6680, only have 2 megs of RAM, and Shuriken takes 400k of RAM using all controls… so you’re better off just not even using Shuriken. For other phones, yeah, sure. Most of the work people are doing are screen savers, and simple games, not applications. Since there is no market for it, there is no incentive for me to use Shuriken.

In fact, I ended up using Shuriken on video players for the desktop web instead of mobile development because they were small enough for quick video players vs. using the Flex SDK, and could be compiled in mxmlc vs. the Flash components which had to use that painful SWC solution.

So, that’s why there is no documentation, and not many people building apps that are “built with Shuriken”. I highly doubt documentation would of helped since they were pretty developer centric like you said. Most Flash Lite apps I’ve seen aren’t that sophisticated and thus don’t really need a component framework.

Now if I lived in Japan…….