On 2011-07-22 04:26:48 -0400, Tony Gravagno
<tony_gravagno (AT) nospam (DOT) invalid> said:

I believe that most of my comments were wrt technical features.
Regardless, a smartphone is lacking the scanning features I mentioned.
I know it wont work for the warehouse and manufacturing environments
that my clients have, but maybe it would for the ones for which you
have experience. RTFTJ, right?

Yes, possibly.

I assume you're being facetious, or has America actually reached that
level of litigiousness?

Giving people access to the data has always been the goal. If the form
factor doesn't matter, then why do we have smartphones, tablets, PCs,
netbooks, etc? Clearly, the form factor DOES matter, and in a big way.

The downside is for the developer that wishes to support multiple form
factors and provide (or require) native code features. I guess this
has partly been Dawn's point and what she wishes to avoid by using a
browser interface, though there is nothing new with that notion. I
think, as you mention in part of your tome that I snipped, a browser
solution may have merit for Sholom as well.

--
Kevin Powick

Kevin Powick wrote:
Once again I'm caught trying to be brief. My intent was that just
about all functionality is available in just about all form factors.
So the question isn't "can I do X?" anymore, it's "I need to do X,
which device gets me there in the most comfortable manner?".

That summarizes the world we live in. We have lots of options but
there is no one-size-fits-all solution. There are pieces here and
there, and none of us are familiar with all of the pieces which can be
assembled to create exactly what we want. It's extremely frustrating
that there are few universal connectors.

The browser is the ubitquitous client (available everywhere) and
plugins like Flash, Silverlight, and Java applets are the equivalent
of the universal connector, making the client found everywhere do
pretty much everything.

But all of these tools are evolving. There is the occasional new
browser like Chrome, the occasional enhancements to the platform like
HTML5, and the occasional nuances in the plugins regarding device
access and local storage. Even the "universal" solutions aren't
"universal". But I'd maintain that for anyone who really does need to
hit the widest possible audience with the best available features,
browser plugins deserve serious consideration. Anyone can chime in
with anecdotes about 'this one doesn't do that', but rhetoric needs to
be set aside, and decisions need to be made.

I've been saying for years, it doesn't matter which tools we use.
Tools are irrelevant, though RTFTJ is the goal. We're never going to
be completely happy with any solution we adopt. But people need to
jump on the train somewhere and start moving forward.

I'm completely bent that my adopted technology of choice, the
Microsoft .NET Framework, isn't ubiquitous even with platforms like
Mono and Silverlight. So I'm adapting by going back to Java and now
HTML5 for some efforts to get access to new things that I want. Point
is - I'm not arguing that anything is "best", just citing some options
as being better for specific tasks as we navigate this minefield of
incompatibility.

T

On 2011-07-22 17:47:39 -0400, Tony Gravagno
<tony_gravagno (AT) nospam (DOT) invalid> said:

Once again? Catching something so elusive is a rarity. Please give a
hunter his due credit.

--
Kevin Powick

On 7/22/2011 5:47 PM, Tony Gravagno wrote:
Tony, could you elaborate on this. (Maybe in another thread.)

Sholom

Sholom wrote:


This might be too detailed for some here, but I am truly elaborating
to spell out concerns for anyone who may not be familiar with various
trade-offs of our tool options.

Please remember that underlying everything I'm a solutions provider
and not a technology biggot, despite years of having to tolerate such
accusations. I have no alliances to specific technologies. I use
what seems right for me and the tasks that I'm asked to perform. So
I'm not moving away from .NET which still solves most problems I
encounter, I'm simply adding more tools to my kit. (That term "going
back" could have given the impression that I'm dumping .NET, sorry.)

Before the .NET Framework I was using Java, VB6, and other tools to
write my code. Java has never captured the imagination of Pick people
outside of some jBase and U2 folks, and IMO, its development and
adoption seemed to plateau around year 2000. When .NET came along it
was apparent to me that it was a game changer for thick/thin-client
And servers, so I jumped aboard. Since then, I've been happy to use
that single platform for Windows server development, Windows
thick-clients (which no one asks for anymore), and using Windows
servers as a middle-tier for any thin-client (including mobile).

Again, it's not that I mindlessly drank the Microsoft Kool-Aid, as
some have opined. It's that Microsoft provided a platform which I
could use for about 80% of the problems encountered. Over the years
I've been trying to convey this experience to colleagues so that they
might similarly benefit, and to my joy, despite no small amount of
kick-back, many people here have benefit.

Now we have mobile platforms, which I personally feel a need to
support. Despite current lack of wide interest in this community,
mobile is becoming the dominant client for many consumers, and I
believe it shouldn't be avoided. The pushback in MV forums is exactly
the same as we saw for "internet" in the 90's and "web services" in
the the 00's. There was the "I don't see any value", "no one is
asking". Then, after losing business to competitors who support the
paradigms, people here eventually geared up for them. I'd like to say
that once again .NET is a ubiquitous solution for this new paradigm,
but it's not.

If we just want to do thin-client browser UI's (BUI) for mobile, then
sure, .NET is fine, and almost nothing changes, except that I do think
HTML5 should be used for most new work - ergo that part of my quote
above.

But common coding methodology these days is to offload more
functionality to the client to minimize network chatter, and with data
bandwidth being what it is, this is more of a requirement than an
option. Putting code on the client used to mean thickening up the
JavaScript, or using Flash or Silverlight. As mentioned in other
threads, this still doesn't give us access to the device, which is the
value-add that makes this medium compelling. And while it would be
nice to look to the plugins to provide device access, or to add more
complexity to BUI, the plugins are not yet fully supported across a
significant percentage of devices/releases.

So at this point we need to look to apps to create the experience
sought by consumers. The mobile device isn't just a client, it's a
stand-alone server, and each has it's own primary language, framework,
file-system, etc: Objective-C for iOS, Java for Android/Linux, and
..NET for WindowsPhone7 and soon Windows8 Tablet. Unless we use
multiple languages, frameworks, and IDEs, we're forced to choose
between platforms.

Bridge technology at some point might allow us to "write once and run
anywhere". That phrase was once the mantra for Java, but Java never
quite fulfilled the promise. Tools like MonoTouch and MonoDroid are
available, but they are not yet mature either.

If Mono was up to speed, then I would only need C# for all platforms,
and I could continue to recommend .NET as the vehicle for the new
paradigm. As big as Microsoft is, and as valuable as Mono is to them
and everyone else, you'd think that the world at large would put more
weight behind Mono as the cross-platform tool of choice, but it just
hasn't happened.

For me, that leaves .NET for WP7, Java for Android, and I'm simply not
going near i-Devices for various reasons which might justify a new
thread.

I've observed, and Microsoft acknowledges, that Windows mobile devices
(including tablets) still have not captured significant market share.
Until Windows gets the blessing from the consumer market, I can't
recommend that for business/personal use, though as a stand-alone
business device to solve specific problems I have no problem
recommending it. This means for the current state-of-the-art, I would
bend more development effort toward Android and Java, and that's what
prompted my recent blog and forum postings. I'm just lamenting that
this is the position that (I feel) Microsoft has put me/us into by not
recognizing and responding to market trends better.

As always, YMMV.

I hope that wasn't too much.

T