Not to dive immediately to an engineering solution,... but this same engineering team attempted to implement and run a Java-based call control software on an IP phone a few years ago. The benefits we were attempting to achieve were abstraction of a lot of manual development for such things as memory garbage collection, so that our engineering team would not have to build these functions from scratch. A phone must have crisp performance/response. Base Java overhead adversely affected user interface performance. Button push to user feedback response was not only poor, it was un-predictable. We abandoned the Java project and moved to a C/C++ implementation on the phone. We also considered implementing flash to allow a jazzier UI for end users (SB people who use the phone daily). The benefit would have been a more pleasing UE for the end user and a more extensible development environment for UI-based funcitons. Again, poor UI response drove us to Build our own C/C++ media rendering engine for graphics, audio and other UIs on the phone.
Likely our first attempt at smartphone service delivery will be usingthe native browser on the device or perhaps a downloadable app that does not require/use flash. We're pretty gun-shy about adversely affecting UI response and battery performance on a phone...especially when we have little or no control over that phone's operating environment.
Dave
