Adobe Flash Coming Soon to the Google Android OS

From Adobe:

Motorola announced that we've been working with them on delivering Flash Player 10.1 for the Motorola DROID. Below is a quick video showing some great content that you'll be able to access on the Droid, including the BBC, New York Times , and even some really cool animation done by the folks at AngryAlien.com
Argsays...

Aaaagh! Why does he keep calling it 'Flash ten dot one'? I was ready to forgive it as some kind of American thing in the same way that they like to say 'period' instead of 'full stop'. But then he says, 'Flash ten dot one' and, 'web two point oh' in the same sentence. Pick one way and stick to it!

Do I need help for noticing stuff like this?

dagsays...

Comment hidden because you are ignoring dag.(show it anyway)

I have one question - So much of Flash uses an "on hover" function. How is that managed on a touch screen?

Honestly I like the Adobe tools in general and Flash as a creative tool- it would be nice though, if they could make the switch and have it output to HTML 5 Canvas, instead of compiled closed binaries.

I shouldn't be against Flash- after all, it's been very good to VideoSift- but I do think the writing is on the wall that we're moving to an open standards plug-in free world.

yellowcsays...

They need to stop holding on to the Flash does video thing, it is absolutely NOT critical to internet video, not in the slightest. When it becomes easier and standard to serve up videos in multiple formats, Flash for video will be entirely irrelevant.

They should focus their energy on games, since you know, upwards of 82million FarmVille users and who knows how many else playing other crap, will care.

L0ckysays...

I agree they should focus on Flash as a wrapper for games and apps. The reason being that browsers are supporting HTML5 video more and more and the benefit of flash video will become less important.

Games and richer, less traditional UI's are something that browsers cannot do very well and won't be able to do for several years to come. Javascript is getting faster and faster but still comes nowhere near the performance of Flash and other embedded plugins for complex applications.

The other benefit of Flash (and Air) is it's ability to be deployed as a self executing application; it doesn't need to be a browser plugin. That allows rapid development of multiplatform applications using existing skills. It also provides proprietary encapsulation for those who need it; unlike Javascript.

Right now there's a fairly large disagreement going on between Adobe and Apple; the depths of which aren't well known by most users. As most people know, the iPhone (and iPad) are closed platforms that only allow vetted applications to be distributed through the App Store. This arbitrarily places Apple in the supply chain so they can take a slice of the action. This also involves developers having to pony up just to make their apps available; not even Microsoft squeezes their customers that tightly.

With this in mind it makes business sense to disallow flash in the browser as that has the potential to undermine that revenue.

What's less known is Apple's recent changes to their App Store/iTunes TOS. They are now disallowing apps that were built with third party developer tools. All apps must essentially be created directly by using their own Cocoa Touch API, and are not allowed to be developed with an abstracted framework. This has disallowed stand alone applications built with Flash (and other platforms) to be distributed through the App Store.

They actually implemented this change right after Adobe announced that they had their iPhone app wrapper up and running and would be releasing it with Flash 10.1, allowing devs to distribute standalone Flash apps on the iPhone and Android.

So why would Apple go out of it's way to prevent Flash apps (and apps built with other frameworks) in the App Store while they are allowed on Android?

As this change allows Apple to limit developers to having to work specifically with Cocoa Touch which prevents them from building multiplatform applications with the same code. As iPhone/iPad is currently a leading platform this will encourage developers to target development for them first; and then port to other platforms later. Apple are hoping that many developers won't bother porting them at all. That's quite a deep method of vendor lock in.

As someone who is starting to look at developing an app (a game, and not using Flash) for mobile I've decided not to develop for iPhone/iPad. I don't like them dictating the technology that I should use; rather than letting me choose the best tools for the job. If all other platforms will happily accept apps as the developer chose to develop it, then all the better for their users.

My hope is that with other developers feeling this way; and with the speed of development and the feature sets provided by Flash, Air, and other frameworks like the 3D game engine Unity; this will result in many more appealing applications appearing on Android and other platforms that drive customers away from Apple.

This may teach Apple that they've gotten too big for their boots and lead to them loosening their grip on developers; and in turn, their customers.

At which point developers can click a few buttons and deploy their existing apps to iPhone and iPad; welcoming their users to the 'Mobile Platform' rather than the 'Apple Platform'.

blankfistsays...

>> ^dag:

I have one question - So much of Flash uses an "on hover" function. How is that managed on a touch screen?
Honestly I like the Adobe tools in general and Flash as a creative tool- it would be nice though, if they could make the switch and have it output to HTML 5 Canvas, instead of compiled closed binaries.
I shouldn't be against Flash- after all, it's been very good to VideoSift- but I do think the writing is on the wall that we're moving to an open standards plug-in free world.


By "on hover" I take it you mean the mouse event for mouseover where the cursor is over an object. I don't think mouseovers will be necessary for Flash on touchscreens, and are things that can be ignored completely.

Most mouseover events are antiquated practices. Back in the day, everything was html hot links where the link was blue and rolling over it would change it to different color to alert the user that it was clickable. We've grown passed that, and with touchscreens there's no need for it.

Mouse events like Click and Move will be useful.

L0ckysays...

>> ^blankfist:

Most mouseover events are antiquated practices.


Mouseover is still used everywhere; it's not antiquated at all. I know what you're getting at though; most people probably would think of the cheesy rollever effects when they think of what mouseover is used for.

Check the menu at the top of this page for an example; and every link here has a :hover style to slightly change the colour. It's a fairly standard and good UI practice to give feedback.

Where mouseover is mostly used though is in combination with click. Think of any UI that uses drag and drop - it's good practice to give feedback on what you're going to drop onto and mouseover is used to trigger that feedback.

On most OS', mouseover just about any UI element and you'll get feedback

Click then mouseover is supported on most capacitive touch devices (ie drag with your finger). Some implement non selected mouseover by allowing you to touch anywhere on the screen (that doesn't react to a hold event) then move your finger around. This isn't completely intuitive though, and flash apps that use non clicked hover will likely have to be changed or suffer usability problems on a touchscreen.

blankfistsays...

There's no :hover style in Flash ActionScript.

Mouseover events are still used for web with mouse cursors. I suppose "antiquated" was a bad choice of words. However they will not serve touchscreens for UI feedback. But you're right, I didn't think of drag and drop.

Let me say it this way then: for touchscreens the rollovers generated on mouseover events most likely won't be necessary. A combination of a release event and mouse within event could be useful.

Send this Article to a Friend



Separate multiple emails with a comma (,); limit 5 recipients






Your email has been sent successfully!

Manage this Video in Your Playlists




notify when someone comments
X

This website uses cookies.

This website uses cookies to improve user experience. By using this website you consent to all cookies in accordance with our Privacy Policy.

I agree
  
Learn More