[Pharo-project] Pharo and new Androids (was: happy new year plus cogdroid news)
golubovsky at gmail.com
Sun Jan 8 14:17:45 EST 2012
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  - how
it was initially implemented in Andreas' classic VM port, and later
the same design was done in Cog .
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.
Anywhere on the Web
More information about the Pharo-dev