I just posted a blog entry about using Android as a UI for MV apps.
Comments welcome here.

nospamNebula-RnD.com/blog/tech/mv/2011/07/android1.html

(copy/paste to your addressbar starting from Nebula)

Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells mv.NET and other Pick/MultiValue products
worldwide, and provides related development services
remove.pleaseNebula-RnD.com/blog
Visit PickWiki.com! Contribute!
http://Twitter.com/TonyGravagno

On Jul 15, 2:22*pm, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid>
wrote:
I can imagine an application that would be highly useful written
directly for the Android OS, such as a game that someone might want to
play offline, for example, or any other application that needs to be
usable locally. I do not doubt that there are applications that would
be great to run without a browser in the mix.

However, I have no interest in writing with Objective-C for the iPad
and then with Java for the Android and who knows what else for the
next device when we can single-source code when writing for a web
browser to run on many target environments.

I know how to write an Android app and had two students write them in
my Java class (students had to apply to do this instead of a typical
Java application because I told them that it was something I had not
done myself -- I have my limits in how I will spend my time). The
class was using NetBeans but these two students really had to use
Eclipse. Perhaps only a masochist would attempt to write one without
the tools integrated into Eclipse, given that Android Java uses an
altogether different compiler and virtual machine. I know someone
could write an Android app in C too, but it would not be the same as
the objective-C used on a Mac and there is a whole different set of
issues if writing C for the Android.

I would caution any company that has a requirement for an application
to run on multiple devices not to write native apps for the devices
unless absolutely necessary. The browser is like the new p-machine --
it is a run-time environment that can be deployed from machine to
machine. Of course then you have to have a server in the mix too.
Browser on the client and p-machine on the server seems like a very
good strategy for deployment on multiple devices. If you have a more
firm requirement to run on only one client platform, such as only on
an android, well then writing a native android app might be just the
ticket.

For what it's worth, I was just reading this article because I wanted
to know if Salesforce was going to expand beyond Oracle. It happens to
also give hints on what they are doing related to mobile devices --
html5. http://www.constellationrg.com/21138...bets-on-html5/
Yup, just a browser on the client, no add-ins, no muss, no fuss. Apple
is banking on html5 too (but trying to figure out how it will not be
an app-killer). Google is too. As mentioned in an earlier thread about
silverlight, even Microsoft seems to be. I don't base my own decisions
exclusively on such companies (who are admittedly very unlike mine),
but when my own directions and theirs align, it does help. A NoSQL
DBMS on the backend and html5 in the browser for the front-end will be
good for enterprise apps needing to run on most devices for some time
to come, I suspect. Do you disagree? Cheers! --dawn

Singing to the choir here - and you don't necexssarily even need to
wait for HTML-5 ;-)

On Jul 16, 10:47*am, Ross Ferris <ro... (AT) stamina (DOT) com.au> wrote:
Agreed. First of all, html 5 as a doctype is here so that if you wish
to use no new features you can still use html 5 very successfully.
Second, there are several new features with html 5, some of which work
almost everywhere already and you need not use the others or can use
them for deployment on browsers were they do work (we have a <canvas>
bar chart, for example, which works in FF, Chrome, Safari, and IE 8
but we did not do any handstands to attempt to convert it to other
stuff that works in IE 7 and earlier). Folks researching it today to
start writing web pages would be wise to chose the non-doctype doctype
for html 5 over xhtml or html 4.

--dawn

Thanks for your comments.

No one else?

On Jul 19, 1:59*pm, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid>
wrote:
You are going to neither agree nor disagree? What's with that? --dawn

On Jul 19, 11:59*am, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid>
wrote:
Alright. Who stole Tony and replaced him with someone who responds in
seven words?
That is just not right!!!

Will

On 7/19/11 12:59 PM, Tony Gravagno wrote:
/me thinks apps for smart phones are a great idea,
and certainly the way of the future. Just the
other day we were talking about how to get a
Contact's picture into our web-deployed CRM app.
The existing code will scan a photo and upload
it, or browse for an image on the hard drive and
upload it. It was pointed out that very few
people have hard copy images (photographs) of
themselves, and most of our Users don't have
scanners. But almost everybody has a digital
camera handy, usually in a smart phone. So an
app to simplify the process of getting the pic
off the smart phone and into our server would
be very useful.

But... the same problems with compatibility that
have hounded us from Microdata --> R83 --> U2
abound in the smart phone app world: A Droid app
won't run on an iPhone, etc. etc.

--
frosty

John, THIS is the kind of discussion I like to see, where you cite a
problem and a possible solution, rather than writing off the whole
technology.

In short, I think the camera application you describe would be simple
to write and would be used by many. I know I could write it in a few
hours even with the little hands-on experience I have to-date. Mobile
phones are already being used to scan and deposit bank checks, and as
replacements for expensive warehouse barcode scanners. Those
solutions come from people connecting the dots as you're doing,
between the features available on the device and problems which those
features can solve.

As to compatibility, you have a choice - don't do anything because you
can't do everything, or do what you can and accept the limitations
until something better comes along. I think most sensible people will
go for the latter, though in this community people are still arguing
proven decade-old technologies. This problem of cross-platform
development is always going to be with us, and if we can't solve all
problems today, let's solve what we can and hope that solving other
problems will be easier tomorrow. This is at the core of one of the
problems in this market - developers don't do what they can because
they are aware of other things they can't do. That stops them from
providing solutions now and limits their (our) growth for the future.
We've seen this with browser GUI, web services, and now telephony and
mobile.

Interestingly solutions to cross-platform development often come in
the form of third-party plugins, where some entity volunteers to
navigate the complexities of cross-platform anomalies so that the rest
of us don't have to. And yet I can think of at least one person who
decries the cross-platform issues while simultaneously condemning
plugins. Some people need to be left behind because there's never
going to be a solution that they like. I have no doubt that we will
see cross-platform mobile development initiatives (Mono has taken
steps in that direction). What stands in the way is probably not
talent to make it happen but companies like Apple, Microsoft, and
Google trying to stop it from happening until they can figure out how
to keep the platform monetized. For now, use what's available, earn
some money, live to code another day.

Regards,
T


frosty wrote:

A couple links for further reading:

Quick slide show, very simple, very clear:
http://www.slideshare.net/retomeier/...le-development

A bit wordy but quite clear on the topic:
http://techcrunch.com/2011/02/09/htm...s-native-apps/
(Thanks for that one, Kevin.)

Very interesting comments on HTML5 by Google CEO Eric Schmidt:
http://www.guardian.co.uk/technology...ongress-speech