On 2011-07-20 15:49:37 -0400, dawn <dawnwolthuis (AT) gmail (DOT) com> said:


HTML5 definitely has some new features that will make for richer
browser-based applications. And yes, on paper, such a x-platform
strategy should be better than a native one for most things. However,
when we hit the real world, it just doesn't seem to work that way.

Your comments remind me of the early Java years, when it was being
touted as the answer to x-platform applications. Sure there are some
great Java x-platform apps, but 15 years later, native applications
still dominate. And just as the desktop market made that decision long
ago, so will it most likely be the case in the mobile market with
HTML5. There will be buzz, there will be some star applications, and
HTML5 won't be going anywhere soon, but native apps will still dominate.

Part of the reason will simply be that the HTML5 "standard" (only as
standard as each implementor's version), just cannot evolve as quickly
as vendors introduce new features into their hardware & operating
systems; along with updates to tool sets that allow developers to
leverage these new features.

Developers, managers, software houses, etc. love the idea of
single-source multi-platform. Consumers want the most feature-rich
experience that their hardware/OS can provide. Consumers pay the
bills. Native apps will continue to rule.

Does this mean HTM5 is a dud? Of course not. The features being
introduced by HTML5 are welcomed by web developers, and if one's mobile
strategy can benefit from a browser-based approach, it should make it
all the better. I just don't see HTML5 being being any type of a death
knell to native apps.

Seriously? You believe that the vast majority of mobile apps are
games? Actually, only 14% of the apps in the US Apple App Store are
games. As of June 2011, total apps were 428,351 of which 63,586 are
games. On a daily basis, 6 times as many non-games than games are
submitted to the Apple App Store.


Yes, definitely.

--
Kevin Powick

HTML5 does not do what an app does. It is not a replacement for
mobile apps. HTML5 does not provide consistent access to the
following mobile device features:
- interface with mobile device sensors (accelerometer, etc)
- the camera
- microphone input, record, playback, storage
- client-side email or contacts
- SMS
- GPS/WiFi for location-based services
- background functions
- proactive notifications
- bluetooth
- the local file system

I'm not saying "none of that functionality exists". Some of it is in
the spec pending implementation. I'm saying that as of now, support
is currently Either undefined, Or has limited implementation across
the many platforms where attempts at support are being made.

Browser sandbox restrictions also prevent HTML from cross-site
operations, not so with apps. This is both a feature and a failing,
depending on the application. There are other places where some
limitations on the browser present value over an app. But the whole
point here (now anyway) is that neither approach is generally
"better", they are simply "different" and (here we go) one needs to
select the right tools for the job. Yes, there are instances of HTML
clients being wrapped in apps, but this is as much an exception as
Windows apps exposing a browser as part of their UI.

HTML5 may never be cross-platform capable. The browser wars have not
ended, and each browser developer is free to implement the standard as
they see fit. HTML5 is only partially implemented, and Most
authorities agree that it may not be fully implemented for another
decade. By that time the whole game will have changed - as is evident
by this whole mobile market which virtually didn't exist more than
(roughly) 4 years ago. What's consistent here is change. Point
being, "HTML5" is a concept, not a solution. Use it for what you can,
just understand its strengths and weaknesses.

The mobile app market (for all devices and vendors) consists of
hundreds of thousands of published applications, only some percentage
of those are games.

When you say you don't understand the market, internalize that above
statement.

There are additional apps that aren't published for general
consumption but which are used by companies and other groups without
first posting through the App Store or Market. Not all mobile apps
are cataloged and for-sale to consumers. It's this kind of app that I
would encourage MV developers to consider. Something useful for their
specific clients and throughout their channel.

Dawn, you have said many times that you don't know a lot about this
area, and yet you make strong assertions as though you have some
information or experience. Please. If you don't know, just sit back
and relax. Don't feel compelled to chime in with a firm opinion when
you aren't familiar with the topic. You aren't in a position where
you need to posture your consultative prowess in case someone wants to
commission you for a gig - so don't. Don't get professorial and
argumentative against points that are key to the discussion but about
which you have been largely unaware until reading about them here.
Ask questions. Learn. Let others who are in a position to make some
good use of this medium do so.

Unfortunately, as usual I'm afraid this discussion has digressed into
oblivion from the very first response - for the same reasons as
plugins, web services, telephony, and others. Thanks for your
contribution to the Pick community.

I'm hoping John and others will resurrect the topic into something
more productive.

T

On Jul 20, 4:40*pm, Kevin Powick <nos... (AT) spamless (DOT) com> wrote:
No, no, that is not what I meant with my typo. I intended to ask "If
you exclude games, what are the apps that attest to the NEED for the
native platform apps?"

I also do not doubt that there are some, but when it comes to
"business software" I suspect the ones that really could not be done
on a web platform are in the edges of the bell curve, not the thick of
it. I definitely know there are a ton of apps that are not games. I
also know that some of these I prefer to have as native apps, but I do
not have a clear understanding of how to classify these.

Ok, good, then what are these -- the business software applications
that could not successfully be written with a browser UI (and
requiring the internet, admittedly) so that they really ought to be
written as native apps for the OS? I would like to get a better handle
on that category. It is very ill-defined for me. Thanks. --dawn

On Jul 20, 6:14*pm, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid>
wrote:
Good. This is helpful. I can see that one category of apps are those
that need to interface with the device. I would typically think of
those as "tools" rather than apps and would think that the web apps
could use such tools, but perhaps that just isn't possible or feasible
at this point. Another category appears to be those that work with
local data on the phone. It makes sense to me that the browser apps
are not going to have the access to the local disk for those. Those
are the two big categories I am taking away from your list. I knew of
both of those categories of apps, and it is helpful to see that your
list fits into those categories. There is nothing of which I am aware
for what I'm doing that would require either of those, but I can
understand that others very well might have such a need. I would like
some more specific ideas and examples of the type of apps that a
database VAR or customer might want, but I do not doubt they exist.

Yes, that is the biggie. There are features in html5 to try to address
some of that, but there will continue to be the issue that we do not
want our browsers reaching into the machine and extracting data.

Yes, cross browser has its charm, but it is a pain in the neck!!

Hmmm. OK, then I'll say "html/css/javascript on the client using an
html 5 doctype" which surely is an existing solution, not just a
concept.

Come on Tony, try to keep the "I'll tell you how little you know"
stuff to a mild roar, OK? It gets tiring. Just like you, I know some
things and I don't know other things, but it is OK for me to state
opinions based on what I do know and learn more by voicing them.
That's how people learn and refine their views. I just happen to be
willing to say that I don't know everything ;-) A more appropriate
response, in my opinion, might be for the other party to acknowledge
the same rather than to say "yeah, you are right, you don't know
everything."

Yes, this is exactly what I have been trying to think of. I can
understand that my browser app cannot reach out and grab phone
contacts, but it kinda makes me cringe to think of the app that would
do that, so I still could use some good examples. Presumably a browser-
app could request the upload of that data, but for some apps that
would surely not be as nice. I really do know there are some business
apps that would be wise to write specifically for an Android, but my
creativity is not yet coming up with a list.

I have said that about every area. Ask me if I know about Calvinism?
About sewing? About how to be a good grandma?I know there is a ton
that I don't know on every topic. That said, if I had to write an
android app by the end of the day today, I'm one of the people in this
forum who could do so (and also one who would not participate in such
a challenge -- that isn't my thing).

Sigh.

We are all learners and all teachers as far as I'm concerned.
Sometimes I have questions, sometimes I have opinions that need to be
refined. I do not always have all of the answers to be sure.

I was just engaging in conversation as part of a learning experience.
It sounds like that is interfering with your ability to show your
feathers. You are right, I have no need to look like I know everything
or even anything. It is more important that my toenails are a pretty
pink (oh, and they are!)

Sheesh. I guess I'll do my fingernails too.

OK, brother, that put me over the edge. I think I have just been asked
to leave. OK. I am sorry if I have not been a good citizen of this
community. I have tried to be. If others want me to leave too, please
do not blast me in this forum (this definitely was hurtful for me),
but feel free to shoot me an e-mail. If I am not welcome here and this
is not just Tony's opinion, please clue me in. I'm really feeling
awful right now. Maybe I deserved it. I dunno. --dawn

On 7/20/2011 5:14 PM, Tony Gravagno wrote:
Tony, er, the topic you address and the topic Dawn addressed differ -
hers is her pursuit of understanding, yours is your own understanding,
of mobile apps nestled into the world of mv apps and customers. Your
response is misdirected and rude. I readily understand its source, but
let it go. I value each paragraph you write, here and elsewhere, and
they combine to a powerful representation of the very high commitment
and energy and excellence you bring to your work.

We each struggle when debugging our own views based on insufficient
experience; we devote great commitment and energy required to the chase
for better knowledge and better understanding. For example, last
evening I witnessed a presentation of Mono for android app creation.
Not having a passion for c# or .net I was ill-prepared to question the
benefits and limits of the approach, and (once again) was left muddled.
From the audience of experienced android developers, the best
questions were weak; we cannot all articulate balanced responses
quickly to this dynamic medium of app and mobile app development.

There are a large number of producers of apps, mobile or otherwise.
There are a large number of consumers of apps. One of the App Inventor
writers produces work at a profit, apparently swapping apps to his local
businesses in trade for services - brake jobs, party catering, and the
like. Our classic mv customers such as Sholom's newly arrive as android
prospects missing only the hardware (it'll come), while Mobile Frame has
been institutionalizing mobile apps for major IT departments for years
now. This is not an easy environment to 'get your head around'. It is
certainly not an easy environment to sell in, requiring different sales
conversations. My point here is that there is a lot to learn, a broad
array of disciplines to study, and certainly a lot of difficult, at
times clumsy, exchanges to overcome.

The nice part of this thread, however, is the openness of the subject -
two nouns, no verbs. It can, and has, wandered, as expected. Being in
the learning phase of the intersection of these worlds now, for me it's
been interesting. Clearly there are lots of more complex subjects
available, such as the career value of learning the structure of the
android system (seen the sdk?) as a component to a career as an mv app
developer. There's lots of relevant history which might illuminate this
subject, as we all have made trade-offs in our technical educations
under the pressures of continued productivity to maintain current
commitments. Anyway, lots of new subjects are available - we don't have
to resurrect topics, we can just re-title.

For anyone interested in the topics that these threads have raised,
including languages, cross-platform issues, access to hardware, and
browser vs app tradeoffs, the following link discusses (mostly? all?)
free tools for writing cross-platform (iOS, Android, Palm, BB, WM)
apps.

http://bit.ly/bzcuvK

I think it's a bit dated, being over a year old, but it's a good start
for someone to research the current status of this area. For now, I
know nothing about any of those tools except App Inventor. My intent
here is just to toss the info out, not to participate in discussion on
any specific tools.

WRT CDP: MV is just the back-end component from which you can serve
data, metadata, and page formatting. You can use any device, any
developer tool, any MV platform, and participate in the modern world
of mobile computing. Carpe diem. That's all I'm trying to do here:
not promote, defend, or decry any specific approaches, just get people
to recognize that they CAN do these things. It's just a matter of
defining your needs and then shopping for RTFTJ (RTs4TJs?). (I can
imagine Chandru cringing at so many recent mentions of that phrase.
LOL)

T