This page last changed on Sep 06, 2009 by juha.

Moving this discussion with Andrew Oliver to a separate thread, where it belongs.

Well for #1, that will mean accepting some divergence in behavior. It is possible to define some/most of it using the android xml. It isn't possible to replicate the amsterdam demo using only the andorid xml. You'd need more information (like "i intend this to be a background image and not a button). This really becomes "do the interpretation in the GUI designer or in the individual apps". Right now you have a reference platform and anything else should emulate that. You suggest something that is aken to moving towards a compiler with backends for different platforms. I'm not sure one route is better than the other (your current route is more like Java, what you propose is more like a C crossplatform compiler).

I'm ok with diverging behavior on different platforms as long as it's being developed in a controlled way. The last point is important in order to manage new features going into panels without it turning into a chaotic feature matrix.

Using the native XML bindings to me is the same decision as with Swing vs SWT (your interpret vs. cross-compile analogy). Personally I am a fan of the Swing approach but at the same time it is a larger effort and harder to get done right. I like keeping the door open for new creative UI use cases through the externalized platform-specific XML bindings when the online design tools haven't been developed yet. This is largely what the A'dam demo was all about – to discover new needs for both the panel UI bindings and the online designer.

Of course a phone gui will look stupid blown up to my 1900x1600 (or like a darn shame waste of space), but it should look ok on the next generation iphone or android with say an extra 100 pixels on each side (which apple will market as the most revolutionary idea they've had since cut and paste). Layouts and template will help that a lot. I'm not entirely convinced that Android XML is enough... but with some reasonably defined layouts we could probably do a good large chunk of it though. Its possible to dyanmically load panels and things from the XML. I think defining layouts (ala swing layout managers,html,etc) is more important than profiles though (not that both shouldn't be done). With layouts you can at least get the iphone app to render correctly at 1900x1600 (even if it would look stupid).

We will do both. I'm prioritizing profiles more though because they do solve three separate issues – UI designs for completely different screen layouts, UI designs for different user groups and even UI design for slightly adjusted screen dimensions. Granted, they do the last one badly with a sort of a brute-force effort but at least the option is there. Having said that though, I am adding a rudimentary layout elements (<grid>) in the new XML UI schema proposal that I will post later today. The Swing layout manager/HTML document layout is the right model to follow here and hopefully the <grid> element will solve at least some immediate layout adjustment issues. I noticed Android natively does a couple of others as well which I don't mind adding if there's interest.

For android I also wonder if the GUI designer could deliver apk files with the images in them. It is quite slow over say WAP or EDGE and I'm not very patient for things to load.

I think this is a great idea, worth investigating further. There are some cases where it won't work where we do want dynamic updates to the UI – public spaces like museums, hotels, etc. But it does make sense for your personal residence where things don't change that often, or if they do, you'll just go through the online designer to make an update. Android's open tool chain and unencumbered app distribution show their benefits here.

Thanks for your comments, Andy. They're very helpful.

Document generated by Confluence on Jun 05, 2016 09:31