'We have never, ever abandoned Apple,' Adobe co-founder says - Page 5

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!

.

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.

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.

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.



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.


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).

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 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.

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?



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?



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.


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!




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.


I disagree! You would have a workable and reliable mobile solution on one of the most popular mobile platforms capable of running the app.


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?

.

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.

FrameMaker was never ported to OS X.

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:




containes 740 characters of data.

These 740 characters of data, when sent to the client, with various formats resulted in adding:




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.

None of them.

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!

.

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?

They were written 8 years ago, the Flash issue arose a year later.


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!

.

No!

.

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!

.

If in fact you can read, parse, and assign in arrays an xml file in one line of javasript, this would be fantastic.

I'd love to know it.

in flash, it'd take me about 10 lines give or take depending on what you're doing with the data.

You need to retake Reading 101!

I DON'T USE XML.

iT IS OVER-USED.

.

it doesn't matter if you use xml, or something else. You still need to store the data somehow, and you need to write a routine, that reads, parses, and assigns.

granted for different applications you choose what suits you and what is quickest.

But you can't tell me you can read anything with the format you posted, parse and assign in one line.

Perhaps you have an include library and it's referencing a function or class that has, many lines.

That indeed would -appear- to be one line...

However. The data set you specified. Flash can absolutely handle it without breaking a sweat. No debate. There is NO way it'd take 60 seconds to accomplish that. Perhaps add some zeros to the number of rows and colums...

then maybe it could take that long.

I won't suggest that flash is -better- at it though.

I really hate be rude... but you zero in on something, filter it into what you understand, and then claim what you don't understand is false.

For this purpose (the one I discussed), XML sucks.

If you encode the data in a intelligent format (at less overhead than encoding XML), you get get a data-exchange packet with 13% overhead vs an XML packet with 269% overhead.

So I can transmit/receive it a lot faster, even if I get lazy and enclose it within XML bookend tags.

Then, at the client I can parse this format (within the XML bookends) and prime arrays with 1 (wait for it) 1 JavaScript command... No XML. No Flash... just efficient open standards code.

The converse is also true!

Anyone, who's ever developed (and understood) anything but Flash/XML can figure this out.

That you can't (or won't), speaks volumes!

.

Well. -I- don't mean to be rude.

But I should point out a few things here.


I have not argued that xml is the best format to store and read data. Now, you are stamping your feet about the fact you feel xml is a bad format.

WHo are you arguing about this with? Certainly not me, because I have not, and would not convince anyone, to use xml over something else that serves their purpose more efficiently. So you've conveniently turned this circus into one about the merits of xml! Did I miss something here???? Note I also, haven't argued, that flash is the best tool to use for this. In fact, if I can display this data in html, and there is no requirement that I need flash... WHY ON EARTH WOULD I USE FLASH??????

However, you've asserted it would take flash more than a full minute, to load, parse and display 60 lines of data with 30 columns.

Incorrect. It doesn't.

And, you've also, incorrectly stated that you can read, parse, and assign all vars to arrays in one line of javascript.

Bull. However, I am always interested in something I've never seen. I'd like to see it done.

I rest my case!

.

hilarious.

however, I still don't believe the one line javascript bull.

Emphasis mine.

I responded, previously, to the other part of your message, but this statement bothers me too,,,

Consider:

Lets' say Apple reverses itself and allows the Flash browser plugin and Flash-compiled apps on the iPhone...

Let's assume, that Adobe releases Mobile Flash first, for Android, later for iPhone OS-- but both within the 2nd half of 2010.

You look at all your customers and decide that you want to write once, and run everywhere.

You determine that you must write for: the smallest screen size; the slowest processor; the smallest RAM-- the lowest common denominator!

What that does, is make the customer with the worst device a first class citizen... and the customers with better devices "feeling like second class citizens"... And those with Symbian or WinMobile-- "worse, being left totally unsupported."

What's sad, is: in this rush to fairness, you are making your program mediocre.

I use a local-app/web-app combo, daily, to get instant stock market updates to my portfolio. It works great but the UI is all wrong for the Mac (or windows, for that matter). It is written in Java-- you might say: write once, run wrong [UI], everywhere.

I have missed, or screwed-up trades, because of this 1 app's unfamiliar UI. This costs me money!

So, I moved the bulk of this portfolio to a broker who has a web app with Mac browser UI... but doesn't provide instant updates. I use the Java system to get the stock prices, etc. and the Web system to execute the trades. The latter makes money off me, the former breaks even.

You explained, in a later, post that your reasons for using Flash were really: financial and support-related tradeoffs!

I agree with that reasoning!

I do not agree with the pseudo-moral, PC statement above-- it makes no sense!

.

Just checked Adobe's site and they have Premier Pro CS5 for Mac OSX. Looks like it's still going strong.