As a content supplier, I frankly don't *care* how special the iPhone is. A "write once, run everywhere" solution is *exactly* what I'm interested in.
It allows us to cater to all our potential customers equally, offering the same experience to everybody without the headache of having to deal with multiple different development teams implementing different features using different techniques, potentially creating different sets of bugs to track and squash on different platforms.
It is counterproductive for me to single out any one group of customers to receive preferential treatment at the expense of other customers feeling like second class citizens or, worse, being left totally unsupported.
You say you are a "content supplier." Just what is that? Do you create the content? Do you own the content? Or, do you provide the means to deliver the content?
I would think that the owners and creators of content would want that content consumed by the largest potential audience.
If that is true, it is likely that the content will be delivered on several platforms, OSes and Devices.
To consume the content the user actually needs to look at it. If the content is delivered in an unfamiliar or inconsistent way, the the target user will likely move on! Not only have you missed an opportunity, you may have poisoned the well for future content.
If you want to present your content in the best manner, you will, likely go out of your way to provide it in a way that is pleasing to the consumer, rather than easy for the supplier.
For example: I can wear a T-Shirt and shorts, for a kids soccer game, a trip to Home Depot... Church, not so much... Definitely, not as best man at a friends wedding. If you want to be accepted, you kinda' have to dress and act the part that the audience expects (within limits).
Otherwise you are only building barriers to your acceptance (whatever your reasons).
When in iPhone, do as the iPhonecians do...
If you want your content to reach that targeted, highly-qualified audience!
Fortunately, Apple is more concerned about providing a great user experience to customers than to giving in to every demand from lazy developers.
Actually, it sounds more like Apple would rather someone develops only for the iPhone, rather than bothering to develope for other platforms too. Apple and Adobe are perfectly capable of working together to bring a great Flash experience to the iPhone, but Apple are simply saying they aren't interested. Apple should at least give it a chance, and it would benefit everyone if they did.
Apple isn't doing anything to stop developers from building apps for other platforms.
Adobe hasn't yet brought "a great Flash experience" to any phone. Back when the iPhone first came out Jobs said Apple looked into Flash and it didn't work. We are three years later and so far it still doesn't work.
Quote:
Originally Posted by mrochester
Actually, it sounds more like Apple would rather someone develops only for the iPhone, rather than bothering to develope for other platforms too. Apple and Adobe are perfectly capable of working together to bring a great Flash experience to the iPhone, but Apple are simply saying they aren't interested. Apple should at least give it a chance, and it would benefit everyone if they did.
Actually, it sounds more like Apple would rather someone develops only for the iPhone, rather than bothering to develope for other platforms too. Apple and Adobe are perfectly capable of working together to bring a great Flash experience to the iPhone, but Apple are simply saying they aren't interested. Apple should at least give it a chance, and it would benefit everyone if they did.
You're apparently very confused.
It's not Apple's job to write Flash for Adobe - in fact, it's unlikely Adobe would even allow them. Besides, if it were Apple's problem, why don't we have a full version of Flash for any of the non-Apple platforms? And why is it that even the beta requires far more computing power than the iPhone offers? And why is it that the beta has crashed in every public demo?
Of course Apple would rather have developers develop only for the iPhone. That's simple business. But that's not the reason why Apple doesn't have Flash on the iPhone. The biggest reason is that IT DOESN'T EXIST.
You say you are a "content supplier." Just what is that? Do you create the content? Do you own the content? Or, do you provide the means to deliver the content?
I would think that the owners and creators of content would want that content consumed by the largest potential audience.
If that is true, it is likely that the content will be delivered on several platforms, OSes and Devices.
To consume the content the user actually needs to look at it. If the content is delivered in an unfamiliar or inconsistent way, the the target user will likely move on! Not only have you missed an opportunity, you may have poisoned the well for future content.
If you want to present your content in the best manner, you will, likely go out of your way to provide it in a way that is pleasing to the consumer, rather than easy for the supplier.
For example: I can wear a T-Shirt and shorts, for a kids soccer game, a trip to Home Depot... Church, not so much... Definitely, not as best man at a friends wedding. If you want to be accepted, you kinda' have to dress and act the part that the audience expects (within limits).
Otherwise you are only building barriers to your acceptance (whatever your reasons).
When in iPhone, do as the iPhonecians do...
If you want your content to reach that targeted, highly-qualified audience!
.
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.
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.
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.
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.
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.
Quote:
Originally Posted by jragosta
You're apparently very confused.
It's not Apple's job to write Flash for Adobe - in fact, it's unlikely Adobe would even allow them.
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.
Quote:
Of course Apple would rather have developers develop only for the iPhone.
And anybody who limited their deployment reach by distributing only for the iPhone would be shooting themselves in the foot.
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).
Although it is rather odd that Apple sentiment has dropped since the iPad was released.
honestly who really cares. I bet if a graph or poll was done about microsoft on desktop OSs, for years running I bet they get their clock cleaned and rightly so.
I think it's been said, but at the end of the day, what tools and methods make the most sense for developers, will continue to be used.
I haven't ever used any Adobe product and even I know this is an outright lie. Who's he trying to fool (besides the people who already have a grudge against Apple and will believe anything any other company says)?
I find it hard to believe that you've never seen a flash piece, or read a pdf. Indirectly, you've visited a website designed using DreamWeaver, or GoLive, or read something printed that was designed with InDesign, PageMaker, Illustrator, Photoshop all of the above, and printed from a RIPPED Postscript file. If you watch TV you've surely seen things created in AfterEffects. Much if not most (at least at one point in time, and rapidly becoming that way again) was done on a Mac using Adobe products at some point in the production cycle. You may not be aware of that, but I guarantee you that is a fact.
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 :}
So:
-- 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?
Quote:
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?
Quote:
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.
I was able to easily accomplish the task within 3-5 seconds with a hidden frame and JavaScript-- it would run on any browser.
Quote:
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.
Boom!
Quote:
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.
Quote:
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.
Quote:
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.
Quote:
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?
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.
I was able to easily accomplish the task within 3-5 seconds with a hidden frame and JavaScript-- it would run on any browser.
.
this is incorrect. Flash is actually known to do this quite well. I have shoved far more data than that in much less time. I think if you check with really good developers, they will tell you the same thing. Flash was pretty dog slow with it's xml in version5 I think it was. I think it was fixed in version 6.
The thing about flash, is unfortunately, there are many bad developers out there developing really bad flash.
If reasons are there to not use flash, this, wouldn't be one of them.
Adobe purchased the company that made the best technical writing software product (FrameMaker). FrameMaker was initially and long mainly a non-Windows product.
Adobe terminated the Mac version, leaving the long standing customer base (professional writers, who had bet on Mac/FrameMaker as far back as 1990) struggling despite major protests. I'm sure many of them continue to feel the pain as they use Microsoft Word on their Macs or work with other solutions.
this is incorrect. Flash is actually known to do this quite well. I have shoved far more data than that in much less time. I think if you check with really good developers, they will tell you the same thing. Flash was pretty dog slow with it's xml in version5 I think it was. I think it was fixed in version 6.
The thing about flash, is unfortunately, there are many bad developers out there developing really bad flash.
If reasons are there to not use flash, this, wouldn't be one of them.
Actually, what i said is correct!
It was 7 years ago.
It was on a Mac!
It worked OK on an equivalent PC!
Several "really good" Flash experts who worked in the Flash Group for Adobe/MacroMedia, examined and tweaked the code. They could not improve the performance!
They suggested I use HTML/JavaScript.
I abandoned Flash because it was not a viable cross-platform solution for web development.
I was pretty well thought of as a developer (by Adobe/Macromedia) at that time-- I had recently ported
ColdFusion MX from RedHat Linux to Mac OSX (on a 333MHz iMac with 256MB RAM).
You should read the entire series, you might learn something!
All of this does not change the fact that the use of XML is gratutious if the data do not need to be read by humans. It is expensive at both the server and client (encoding and parsing), and a storage and bandwidth hog.
For example, I did an an analysis and found that the following client-side database query:
As you can see, XML was the least efficient. Also, it took time-consuming XML parsing to extract the data at the client and load it into multiple arrays. That takes 1 JavaScript command with intelligent formatting!
The coldfusion articles don't directly address the problem of flash loading an xml file.
You are talking about 31 cells in a 30 row table? This is a very small amount of data, and you are updating 31 cells?
And it took flash more than one minute to accomplish this????
Ok I really must be missing a piece of information here, because I have had flash load far more pieces of information from xml in less than 60 seconds. In less than a second actually. If that were so none of my flash systems would ever work.
As you can see, XML was the least efficient. Also, it took time-consuming XML parsing to extract the data at the client and load it into multiple arrays. That takes 1 JavaScript command with intelligent formatting!
.
can you post the one line of javascript that accomplishes this?
I've written this routine in flash many times, and I certainly cannot read, parse, and sort into arrays in one line.
Though the new AS3 XML object sees xml as arrays which is a huge improvement over AS2's way of handling xml data.
The coldfusion articles don't directly address the problem of flash loading an xml file.
They were written 8 years ago, the Flash issue arose a year later.
Quote:
You are talking about 31 cells in a 30 row table? This is a very small amount of data, and you are updating 31 cells?
And it took flash more than one minute to accomplish this????
Ok I really must be missing a piece of information here, because I have had flash load far more pieces of information from xml in less than 60 seconds. In less than a second actually. If that were so none of my flash systems would ever work.
None of them.
Sorry, I misspoke... It was 61 cells.
They were stock prices and amounts plus the total amount. Flash was used to format and transmit the data. The formatting consisted of dollar formatting and displaying the result in red or green text.
It worked fine on an equivalent PC... That was a big part of the problem: one size didn't fit all!
Comments
As a content supplier, I frankly don't *care* how special the iPhone is. A "write once, run everywhere" solution is *exactly* what I'm interested in.
Fortunately, Apple is more concerned about providing a great user experience to customers than to giving in to every demand from lazy developers.
As a content supplier, I frankly don't *care* how special the iPhone is. A "write once, run everywhere" solution is *exactly* what I'm interested in.
It allows us to cater to all our potential customers equally, offering the same experience to everybody without the headache of having to deal with multiple different development teams implementing different features using different techniques, potentially creating different sets of bugs to track and squash on different platforms.
It is counterproductive for me to single out any one group of customers to receive preferential treatment at the expense of other customers feeling like second class citizens or, worse, being left totally unsupported.
You say you are a "content supplier." Just what is that? Do you create the content? Do you own the content? Or, do you provide the means to deliver the content?
I would think that the owners and creators of content would want that content consumed by the largest potential audience.
If that is true, it is likely that the content will be delivered on several platforms, OSes and Devices.
To consume the content the user actually needs to look at it. If the content is delivered in an unfamiliar or inconsistent way, the the target user will likely move on! Not only have you missed an opportunity, you may have poisoned the well for future content.
If you want to present your content in the best manner, you will, likely go out of your way to provide it in a way that is pleasing to the consumer, rather than easy for the supplier.
For example: I can wear a T-Shirt and shorts, for a kids soccer game, a trip to Home Depot... Church, not so much... Definitely, not as best man at a friends wedding. If you want to be accepted, you kinda' have to dress and act the part that the audience expects (within limits).
Otherwise you are only building barriers to your acceptance (whatever your reasons).
When in iPhone, do as the iPhonecians do...
If you want your content to reach that targeted, highly-qualified audience!
.
Fortunately, Apple is more concerned about providing a great user experience to customers than to giving in to every demand from lazy developers.
Actually, it sounds more like Apple would rather someone develops only for the iPhone, rather than bothering to develope for other platforms too. Apple and Adobe are perfectly capable of working together to bring a great Flash experience to the iPhone, but Apple are simply saying they aren't interested. Apple should at least give it a chance, and it would benefit everyone if they did.
Adobe hasn't yet brought "a great Flash experience" to any phone. Back when the iPhone first came out Jobs said Apple looked into Flash and it didn't work. We are three years later and so far it still doesn't work.
Actually, it sounds more like Apple would rather someone develops only for the iPhone, rather than bothering to develope for other platforms too. Apple and Adobe are perfectly capable of working together to bring a great Flash experience to the iPhone, but Apple are simply saying they aren't interested. Apple should at least give it a chance, and it would benefit everyone if they did.
Actually, it sounds more like Apple would rather someone develops only for the iPhone, rather than bothering to develope for other platforms too. Apple and Adobe are perfectly capable of working together to bring a great Flash experience to the iPhone, but Apple are simply saying they aren't interested. Apple should at least give it a chance, and it would benefit everyone if they did.
You're apparently very confused.
It's not Apple's job to write Flash for Adobe - in fact, it's unlikely Adobe would even allow them. Besides, if it were Apple's problem, why don't we have a full version of Flash for any of the non-Apple platforms? And why is it that even the beta requires far more computing power than the iPhone offers? And why is it that the beta has crashed in every public demo?
Of course Apple would rather have developers develop only for the iPhone. That's simple business. But that's not the reason why Apple doesn't have Flash on the iPhone. The biggest reason is that IT DOESN'T EXIST.
You say you are a "content supplier." Just what is that? Do you create the content? Do you own the content? Or, do you provide the means to deliver the content?
I would think that the owners and creators of content would want that content consumed by the largest potential audience.
If that is true, it is likely that the content will be delivered on several platforms, OSes and Devices.
To consume the content the user actually needs to look at it. If the content is delivered in an unfamiliar or inconsistent way, the the target user will likely move on! Not only have you missed an opportunity, you may have poisoned the well for future content.
If you want to present your content in the best manner, you will, likely go out of your way to provide it in a way that is pleasing to the consumer, rather than easy for the supplier.
For example: I can wear a T-Shirt and shorts, for a kids soccer game, a trip to Home Depot... Church, not so much... Definitely, not as best man at a friends wedding. If you want to be accepted, you kinda' have to dress and act the part that the audience expects (within limits).
Otherwise you are only building barriers to your acceptance (whatever your reasons).
When in iPhone, do as the iPhonecians do...
If you want your content to reach that targeted, highly-qualified audience!
.
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.
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.
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.
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.
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.
You're apparently very confused.
It's not Apple's job to write Flash for Adobe - in fact, it's unlikely Adobe would even allow them.
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.
Of course Apple would rather have developers develop only for the iPhone.
And anybody who limited their deployment reach by distributing only for the iPhone would be shooting themselves in the foot.
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).
Looks like the public isn't as gullible as Adobe apparently thinks they are:
http://www.loopinsight.com/2010/05/1...ck-the-battle/
Although it is rather odd that Apple sentiment has dropped since the iPad was released.
honestly who really cares. I bet if a graph or poll was done about microsoft on desktop OSs, for years running I bet they get their clock cleaned and rightly so.
I think it's been said, but at the end of the day, what tools and methods make the most sense for developers, will continue to be used.
I haven't ever used any Adobe product and even I know this is an outright lie. Who's he trying to fool (besides the people who already have a grudge against Apple and will believe anything any other company says)?
I find it hard to believe that you've never seen a flash piece, or read a pdf. Indirectly, you've visited a website designed using DreamWeaver, or GoLive, or read something printed that was designed with InDesign, PageMaker, Illustrator, Photoshop all of the above, and printed from a RIPPED Postscript file. If you watch TV you've surely seen things created in AfterEffects. Much if not most (at least at one point in time, and rapidly becoming that way again) was done on a Mac using Adobe products at some point in the production cycle. You may not be aware of that, but I guarantee you that is a fact.
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 :}
So:
-- 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.
I was able to easily accomplish the task within 3-5 seconds with a hidden frame and JavaScript-- it would run on any browser.
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.
Boom!
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?
.
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.
I was able to easily accomplish the task within 3-5 seconds with a hidden frame and JavaScript-- it would run on any browser.
.
this is incorrect. Flash is actually known to do this quite well. I have shoved far more data than that in much less time. I think if you check with really good developers, they will tell you the same thing. Flash was pretty dog slow with it's xml in version5 I think it was. I think it was fixed in version 6.
The thing about flash, is unfortunately, there are many bad developers out there developing really bad flash.
If reasons are there to not use flash, this, wouldn't be one of them.
Adobe terminated the Mac version, leaving the long standing customer base (professional writers, who had bet on Mac/FrameMaker as far back as 1990) struggling despite major protests. I'm sure many of them continue to feel the pain as they use Microsoft Word on their Macs or work with other solutions.
FrameMaker was never ported to OS X.
this is incorrect. Flash is actually known to do this quite well. I have shoved far more data than that in much less time. I think if you check with really good developers, they will tell you the same thing. Flash was pretty dog slow with it's xml in version5 I think it was. I think it was fixed in version 6.
The thing about flash, is unfortunately, there are many bad developers out there developing really bad flash.
If reasons are there to not use flash, this, wouldn't be one of them.
Actually, what i said is correct!
It was 7 years ago.
It was on a Mac!
It worked OK on an equivalent PC!
Several "really good" Flash experts who worked in the Flash Group for Adobe/MacroMedia, examined and tweaked the code. They could not improve the performance!
They suggested I use HTML/JavaScript.
I abandoned Flash because it was not a viable cross-platform solution for web development.
I was pretty well thought of as a developer (by Adobe/Macromedia) at that time-- I had recently ported
ColdFusion MX from RedHat Linux to Mac OSX (on a 333MHz iMac with 256MB RAM).
http://www.adobe.com/devnet/logged_i...ll_macosx.html
http://www.oreillynet.com/pub/a/java...ion_three.html
You should read the entire series, you might learn something!
All of this does not change the fact that the use of XML is gratutious if the data do not need to be read by humans. It is expensive at both the server and client (encoding and parsing), and a storage and bandwidth hog.
For example, I did an an analysis and found that the following client-side database query:
EMP_ID LASTNAME FIRSTNAME PHONE DEPARTMENT EMAIL
1 Peterson Carolynn (612) 832-7654 Sales CPETERSON
2 Heartsdale Dave (612) 832-7201 Accounting FHEARTSDALE
3 Stewart Linda (612) 832-7478 Administration LSTEWART
4 Smith Aaron (612) 832-7201 Accountingstration ASMITH
5 Barken Peter (612) 832-7023 Engineeringation PBARKEN
6 Jennings Linda (612) 832-7026 Engineering LJENNINGS
7 Jacobson Peter (612) 832-7652 Sales PJACOBSON
8 Frankin Richard (612) 832-7672 Sales RFRANKLIN
9 Smith Jenna (612) 832-7422 Administration JSMITH
10 Manley Erica (612) 832-7657 Sales EMANLEY
11 Cabrerra Francisco (612) 832-7041 Engineering FCABRERRA
12 Leary Michelle (612) 832-7047 Engineering MLEARY
13 Branden Dominique (612) 832-7049 Accounting DBRANDEN
14 Reardon Walter (612) 832-7427 Administration WREADON
15 Barnes David (612) 832-7615 Sales DBARNES
containes 740 characters of data.
These 740 characters of data, when sent to the client, with various formats resulted in adding:
HTML Formatting........... 1,023 Characters..... Overhead..... 138%
WDDX Formatting........... 1,891 Characters..... Overhead..... 256%
XML Formatting............ 1,989 Characters..... Overhead..... 269%
Intellicent formatting....... 98 Characters..... Overhead...... 13%
As you can see, XML was the least efficient. Also, it took time-consuming XML parsing to extract the data at the client and load it into multiple arrays. That takes 1 JavaScript command with intelligent formatting!
.
You are talking about 31 cells in a 30 row table? This is a very small amount of data, and you are updating 31 cells?
And it took flash more than one minute to accomplish this????
Ok I really must be missing a piece of information here, because I have had flash load far more pieces of information from xml in less than 60 seconds. In less than a second actually. If that were so none of my flash systems would ever work.
None of them.
As you can see, XML was the least efficient. Also, it took time-consuming XML parsing to extract the data at the client and load it into multiple arrays. That takes 1 JavaScript command with intelligent formatting!
.
can you post the one line of javascript that accomplishes this?
I've written this routine in flash many times, and I certainly cannot read, parse, and sort into arrays in one line.
Though the new AS3 XML object sees xml as arrays which is a huge improvement over AS2's way of handling xml data.
can you post the one line of javascript that accomplishes this?
I've written this routine in flash many times, and I certainly cannot read, parse, and sort into arrays in one line.
Though the new AS3 XML object sees xml as arrays which is a huge improvement over AS2's way of handling xml data.
I don't recommend or use XML if I can avoid it...
That said, a "really good developer" would know the reasons why, investigate alternatives... And figure it out for himself!
.
XML is used by hundreds of thousands of developers, for a reason. If it doesn't make sense for you by all means don't use it
I'm interested in the one line of javascript that reads parses and sorts in arrays the data. Can you post this?
The coldfusion articles don't directly address the problem of flash loading an xml file.
They were written 8 years ago, the Flash issue arose a year later.
You are talking about 31 cells in a 30 row table? This is a very small amount of data, and you are updating 31 cells?
And it took flash more than one minute to accomplish this????
Ok I really must be missing a piece of information here, because I have had flash load far more pieces of information from xml in less than 60 seconds. In less than a second actually. If that were so none of my flash systems would ever work.
None of them.
Sorry, I misspoke... It was 61 cells.
They were stock prices and amounts plus the total amount. Flash was used to format and transmit the data. The formatting consisted of dollar formatting and displaying the result in red or green text.
It worked fine on an equivalent PC... That was a big part of the problem: one size didn't fit all!
.
There are a lot of good reasons to use XML. A good developer would indeed, know when to use it and not to use it.
XML is used by hundreds of thousands of developers, for a reason. If it doesn't make sense for you by all means don't use it
I'm interested in the one line of javascript that reads parses and sorts in arrays the data. Can you post this?
No!
.
I highly doubt javascript could do all of that, in one line.
that's what I thought.
I highly doubt javascript could do all of that, in one line.
Well, you're wrong... Even an average developer like me can figure it out!
.