Decoding Adobe's Big Device Push
nerdyH writes "Adobe yesterday chummed the waters around Flash and AIR as cross-platform app dev environments for mobile devices. It promised runtimes for several popular mobile OSes, including WinMo, Symbian, Palm webOS, and Android, with future RIM/Blackberry support hinted as well. Moreover, it reiterated its commitment to the Open Screen Project, an Adobe-led industry group that, if you deconstruct its name and look at its membership roster, appears tactically focused on enabling hardware acceleration of Flash/AIR on devices, as part of a larger strategy of making the runtimes ubiquitous as UI development frameworks for essentially every computer-like device with a user interface."
With HTML5's video, audio and canvas elements, there will be less and less need for Flash in the future on the web. It seems like Adobe is realizing this as well and has decided to move the focus of Flash from mere embedded objects on web pages to a way of easily creating full, rich and cross-platform applications for both PC's and phones.
This coiuld work out pretty well for them in the end. I must admit clicking a game together using Flash and publishing it to every major platform sounds more attractive than the more traditional ways of developing software, and I'm sure I'm not the only one who's thinking this.
Pretty good is actually pretty bad.
...they will learn something from squeezing Flash onto these embedded devices that can be used to help make the desktop edition less resource intensive.
What can you do with Flash that you can't do with html5?
Certain projects shouldn't fork. Sun wouldn't open up Java for the longest time, because they didn't want forks of Java, and they didn't want to repeat what they went through with Microsoft.
I propose a new license that operates on a few basic principles.
1 - You can redistribute and modify the source code.
2 - You may compile the original source code, and even compile modified versions for personal use.
3 - You may not redistribute modified binaries.
In this scenario, users can compile themselves, test, fix bugs, write patches, etc. They can submit patches upstream, but upstream still largely controls the project and prevents major forks. You would still attract community developers.
I think a license like this would work well for Flash.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
I could be wrong, but..
Unity3d.com is probably doing what Adobe plans to already, except they're using .NET. Cross-compiling code into real iPhone applications. I haven't dug too deeply into how Unity3d is doing it, but it seems pretty clear -- you can write your code in .NET with some pseudo-alternative languages like 'Boo' (python), and it makes you a nice iPhone binary that'll pass Apple's deployment criteria.
Considering Adobe has the time, money, and smarts to do it, don't be surprised when their 'Program Actionscript for the Iphone!' system is a very tightly defined API coupled with the iPhone framework that is cross-compiling..
Before I gave up on Perl, the assertion that Parrot would be some fancy answer to everyone's programming problems by allowing you to program in any language you wanted. I somewhat scoffed at the idea, but more recently as I've been working with ARM processors and doing a lot of cross-compiling work I can understand why it's an important idea that will soon be second nature to us.
If I could buy stock in Unity3D right now I would, because those guys nailed it. They just need to scale up and out of just the 3d game market.
Having hardware video acceleration seems to be one thing, but hardware acceleration of an API or bytecode seems like it could lead to chip bloat, which would make chips much more expensive to make. Shouldn't we concentrate on optimizing the software side of things? Would increasing the processor speed and battery capacity be cheaper than specialized silicon?
I must admit clicking a game together using Flash and publishing it to every major platform sounds more attractive
Slap it together and call it a day!
Never mind it doesn't take advantage of platform specific features. I'm sure users wouldn't care about THAT at all. I'm sure your sales will be just fine...
Sometimes easier things are just easier, not better.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
...and Adobe claimed they would have flash on Android this Fall.
October is here. Now they say next year.
I am not hopeful that they can get flash on Android. Possibly they are waiting for better devices so they don't have to shoehorn it into the G1, which could use more RAM, but it is what it is.
In fact, I predict, no Flash for the G1 ever. And many of the other platforms as well. Adoby wants to FUD the developers and keep HTML5 on the shelf as long as possible, since stuff like Canvas will pretty much eat their lunch and dinner if they don't watch out.
deleting the extra space after periods so i can stay relevant, yeah.
Adobe is saying that the new 10.1 version will fully offload h264 decoding to the GPU. If that works as advertised, then it would solve lot of problems involving full screen video playback on websites like hulu and youtube.
h264 decoding is not the problem. In fact, 80% CPU usage when playing back a simple video is probably the -best- case scenario for Flash on Mac, since there's not very much Flash actually going on. Try some games from armorgames.com and compare your framerates to a similarly spec'd Windows box. On my 2006 MBP, many of those games are simply unplayable due to slide-show level framerates (10fps). The CPU, of course, is pegged at 100% no matter what the application.
I have to install Flash blockers in my browser because sometimes I like to surf the web while on battery, hahaha. Flash alone cuts my battery life in half.
Face it, Mac Flash performance is like every other poorly, hastily executed Mac port: shit poor. I saw an Adobe developer claim on someone's forums they knew what the problem was, but just didn't have the "resources" or corporate will to fix it.