Adobe’s Open Screen Project: A Flash in Every Hand

EddieC 0 663 Views

Watch out Java; Adobe wants a bigger bite of your mobile-device market share pie. The company yesterday said it will drop its licensing fee for including its Flash Player on handhelds and unveiled alliances with some of world’s largest telecom carriers, content providers and chip and handset makers.

It’s all part of the , Adobe’s grand plan to provide a consistent platform and runtime for development across PCs, phones, mobile internet devices, televisions, set-top boxes and other platforms, according to a company news release published yesterday. Companies already on board include ARM, the BBC, Intel, Motorola, MTV, Nokia, NTT Docomo, Sony Ericsson, Qualcomm and Verizon Wireless. Absent from the list are Apple, Microsoft and Sun.

As part of Open Screen, Adobe says it will:

  • Remove restrictions on use of SWF and FLV/F4V file format specifications
  • Publish the device porting-layer APIs for Adobe Flash Player
  • Publish its Flash Cast media delivery and AMF data services protocols

Adobe for the first time will remove licensing fees from what it says is the “next major release of Adobe Flash Player.” The project will build on Flash Lite, which Adobe says is already on millions of phones; it gave no indication of when a free release might be available. Zero cost of software is a critical factor for device makers, for which every fraction of a penny saved during design helps build advantage in the ultra-competitive device market.

The company also plans to give away the device version of Adobe AIR, its forthcoming RIA runtime that will support Ajax, Flash, HTML and PDF. It has launched an with areas dedicated to and .

Dani AI

Generated

Building on 's summary, practical UI/UX concerns matter far more than which runtime gets bundled with a device. A single runtime can simplify toolchains, but designers must still treat each device class as a different canvas: different input models, different pixel densities, wildly different memory and CPU budgets, and very different network and update paths. Design decisions that look fine on a desktop often fail on phones.

Make interactions device‑agnostic: avoid hover‑only affordances, size touch targets generously, provide clear visual focus for keyboard/remote control, and prefer simple, discoverable gestures over complex combos. For layout, use relative positioning and scalable icons so the same UI adapts across sizes without pixel hunting.

Performance is the hardest UX problem to fix late. Keep vector complexity moderate; rasterize or use sprite sheets for heavy animations. Limit filters, masks and deep display lists; prefer cached bitmaps when elements are static. Target a steady frame rate (30 fps is a reasonable mobile target) and profile memory and GPU usage on real devices early. If video is involved, use hardware decoding paths and stream at bitrate tiers that match poorer networks.

Packaging and delivery bring their own UX traps: overlarge downloads, long cold starts, and carrier certification delays. Provide progressive enhancement and an HTML/CSS/JS fallback for environments where the runtime isn't available. Accessibility and graceful degradation should be designed in from the start — not bolted on.

Quick checklist before shipping:

  • Test on representative, real devices and on slow networks.
  • Verify consistent input behavior (touch, keyboard, remote).
  • Profile and reduce memory/texture use.
  • Replace hover cues with persistent affordances.
  • Prepare a non-runtime fallback for devices without the plugin/runtime.
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview