Originally Posted by lfmorrison
We own and create the content.
We sell autonomous machines that are typically installed in isolated, unpopulated locations. The machines have an embedded server that provides remote control and monitoring of the equipment via an asynchronous streaming binary TCP/IP socket connection to the customers' remote access terminals.
Currently, the sole fully featured remote access terminal that has been implemented is a web app built using Adobe Flex. One copy of the app Flash runs in a touchscreen on the front panel of the machine to provide full control locally. Other connections can be established via the customers' private intranet. As a consequence, the remote control is only available on "desktop-class" operating systems with a web browser capable of running Flash. Unfortunately, we're not just singling out the iPhone (and related iDevices) -- we're basically missing out on the mobile ecosystem.
EDIT: 07/18/2010 10:10 PM PDT Since I originally posted this, I've done some research!
It seems that Flash, as a system, has evolved quite a bit quite a bit since I used it 7 years ago-- not unexpected.
It appears Flash can handle streaming binary TCP/IP socket communications.
In my opinion, it also appears that Adobe is enhancing Flash to the point that it [almost] becomes an Operating System within the Host OS. It provides an IDE, frameworks, a [rather] loose UI, APIs, a program structure, templates, a programming language, and a runtime interpreter/player for application execution.
As to the issue (mine) of a content provider, likely, wanting his content available to all comers regardless of platform... and the need to tailor your presentation [of the content] to each platform so to attract users on that platform. That's not really as important in your case. Yours' is a special case in that you create, deliver and [provide the app that will] consume the content. Yours' essentially is a closed system.
However, you want to replicate this system on multiple platforms... and what you have today will run on windows and Mac desktop platforms, assuming the Flash implementation is equivalent.
Likely, you made the right choice for these circumstances!
Keep the above in mind as you read my comments, and adjust, accordingly :}
-- you dynamically create proprietary content for the client
-- the code that provides the binary streaming (broadcast and receive) is external to the Flash component, correct?
-- you access that content and add a Flash UI component that executes on a custom remote access terminal device, Correct?
-- the client, via Flash, running on desktop-class computers on a private LAN, can access/control the device from fixed remote locations
-- you really don't need to "write once, run everywhere"... you just need to run on the "remote access terminal" and the private LAN computers that, likely, have similar OS, hardware and application configurations
-- you don't provide outside "web" access so you don't need to support every environment, like Linux, Correct.
-- as of today, you can't implement any mobile solutions, because no mobile Flash exists, correct?
-- given that mobile Flash will exist in the future, you will be limited to mobile devices that support mobile Flash and vice versa, correct?
Certainly, it could be easily argued that adding mobile connectivity to our remote control system would be an asset: An operator could be kept up-to-date about equipment status wherever she is, even on the go. She could fully diagnose the cause of any failures and dispatch repair personnel with only the equipment needed to fix the problem, and leaving behind any extra equipment they don't need.
Assume you had mobile Flash running on any mobile device (within reason), including Apple devices.
How would the mobile device connect to the remote device, through the web?
We've been looking into an option to drop Flash completely. HTML5 has been our first preference, but so far we haven't been able to come up with an adequately bandwidth-efficient interface to (or replacement of) our streaming telemetry protocol.
Does Flash handle streaming binary data? Or just the UI and display/animation?
If it's not proprietary, could you elaborate on your streaming telemetry protocol. The reason I ask is that Flash is not known for its bandwidth efficiency. The last time I tried to use Flash was 7 years ago to: every 60 seconds, update 31 cells in a 30 row, 10 column table. The bandwidth and client-side processing could not handle this (on a Mac-- worked OK on an equivalent PC). AIR. the data was transmitted using XML. This is terrible overhead to pay (encoding, bandwidth, parsing)... especially if the data need not be [easily] human-readable.
It's taken us over a year to iron out the wrinkles of our current Flash user interface, and we have a constantly moving target as new features are added to our machines. If/When we do come up with a replacement (and we almost certainly will - so it's not really a matter of "IF"), we simply don't have enough staffing to support multiple different implementations for multiple different platforms -- it will have to be a similar "write once, run everywhere" solution.
OK, I am a long-time [mostly] satisfied Apple user and an AAPL shareholder. At the risk of doing myself harm-- it seems your problem is not write once, run everywhere",
Rather, it is write once, run at one place."
Today, you can run Flash web apps on todays latest mobile devices (including iPhone and iPad). The way you do it is to access a server (or desktop) that runs the Flash app or plugin, and serves the result to the mobile device.
You could write a server app or dedicate a few desktop Flash computers to VNC connection from the mobiles.
Maybe not the best solution, but one that will get you [most of the way to] where you want to go.
Philosophically, I am not opposed to the idea of an iPhone-only solution. Personally, the "nifty" factor alone would be worthwhile. But we're spread thin already - dedicating people to the task of writing and maintaining an iPhone-only version of the application could only come at the expense of poorer maintenance of the "everybody else" version of the application. Right now, realistically, it would take one or two customers with a well-defined need - and deep pockets - willing to pay for the additional developers we'd need to bring on to support an iPhone-compatible version of the application.
Nope. Actually, Adobe has officially published the SWF specification, and expressly said that anybody is permitted to produce their own Flash player implementation based upon it without paying Adobe a royalty or asking for Adobe's permission.
mas o menus... as others have posted, the spec is public, but is not updated in a timely fashion-- competitive players are always behind the latest features then must run like hell to catch up... or just give up.
And anybody who limited their deployment reach by distributing only for the iPhone would be shooting themselves in the foot.
I disagree! You would have a workable and reliable mobile solution on one of the most popular mobile platforms capable of running the app.
For developers in our situation, where we simply don't have the resources available to develop for multiple platforms, we have to make trade-offs. Currently, the value proposition for offering a product accessible only through Flash (to the exclusion of all mobile platforms) is much better than that of offering a product available only to iPhones (to the exclusion of all other platforms, both mobile and desktop-class).
I am still not clear to, whether HTML (not necessarily HTML5) is equal to the task or not. If you could go with a [completely] open standards solution, it would run on any capable desktop or mobile platform, No?