Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
SJ's note about Flash was about running it on iOS, not on Android. Nothing for iOS has changed. Just sayin'.

Well, it's the number one reason why most Apple fans dislike Flash and care about news like this. So as an answer to the question that was put forth, my post was relevant.
 
This will be problematic for companies like the BBC reliant on Flash for their products.

We're not going to see the death of flash any time soon. There's no real alternative to it for protected video streaming (other than Silverlight, which is just Microsoft's version of Flash, so hardly different in concept - closed-source browser plugin.).

Flash is definitely dead on mobile platforms with Adobe no longer supporting Flash on Android going forward. Flash on the desktop may be around for a little while longer but why should web developers support both? I think you are wrong in your assertion. The BBC will be forced to abandon Flash once hundreds of millions of iOS and Android users can no longer see their content. The future lies with the mobile platforms, not desktops.
 
The BBC annoy you because your Flash blocker is blocking their Flash content? :cool:

More of the fact that they use it to begin with haha! Though when I originally typed that post I was thinking 'I bet someone will say that I'm whining about my flashblocker doing it's job' :p

I would have just expected the BBC to use something a little nicer, that's all :) :apple:
 
It's the lack of support for HTTP Live Streaming (in Android 2.x) that is the problem.

Apple makes using HTTP Live Streaming mandatory for video streaming in Apps, which is quite the opposite of what they've done with Android.

Android 2.x is 3 years old. It's supported on Android 3.x (out of the box) and above.

It is actually possible to get it on 2.x but the software developer has to license vitamio which is bundled in the apk. There are a number of other ways it can be done as well as there are/were a number of local network streaming apps over upnp.

Either way, it's a mute point as android 3.x and above fully supports it. Obviously there will be a transition period but theres nothing to stop there being a check in apps to see if the OS is 2.x or lower and then use flash instead of an mp4 stream.
 
I don't know why its so hard to understand: nobody is loyal to flash. We just want to be able to watch flash videos or view websites that use flash. If the technology changes or improves, so be it. Just make sure my device is compatible with the new standard.
 
Android 2.x is 3 years old. It's supported on Android 3.x (out of the box) and above.

It is actually possible to get it on 2.x but the software developer has to license vitamio which is bundled in the apk. There are a number of other ways it can be done as well as there are/were a number of local network streaming apps over upnp.

Either way, it's a mute point as android 3.x and above fully supports it. Obviously there will be a transition period but theres nothing to stop there being a check in apps to see if the OS is 2.x or lower and then use flash instead of an mp4 stream.

Except 90% of Android users are still on 2.x, including many devices on sale now. :)
 
It's a terrible example, because it is being rewritten in favor of native code, and it was running without the benefit of Apple's Nitro javascript engine.

(And saying that Flash is "certainly faster than HTML5" is just silly without context. There are plenty of obvious situations where HTML5 is going to be more efficient.)

Fair point about Nitro; I forgot that Apple locks that out of the developer Safari window. But as I've said, I've run resource-intensive HTML5 apps in mobile Safari, and it's just as slow. "Nitro" can't improve that HTML5's poor speed at animations.

And please name these obvious situations where HTML5 is more efficient than Flash. I'm not aware of any. The current version of Flash (11.3) is pretty efficient.
 
Fair point about Nitro; I forgot that Apple locks that out of the developer Safari window. But as I've said, I've run resource-intensive HTML5 apps in mobile Safari, and it's just as slow.

Why would it be just as slow if it uses a faster javascript engine? Are you creating resource intensive html5 apps without using javascript?

"Nitro" can't improve that HTML5's poor speed at animations.

Of course it can! Javascript is the primary method of creating animations in html5.

And please name these obvious situations where HTML5 is more efficient than Flash. I'm not aware of any. The current version of Flash (11.3) is pretty efficient.

Playing video.
Displaying text.

Those are the obvious examples. Like I said, it depends on what you are doing as to which method is more efficient.

But we've gotten off the point here. Obviously, Flash is more efficient than HTML5 in a lot of situations. Particularly complex animations. My point was that you simply chose a really poor example.
 
It's okay. Mobile OS is near its end. The beginning of PC/maybe Mac quality for tablets is beginning. Companies are starting to go with Intel over slow ARM and a real operating system such as Windows 8. In the future, it's going to be Intel-equipped hardwares for all tablets. So, we'll probably see professional OS such as OSX and Windows 8 being the main platform, ala Macs and PC, but for tablet form factor. No more phone OS!:eek:
 
It's okay. Mobile OS is near its end. The beginning of PC/maybe Mac quality for tablets is beginning. Companies are starting to go with Intel over slow ARM and a real operating system such as Windows 8. In the future, it's going to be Intel-equipped hardwares for all tablets. So, we'll probably see professional OS such as OSX and Windows 8 being the main platform, ala Macs and PC, but for tablet form factor. No more phone OS!:eek:

Because if there is one thing that the last decade has proven, it's that people want the same interface on their mobile devices that they have on their desktop. :rolleyes:
 
SSLv2, SSLv3 and TLSv1 disagree. Open standards are completely open. But that doesn't mean that if you fail to properly implement them, they will still work.

They don't work on the same principles.

With TLS, you're saying:

Bob wants to send Alice a piece of information securely, but they don't want Joe to be able to intercept it.

With Video Streaming, you're saying:

Bob (Netflix) wants to send Alice a movie, but only wants her to do a few things with it.

It's a completely different type of scenario. With TLS, the untrusted party is some stranger in the middle up to no good. With Video, the customer is the untrusted party.

This is ultimately the downfall of most DRM schemes - you have to give the user some level of access to the system. At least with something closed source it has to be reverse engineered.

In an "open" DRM scheme, you'd have a scenario where anyone could simply implement a client that ignores all of the rules.

----------

Except 90% of Android users are still on 2.x, including many devices on sale now. :)

My point exactly.

I don't usually go for the "ZOMG it's fragmented" line, but this is one scenario where it actually makes sense.
 
This will be problematic for companies like the BBC reliant on Flash for their products.

We're not going to see the death of flash any time soon. There's no real alternative to it for protected video streaming (other than Silverlight, which is just Microsoft's version of Flash, so hardly different in concept - closed-source browser plugin.).

Then they would have to wake up and learn alternatives: tagesschau.de - the Federal German news station's news show (of the ARD) has all its news content available in other ways as well. See the iPhone and iPad Apps - which in my eyes are by far the best German news source.
 
appleflash.jpg


:D
 
We're not going to see the death of flash any time soon. There's no real alternative to it for protected video streaming

In what way is Flash video "protected?" There's really no such thing. The video content is there regardless of the delivery method. Flash, just like anything else, obfuscates the location of that content, but then, you can do that with any delivery method, including HTML5.
 
Its fear mostly. They believe they will run out of battery at any time. Goes back to times when batteries where not as efficient. What is funny is all those people with phones that can switch out batteries is that they never do.:rolleyes:

You know whats funny - I have co-workers that got Androids just because they can replace the battery .... but they still run around the office looking for someone with a compatible charger because they were to cheap to buy a second battery (or 'forgot' the battery at home).

Glad my iPhone battery lasts all day (well, during the hours that I am awake) and that I don't have to carry a second battery with me all the time.
 
In what way is Flash video "protected?" There's really no such thing. The video content is there regardless of the delivery method. Flash, just like anything else, obfuscates the location of that content, but then, you can do that with any delivery method, including HTML5.

Flash provides the option to wrap the video in DRM.
 
In what way is Flash video "protected?" There's really no such thing. The video content is there regardless of the delivery method. Flash, just like anything else, obfuscates the location of that content, but then, you can do that with any delivery method, including HTML5.


Flash provides the option to wrap the video in DRM.

Indeed.

I mentioned earlier that most DRM systems fail because current approaches to security are not designed to cope with this scenario.

While these systems are not 100% secure, the content providers want them to be used. Until that changes, you'll need a proprietary system of some sort -whether it's Flash, Silverlight, an App or something else.

I take the view that the proprietary system should be as widely accessible as it possibly can be, and right now Flash is the best fit for that.
 
You people have no idea what you are talking about... Adobe Flash Player for mobile was completely useless from the very beginning since no Flash content was optimized for mobile. Yes, you could load Flash content in the browser but it was far from usable...

Adobe is now focusing on Adobe Air to create applications / games that can be easily packed for both iOS and Android ( stuff that has been around for quite a while but of course the ignorant hordes know nothing about the apps / games they've been using all this time ). The apps written in ActionScript 3.0 and wrapped for iOS or Android are of course not be as fast as well optimized native apps, but they can get close enough to native speed in the hands of an experienced programmer.

99% of you people really have no idea what you're talking about... You've just bough the cheap Apple propaganda like blind slaves. Flash is far from perfect, but it's also far from being as crappy as many of you blind slaves want to make it seem it is.

Seriously, S.T.F.U. if you think Flash is only about the banners you see on the P0RN sites you visit on a daily basis!
 
I've never heard of a job title called "web guy" but the job title "front-end developer" is very frequent.
Using Perl, the read-only language, for rendering web pages sounds like a nightmare. Who did that to you?
Wow. Have you ever read slashdot? You know, that site that brings down other sites? Guess what? They generate their pages in.... perl.

Back in the day, when PHP was even worse than it is now and before .NET even existed, I wrote a set of parsing/rendering routines which read in HTML file snippets and populated embedded symbols/tags with controls rendered with perl functions. Some of those functions contained drop down lists with values pulled from lookup tables in a database.

I essentially, re-implemented what PHP was trying to do in Perl. You would hit the PHP CGI script with parameter and I would return the appropriate webparts with the controls populated through macro substitution/evaluation.

To the end user, it looked like static webpages but it was dynamic. I even had an in memory session/user state and I tied that back into a shopping cart. The sessions had an expiry timer on them which reset based on user activity or were destroyed if the user was inactive too long. Sessions were tied to a combination of the encrypted username and random GUID parameters.

It was sort of like what you could do with JSP or ASP.NET.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.