HTML and CSS Reference
In-Depth Information
Figure 2-3. Showcasing the projected Flash Player penetration rate in smartphones (Credit: Adobe)
Adobe, which had huge ambition for Flash support on mobile devices, felt that with the huge backing in the Android
and Blackberry market, Apple would eventually give in to supporting Flash on iOS; for some time, that wasn't something
to giggle over. Apple, it was said, actually gave Adobe a chance to prove that the mobile Flash Player could be performant
on their phones and not overly tax the user's device in such a way that it would eat up battery life and ultimately crash the
application. Whether this happened or not is unknown to me, but Adobe's take is much different on this matter.
This is where the politics behind the age-old HTML5 vs. Flash business comes into play. Hopefully, with the
information outlined thus far, you can draw your own educated conclusion. That said, in late 2011 Adobe released
a public statement that they company would finally sunset the Flash Player on mobile and focus efforts on web
standards leveraging HTML5. This caused many repercussions. For starters, Adobe's faithful developer community
felt betrayed and backstabbed; they thought their future on mobile was murdered. Also, many in the industry saw
this as Adobe's white flag of surrender to Apple. If you look at the business decisions around it, however, Adobe took
an altogether different approach for the company. Adobe also stated that it would continue to support native mobile
applications built on Adobe's Integrated Runtime (AIR).
at a high level, adobe air is essentially a framework that leverages a code base and structure very similar to
what is used in the flash player. With air, developers can build native applications on desktop and mobile devices using
the same practices they did building rich internet applications with flash player. in fact, at the time of writing, adobe air
is on its 3.2 release and continues to be supported in many distribution channels, including desktop, mobile, and tv.
With air's approach to building native applications, when a developer's application gets compiled, it is actually
rewriting the code from native actionscript into native objective-C or Java for the ios and android operating systems.
this means that the air compiler and packager will actually write everything to the assembly of the device, which is
extremely low-level code, lower than the apis available to ios or android developers building for native applications.
it's damn close to machine code! 1's and 0's, my friend; that's all.
Search WWH ::

Custom Search