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.
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.
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 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.
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.
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!
Comments
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.
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.
.
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.
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!
.
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.
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!
.
however, I still don't believe the one line javascript bull.
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.
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!
.
Didn?t Adobe pull Premiere from Mac when Apple released Final Cut?
Just checked Adobe's site and they have Premier Pro CS5 for Mac OSX. Looks like it's still going strong.