Hi, Guido Stepken wrote:
Google has unified development for handy and tablet 4.0. They have introduced scalable, animated tiles, reacting on events, coming from analysing contents of about 100 different protocols streaming through the machine. Google even collects barometer and temperature information global, for own weather forecast, and A-GPS information for traffic jam maps.
Well, every application on Android is event-driven (rather than polls for events itself). This of course applies to CogDroid. See [1] - how it was initially implemented in Andreas' classic VM port, and later the same design was done in Cog [2]. For scalable animated tiles I believe you mean the widget views which have been improved in Android 4. But having an application look as a widget is just a way to configure its main view. Currently the CogDroid main view is fullscreen. So, for events, I think more can be done in the way Android events are mapped to Smalltalk events. Currently only touch and keyboard events are processed, and they are treated by the image as regular Linux (polled) input events - just for the sake of the "Regular" GUI to work. Nothing prevents development of a different event handler behaving in desired way. Maybe some reflection must be done on incoming messages, and then recipients of those messages inside an image could be resolved symbolically. Do you have an example of an Android scalable tile application with sources? I might look which events it takes, and how can I map them into Smalltalk messages internally. For widget vs. fullscreen view: the code of VM itself has been separated into a Java class library, so it may be possible to write overriding classes for activity and view so it show up as a tile. Only nobody has tried this yet. Maybe I need to make some of widget functionality part of the library.
This new tile approach is even intended to be introduced onto desktops, so i fear, former designs with pulldown menus will look old fashioned in about one year for customers, included Windows 7, Mac OS X. This new tile design even can be found already in Samsung TV's.
Yes, and I am belong to the number of people who want this. The Android-x86 project makes steps towards better adoption of Android on the Intel architecture (desktops and laptops). Unfortunately, the state of things is: Gingerbread works more or less (I use it for my Cogdroid testing) - but it is not very convenient for desktop use - at the userland level of course, Honeycomb works so-so (I was able to PXE-load it onto a PC, and browse Internet, but asynchronous downloads always get stuck and never complete, so I could not even install CogDroid on it). ICS is from barely working to not working at all - never worked for me. But eventually I think (open sourced part of) Android will make a good single-user client-oriented Linux distro (Ubuntu and likes are server distros, and there seems to be no other Linux distro aimed at an average smartphone user level than Android).
Like Jobs banned flash on iphone for power consumption disadvantages, Google has dropped the "monolithic" design approach and invented a "multi-vm-vm", where multiple bytecodes are executed in parallel, but time slices are controlled by the underlying linux scheduler. This approach leads to very good uptimes of your handy or tablet. 1/2 Watt incl. Display at normal operation.
Well, if you mean that most of the userland is event-driven, it is true, and as I wrote earlier, the only reason I need to keep sending periodic timer events to CogDroid is to make its regular Pharo desktop work as usual: blinking text cursors, scrollers when scroll buttons are held still, network operations which run long without any user input. If you need an application which only reacts to external events, and not doing anything in between (like most of mobile apps should behave), just put the background timer delay to maximum value, and Cog code will not run without external events at all. I'll try to make this configurable.
So, any "monolitic" vm will consume too much power. Pharo Smalltalk completely had to be redesigned to work on multi-vm-vm, where parts of smalltalk code can be time scheduled by the underlying kernel. Apart from the fact, that about a hundred new protocols had to be implemented in pharo, i see NO chance in integrating pharo in the new operating system designs.
I think we already have this covered in part - see my notes on disabling the background timer, and reflection on external messages to resolve them into Smalltalk classes to handle them.
This is state of development on vm's . And yes, jitter included.
Thanks for your suggestions - very interesting direction of development. --------------------- [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2009-November/003385.html [2] http://lists.gforge.inria.fr/pipermail/pharo-project/2011-August/052848.html -- Dimitry Golubovsky Anywhere on the Web