[opendtv] Re: Fwd: Re: Apple loosens its chokehold on app development
- From: Kilroy Hughes <Kilroy.Hughes@xxxxxxxxxxxxx>
- To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
- Date: Thu, 16 Sep 2010 06:24:07 +0000
Fine, Flash and HTML such for iPhone apps. You can talk about that if you
want, but I wasn't.
The idea of making every interactive video, DVD, Blu-ray, interactive TV play
on every different type of device by writing a native app for each is not
viable. I was talking about some of the practical options, one of the widest
used being Flash because a couple hundred million computers use it, and
computers and DVD players have been the most numerous interactive video
devices; but an increasing number of cell phones, other portable devices,
Internet TVs, a variety of Internet connected settop boxes, etc. are developing
video and programming capability.
It will be interesting to see what presentation language and application model
will hit critical mass for publishing to a range of net connectable devices.
My guess is that some application of HTML5 will dominate.
Kilroy Hughes
-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of Kon Wilms
Sent: Friday, September 10, 2010 9:55 PM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: Fwd: Re: Apple loosens its chokehold on app development
On Fri, Sep 10, 2010 at 9:04 PM, Kilroy Hughes <Kilroy.Hughes@xxxxxxxxxxxxx>
wrote:
> 1. Write once, run everywhere. Currently a SWF file can play on a few
> hundred million PCs, most Macs, and a smattering of other devices like
> netTVs, game consoles, mobile devices, maybe a toaster or two. Having to
> write and compile a separate app for iOS to approximate the interactive
> functions of each SWF file is the opposite end of that scale.
Write once, debug everywhere. The SWF model is to code for desktop and if it
happens to work on other devices then so be it. Mobile and embedded still does
not have the power to run SWF files across the board with any reliability. Even
Adobe advises debugging on all targets.
> 2. Allow "content" intelligence/"interactivity" in addition to
> intelligence/interactivity programmed in the app. Currently, SWF files,
> DVD-Video discs, BD-J titles, etc. have various script language, presentation
> language, procedural language that allows creating different user experiences
> in each piece of "content", while the DVD player, Flash player, JVM, etc.
> "app" stays the same.
>
> That makes it easier to get a single app/player tested and distributed
> (compiled from C or whatever), but include some programmability in the
> interactive video format it plays to enable relatively easy authoring of
> "interactive content", often by non-programmers, but enabling different
> behavior, user experience, etc. without compiling and testing a new app.
Sorry I'm not buying that as a selling point for SWF. *Any* language can
provide scripting and 3rd party encapsulation, even C.
> Presentation languages, like DVD's and HTML tend to be the least flexible,
> easiest to write and test, and least likely to drain CPU cycles and battery
> or cause blue screens. Native interpreters can use device optimized
> execution, refuse to divide by zero, reject invalid statements, etc. because
> the language is declarative.
Actually HTML5 is the *most* likely to drain CPU since most devices do not have
display acceleration and those that do, suffer with programmatic interpreter
hits from running i.e. JS libraries and routines. Native code is always faster.
Always.
> I think it is appropriate to allow a judicious amount of markup and script in
> portable "content", but leave the procedural language and low level APIs to
> native system apps or well tested "installed" binary apps.
Which is the approach taken by PhoneGap, Titanium, Corona, Unity3D, ... all
available for iPhone, all without the 'deployment' issue. And if you're doing
games the Lua-based engines are the immediate and obvious choice.
If you want to write apps for iOS I still maintain it's time to suck it up and
learn a new language. Else you are just doing yourself a disservice.
Cheers
Kon
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts: