[opendtv] Re: Fwd: Re: Apple loosens its chokehold on app development
- From: "Tom McMahon" <tlm@xxxxxxxxxx>
- To: "OpenDTV" <opendtv@xxxxxxxxxxxxx>
- Date: Sat, 11 Sep 2010 07:41:54 +0000
Use LISP.
Sent via BlackBerry by AT&T
-----Original Message-----
From: Kon Wilms <konfoo@xxxxxxxxx>
Sender: opendtv-bounce@xxxxxxxxxxxxx
Date: Fri, 10 Sep 2010 21:54:49
To: <opendtv@xxxxxxxxxxxxx>
Reply-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.
Other related posts: