[Mono-list] Android

[Jonathan Pryor]

On Wed, 2009-11-04 at 07:40 +0100, Thomas Jam Pedersen wrote:
> Let me tell you what we want.
...
> What we want to do, is to make it possible to build an application in
> Visual Studio.

That's very easy to do -- even MonoTouch apps can be built in Visual
Studio.  (Testing is another matter entirely, but *building* can be done
in VS, and reportedly is done by some devs on the MonoTouch list.)

> Then be able to run that application on 6 different platforms without
> having to rebuild it for each platform. And it should look and feel
> almost the same on all 6 platforms.

I'd hate to be the bearer of bad news, but this is loony.

Developers have been trying for *decades* to do this.  ALL attempts have
failed (or at least aren't very successful), without exception.

There are multiple problems:

  - Such a library attempts to be a platform abstraction layer, but the
    underlying platforms keep changing over time.  Result: inevitably
    the underlying platform gains a new UI control that is unusable
    from the library.
  - Application are more than just "looks."  There are lots of 
    subtleties at play with UI interaction, from expected drag-and-drop
    interactions to font kerning.  (See also all the complaints against
    Safari on Windows due to font display differences.)
  - Different platforms have different conventions for e.g. button 
    placement, which isn't always easy to abstract out either.

To take some modern-day examples:

Java: AWT is dead (and the prime example of "can't keep up with
underlying platform improvements," much less platform differences -- it
didn't provide a tree UI, iirc, among other things, as not all platforms
provided a tree control).  Swing is better, and actually attempts to
deal sanely with button placement/etc., but it's still a "leaky
abstraction," and users can often tell that it's not a native app just
because of "look & feel" issues.

Qt: Custom draws ~everything, and is actually capable of looking
reasonably native on Windows & OS X, but I've heard from some users that
they can readily tell when an app is written in Qt on OS X.

GTK: Have you seen MonoDevelop on OS X?  It works, which is wonderful,
but "native looking" it is not.  Even on Windows 7, the menus don't look
correct (compared to Notepad), and the File->Open dialog is completely
wrong.  Furthermore, many built-in apps on Windows migrating to
Ribbon-style interfaces (WordPad, Paint), so the very meaning of what a
Windows app "looks like" is changing.  (Though Windows has always been a
clusterf*ck for UI consistency, especially among Microsoft apps.)

The only apps that have a chance of being "cross-platform" are apps
which *completely* control their own UI.  Think "Flash".  Granted, these
apps don't look native *anywhere*, but at least they look the same
everywhere!  (This is still appropriate for many things, such as games
-- where custom drawn everything is the norm -- but for "normal"
programs users often prefer apps which -- shock! -- look like the other
apps they use.)

So in a sense, Silverlight will be a rational way forward with
"cross-platform UI"s, with the *large* caveat that said "cross-platform
UI" will effectively be restricted to a custom UI for that specific app,
with a high likelihood that it won't look like the native UI for that
platform.  This may be acceptable -- again, think Flash -- but it won't
always be acceptable.

THIS is why MonoTouch bound the native iPhone UI.  Anything else would
involve more work and a lesser, less consistent, user experience.
Anything else -- outside of games/etc. -- is a path to FAIL.

For the same reasons, any Mono+Android effort will need to bind the
Android UI libraries (not reimplement or write a theme mimicking, but
actually *bind*).  This way Mono+Android apps will look, feel, and be
entirely indistinguishable from every other app on the platform, and
will thus be able to conform to UI metaphors that lead to a consistent
user experience.

Anything else is insulting to the users.

 - Jon