Slashdot Mirror
Adobe's iPhone Hail Mary
snydeq writes "Fatal Exception's Neil McAllister questions whether the move to port Flash to the iPhone isn't a last-ditch effort on Adobe's part to remain relevant in the quickly evolving smartphone market. By allowing developers to compile existing Flash apps into native binaries, Adobe believes it has found a way around Apple's requirements that no non-Apple API interpreted code may be downloaded and used in an app, a clause that has also prevented Sun from porting JVM to the iPhone. The resulting apps will be completely stand-alone, with no runtimes and no Flash Player required — if Apple lets Adobe get away with it, no small feat given how protective Apple has been about its app market. But as much as Apple has at stake here, Adobe may actually have more, McAllister writes. 'Already the idea of using Web languages and tools to build smartphone applications is taking hold. Palm has built an entire smartphone platform around the idea. Apple supports the use of Web technologies like AJAX to build applications based on the iPhone's Safari browser. And developers will soon even be able to build Web-based applications for BlackBerry handsets, thanks to a new SDK from Research in Motion. As late to the game as it is, what Adobe needs now is to convince developers that Flash is better than the other options — and that could be a tough sell.'"
While PHP was originally developed to be a server-side scripting language to generate dynamic websites, it's really capable to work in CLI and even in GUI applications. I do most of my server scripts with it instead of bash or the other popular ones, just because it's a lot more readable and quicker language to work with.
So, you might want to tell me why would I be joking? The only problem currently is that there's no support for multiple processes in PHP and you have to use hacks and forking to accomplish it (not that Flash would have it either). I except this to change at some point too, and with iPhone it's hardly a problem as you cant even run multiple apps at the same time.
Sure, you cant do the next Crysis with it, but I can think of many kinds of games especially on mobile phones that would work great. On top of that PHP-GTK's and other frameworks drawing functions are fast.
WinBinder is one of such extension for PHP that provides easy access to Windows API's and builds an exe from it.
One of the powers in PHP is it's huge build-in function library (+ extensions) which really makes developing and programming faster and more fun, when you dont need to hunt such functions or libraries from Google or make the functions yourself (which in most cases probably aren't as good optimized). I always wish other languages would have such by default (c/c++ especially is pain in the ass and all the dependencies just create problems when moving from environment to another).
Adobe controls the spec. They keep on adding on new functionality in a way that has to be reverse engineered, so that there is a lag time between when they have developer tools for it and the free software makers have developer tools for it. That has a direct impact on first to market opportunity for new functionality for developers, meaning that the free software version is mostly irrelevant if developers want to stay competitive. Does that sound possible?
Adobe is claiming that a few apps already on the store were built this way. Here's a guy that disassembled one of these apps and did a writeup:
http://devwhy.blogspot.com/2009/10/flash-on-iphone.html
Can you cite an actual example of something wrong with it?
Sure. I've used it, and it gets the job done, but I didn't much like it compared to the many other options - trying to force development of a GUI application into PHP is my idea of a nightmare, and comparing it to C and saying that it has far more libraries is laughable, considering that most PHP additions (image manipulation for example) are just wrappers around C based tools. My object to PHP is not that it is impossible to use, it's that it's messy and not very well thought out in many regards. It's quick and dirty, with the emphasis on the dirty.
A few problems with PHP off the top of my head:
There is no clean separation of logic and view (or MVC if you prefer that split) - the language itself encourages mixing code and presentation, often with horrendous results. You can work against this, but you're always going against the flow - see the many examples of PHP CMS etc for great examples of this kind of mistake in action. They work, but only just, and the internals are often very messy.
The naming conventions for the API are all over the map - any language that has functions named stuff like mysql_real_escape_string, as opposed to the still extant mysql_escape_string, has obvious problems with design philosophy. Maybe next year they'll come out with mysql_really_escape_the_string_this_time? It is very difficult to guess function names because there are no clear conventions, and the whole thing has grown organically to a huge bundle of disparate functions, some of which definitely do not belong in a language and should be broken out into modules or put into objects like strings. Stuff like eregi_replace, str_ireplace and str_replace is needlessly confusing because the naming conventions are inconsistent and cryptic.
Strings and arrays are not proper objects, so you have to use a mix of procedural and oo code everywhere - it'd be nice to be able to call methods on strings and chain stuff like Ruby. The object model was also weirdly broken till PHP5 and is really bolted on.
Doesn't have closures (just added to C/Obj-C by Apple).
Unicode strings are still not properly supported.
The syntax inherits everything which is bad about perl (it's quite possible to write very difficult to read code), and doesn't improve on it one iota.
I'm sure I could do a search and turn up a few more issues, but it generally just feels ungainly compared to any other language I've used (Ruby, Objective-C, C, Python). I think the author of the above comment saying everything could be done better in PHP really should explore other languages before dismissing them as somehow lacking, and understand that different languages have different strengths, and learning to use other languages could teach them something about how to write good code in PHP.
Having worked with it, PHP doesn't strike me as a very good language by most metrics, and it certainly is not more complete than the many other options in any arena. There is simply no comparison in my opinion with a properly structured API like cocoa for GUI apps.
There's a major misinterpretation of the situation regarding interpreted languages on the iPhone. Apple has absolutely no qualms about interpreted languages used on the device. In fact, a huge number of games are built around lua-based game libraries. It's a no-brainer! All you have to do is ensure a user can't add and execute arbitrary scripts by way of downloading them later.
The issue here is getting the right balance to make it through the review process. See, your game could allow for added levels for free down the road, a totally acceptable (and relatively common) occurrence. It's entirely okay if those levels are composed by your scripting language. What isn't okay is if the game will execute arbitrary scripting, to essentially distribute a target platform as an app. That's about where the line is drawn. This could be seen with the final result of the commodore 64 emulator app. They couldn't enable basic but they can allow for delivery of additional games, which are obviously interpreted. A developer might choose to use an encryption scheme or signing scheme to ensure they only execute gamescripts that should be, for example.
This relates to flash because there's nothing stopping adobe from porting the flash engine and making it possible to export individual iPhone apps that include it and execute some flash game that is packaged in with the app so long as that game can't randomly pull in more flash to execute. Of course, if you could compile the entire flash application to native code that would be more ideal in the general case assuming you have no consistency of execution problems. But that's not always the best idea. Take java, for example. Its design causes a complete native compilation effort to result in worse performance and lower reliability because the runtime optimization of the JVM is more effective than static code optimizations.
Anyway, I guess my point is that the limitations about virtual machines and script languages aren't quite what is popularly regurgitated. The issues with the iPhone and these technologies is one of post-app-install delivery of arbitrary code execution. It's not a problem with the use of VM/Script itself.
I read the script, and I think it would help my character's motivation if he was on fire. -Bender