I was in the bookstore yesterday and took a look at a book named (oh,
I really want to write "nook" here)

Pro Android Web Apps, Develop for Android Using HTML5, CSS3, and
JavaScript
by Oehlman and Blanc

They had the answer to the question of what you can and cannot do with
web-apps on an Android, when single-sourcing your application for
multiple platforms using web apps. Their run-down was that using the
browser run-time environment you have access to local storage and
databases and to GPS information. Additionally, by means of a bridging
framework, such as PhoneGap (or Rhodes and perhaps others), you have
connectivity detection, H/W sensors, access to the camera and partial
access to the touch screen and screen events.

However, when writing a browser-based Android app there is no access
to messaging and notifications. That would definitely be a sacrifice
for some types of applications. I have not researched it further to
get a handle on if/when that last barrier will be lifted, so use of
Android messaging/notifications would be the primary technical reason
to write a native app.

Based on what I have read since responding to a previous thread on
android apps with a comment that I thought that writing web apps
rather than native Android apps seemed like it would be a good choice
for many organizations and applications, I am even more convinced that
the web-apps approach for cross-platform development will be coming on
strong for mobile development. It does sound like you need to use a
library like PhoneGap to get the most out of mobile development. Has
anyone here given that a spin?

--dawn

dawn wrote:
Dawn, you want so hard to be right but you're not doing your homework.

A few minutes on Google will reveal that both Rhodes and PhoneGap
allow you to wrap a web page into an app which you then deploy. They
don't allow browsers to access native functionality.

The HTML and JavaScript in tools like this are extended to use the
underlying plugin resources. If you actually look at Flash/Flex and
Silverlight you will find that they do the exact same thing, providing
the exact same conveniences, just with their own unique value-add.
You code with JS in Flex, C# or VB for Silverlight, and you get access
to special client functionality through the provided framework. The
only difference between your newly discovered tools and the plugins
you dislike so much is that the final product runs natively on the
target rather than being deployed to the browser container (wrapper
within a wrapper).

A key difference between PhoneGap and Rhodes is that Rhodes apps
target multiple platforms rather than just one. You build for each
target platform separately, with varying amounts of pain for each. To
use Rhodes, you need to learn Ruby. (One amusing aspect of Rhodes is
that when they return data from an external source it's represented as
"object / attribute / value - triples", but no, it's not Pick.)

So if you want to access device resources, you can't yet do it all
with browser pages. Pick your poison, Ruby, Java, ObjectiveC, C#, or
VB.NET, but you're still going to learn a different language and
framework, and you still need to deploy an app.

T

On 2011-08-01 08:26:17 -0400, dawn <dawnwolthuis (AT) gmail (DOT) com> said:

When you finally adopt a strategy, please post your experiences. Few
in MV seem to be doing mobile development in production, so I'm sure
many would like to hear how it goes for you.


Dan McGrath tweeted this link today about Android vs iPhone native
development. It's the opposite of the cross-platform approach that
you're looking at, but interesting, none the less.

http://nfarina.com/post/8239634061/ios-to-android

--
Kevin Powick

On Aug 1, 6:32*pm, Kevin Powick <nos... (AT) spamless (DOT) com> wrote:
Yes, the parts I skimmed were definitely interesting. I very much
agree with this statement
"You’re going to just hate Eclipse. You’re going to hate it with the
heat of a thousand suns. It’s going to feel slow and bloated and it
won’t taste like real food."

This is only one of the reasons I want to avoid writing Android-only
apps, however.

As you might have guessed, I have written something that runs on an
android (a web application) but it not optimized for mobile devices
yet, and I will not be doing anything Android-specific soon, knock on
wood. --dawn

On Aug 2, 9:32*am, Kevin Powick <nos... (AT) spamless (DOT) com> wrote:
Hi
Interesting thread. Also putting the HTTP: in front at least gets
Google to send it to the proper place in the end.
As Well as writing special apps how about using what is on the phone
such as spreadsheets to enter data and then just send a .txt file. I
am thinking of situations such as Fuel deliveries which are rarely
more than one product to one tank for a home. Or logging contractors
who pick up a load of logs from the landing and deliver it to the
mill. The truck has a built in scale and the mill also weighs the
truck in and out so only a coulpe of entries required.
Peter McMurray

Here is a completely new medium with more power in one's hand than we
could imagine a decade ago. And once again we see a Pick-style
solution where anyone who actually uses one of these devices would say
"are you kidding?". As an analogy, I picture an Amish guy looking at
a Corvette and thinking "I wonder how many oxen it takes to pull that
baby." Using a spreadsheet for data entry, on a mobile device or
desktop, is about as conventional and appealing as creating sales
orders in a Pick environment with ED.

I'm hoping one of those metaphors will stick. It's exactly this kind
of solution (spreadsheets for entering data) that cause end-users to
run away quickly from Pick and the people who support it.

Use the right tools for the job.

All that said, particularly for Android, Google docs are used as an
intermediary mechanism to move data between some environments, even as
small databases by beginning programmers who don't know any better.
This is because Google Apps are accessible via an API and HTTP/REST,
so reading/writing documents from outside is very easy. But for real
work, by people who have a real job to do, the above solutions simply
don't fly in the real world.

So here is an alternative solution that make use of the technology.
THIS is what people want to see these days: The trucks are outfitted
with sensors that get the current weight/volume of the contents of the
tanks or flatbed. When the trucks stop moving the weight is taken and
transmitted by Bluetooth. (This can be done with onsite truck scales
as well.) The encrypted transmission is received by the driver's
mobile device in his pocket, which uses the GPS to record the location
associated with the weight data. When the truck is reloaded, the new
weight is transmitted. When the driver is in range of their office or
a client, the data is again transmitted via Bluetooth. The GPS
coordinates identify the sites where activity occurred.
Starting/ending data is used to calculate a difference, being units
sold or purchased. Statements are generated and sent by email.
Client payments are processed by automatic bank deposits.

All of that is managed without anyone touching a keyboard or even
looking at a device.

THAT kind of transparency should be our goal for technology. You may
only get half way to complete touchless operation for any given
application - or you might make it even cooler by requiring voice or
biometric confirmation of data. You might require the onboard camera
to scan barcodes to confirm transactions. Or you might capture
consumer signatures on the device to be sent back with invoices as
confirmation of their acceptance of goods. This is all far better
than some of the error prone, time consuming, resource intensive
activities that make almost zero use of available technologies, and
yet which some people call "solutions".

The device is irrelevant.
The language is irrelevant.
People will do business with you when you provide solutions like this.
They will ignore you and do business with someone else when you don't.

T

On 8/9/11 2:33 AM, Tony Gravagno wrote:
So you think my abacus app for teh Droid is not going to sell? =`;^>

--
frosty

frosty wrote:
On the contrary, I think that one would be hot.

Since we're here. Developers in the mobile market hunger for
different ways to store and process data. An enterprising Pickie
might do very well to make it easy for people to create BASIC rules,
then remotely and securely execute them via a web service. Right now
people are trying to do this with Java on the client, or Java or PHP
or something else on servers. They're having a miserable time of it.
I've actually already done something like this but I just don't have
the time to build a compelling model around it.

T

On Aug 9, 1:33*am, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid> wrote:
Times and locations are transmitted to the police computer which
automatically issues citations for speeding to the trucking computer
which automatically transmits payment to their bank and also dings the
drivers paycheck.

Sha Zam!!

wjhonson wrote:

That's funny. Such things are possible, though not always desirable.

For our purposes, GPS can be used to msg back to the office when a
driver deviates too far off course between stops, or when they're
speeding, or when they're sitting idle for too long, or when code
determines that they are going to be late to make a stop. When a
timing issue is determined, the driver can be called or msg'd and an
automated call can be made to subsequent stops to notify them of
delays - all without any manual intervention.

Or let's say you have drivers in the field making pickups or
deliveries and some new order comes in at the office. The system can
identify the driver closest to a pickup point and SMS them or notify
them with the app to take action.

T