You are currently browsing archived articles from

AIR for Android

Thursday, May 13th, 2010

As you may be aware, Adobe currently has a private beta of AIR for the Android Operating System.

Although still in it’s early stages, the core platform is quite stable and support from the AIR engineering team has been very good while the pre-release forums have also been quite active with lots of useful information being shared daily. In just a little under an hour I was able to have two POCs demonstrating the Accelerometer and MultiTouch Gesture capabilities running flawlessly on my Droid. Additionally, I was also able to develop a very basic Geolocation prototype in next to no time at all which accurately conveyed latitude / longitude, altitude and even speed. In the time since I have been focusing on real world applications and the results have been excellent for such early stages of the platform.

Some notable features I have been working with are: GPS, Accelerometer, Multitouch / Gestures, SMS/TEL URI Schemes, IME, S/W Keyboard, Screen Orientation, Screen Dimming, Menu/Back keys and more.

As the pre-release and my applications built on AIR for Android progress I will share my findings as well as provide open source APIs, code examples, videos and / or screen shots of the apps I am working on, so stay tuned for more information.

The Flash Platform and Android

Thursday, April 22nd, 2010

Rather than going into any detail regarding my thoughts surrounding Apple’s updated iPhone developer license clause last week, I instead prefer to focus on the more exciting and positive developments the future has to hold for the Flash Platform in the mobile space; and at the moment, it’s Android

As you may be aware, beginning with Adobe Flash Player 10.1, the AIR 2.5 for Android SDK and Android, the Flash Platform will now begin to close the gap in terms of developing and deploying Web, Desktop and Mobile applications. Thus it appears this could open up some very exciting possibilities in the RIA space as, a write-once, deploy-anywhere solution for Mobile, Web and Desktop applications is obviously highly desirable.

For those of you unfamiliar with Android, it is a premiere software stack for mobile devices which provides an Operating System built on the Linux kernal, a very well designed middleware layer and core applications including an E-mail client, SMS program, calendar, maps, browser, contacts and more. Android also provides an Application framework, a Dalvik virtual machine which is optimized for Mobile Devices, an integrated web browser based on the widely known WebKit engine, SQLite storage, common Media support, hardware dependent Bluetooth, EDGE, 3G, WiFi, Camera, GPS, Compass, and Accelerometer support as well as many other features.

Originally developed by Android Inc., which was later acquired by Google, Android is now governed by the Open Handset Alliance; a consortium devoted to advancing open standards for mobile devices. Currently, over 50 mobile phones are expected to come shipped with Android in 2010. Moreover, Google and their hardware partners are now shipping 60,000 Android handset units each day! If this trend continues (which it certainly appears will be the case) this equates to over 21.9 million devices shipping with Android per year.

Traditionally, getting started with Android has been quite simple for developers who have experience with Java as one need only download and unpack the Android SDK distribution and install the Android Development Tools (ADT) Eclipse plugin. Managing different Android platforms as well as other SDK components is accomplished via AVD Manager which come with the SDK. As expected, the Android SDK also comes with a very high quality device emulator which feels similar to the BlackBerry JDEs device Simulators.

While developing applications for Android with ADT is certainly convenient (and quite fun), from a Flash Platform development perspective it is much more desirable (as well as economical) for developers to leverage their existing skill-set and APIs to develop a single application targeting Flash Player or the AIR runtime that will work with any device shipped with Android. And with Flash Player 10.1 and the current private beta of Android AIR 2.0, the Flash Platforms reach will now include the Android platform. The most significant of these new possibilities is the ability to develop a single application which supports both Web and Mobile devices alike. Thus considerably simplifying the development and deployment process. Of particular interest is the ability to leverage Mobile Device specific features such as Accelerometer, GPS, multi-touch, gestures screen orientation etc. from an AIR application.

Flash Player 10.1 will support devices running on Android that meet the minimum software and hardware requirements, which at the moment appear to be devices with an ARM v7 (Cortex) processor. Both Droid and Nexus One carry ARM v7. Architecturally, I am quite interested in seeing how this all comes together in terms of memory and cpu optimization.

Working in conjunction with Adobe, as part of the Open Screen Project, Motorola is helping to develop Flash Player 10.1 so it works on Android. Motorola will also be deploying the Flash Player broadly across its Android product portfolio going forward; releasing Flash Player updates for existing devices such as the Droid (which I happen be actively developing for).

Adobe is targeting the end of July 2010 to have the Android AIR 2.0 Beta and Flash 10.1 for Android available. For updates sign up for:

  • Adobe Flash Player 10.1 Beta for Android Notification
  • Adobe AIR 2.0 Beta Android Notification
  • Data Binding with AS3 Signals

    Monday, March 22nd, 2010

    Over the past few years the Presentation Model Pattern has picked up a lot of traction in the Flex world as it allows for an abstracted representation of a views model and state which can easily be tested. Core to it’s implementation is the facilitation of data bindings between a PMs model and a corresponding View’s controls. Implementing data bindings between a view and its associated PM is quite straightforward when leveraging data binding in Flex – simply annotate a property, getter or class with [Bindable] metadata. A basic example of which can be seen as follows:

    Then a typical Flex data binding expression can be defined within a particular property of a control where the binding is to take place against the property of the Presentation Model instance:

    As you can see this is quite simple and easy to implement. But how does one accomplish this without the use of Flex’s native data binding facility?

    This may seem like a rather moot question as its hard to imagine why someone would choose to not take advantage of Flex data binding to accomplish synchronizing a view with its PM. However, just recently I found myself in need of a solution for this problem…

    I have been experimenting with AS3 Signals lately as I find them to be a nice alternative to Flash Player Events. This especially makes sense in the context of Presentation Models as, at least in my experience, event Bubbling within the display list simply isn’t necessary when binding a component to a property of a PM. Furthermore, while I am not particularly biased against Flash Players event model, its implementation is very much a black-box, and AS3 Signals allows for a good level of abstraction and control of the Signaling mechanism. So I contemplated how this may improve a Presentation Models implementation and decided to see how Signals could be implemented with a PM; however I first needed to find a solution which would allow Signals to provide the same functionality as data binding.

    Essentially, implementing “pseudo” data bindings with AS3 Signals can be accomplished much the same as can be seen in BindingUtils. I developed a SignalDataBinding API which will feel somewhat familiar to those who have worked with BindingUtils in the past. SignalDataBinding provides an API allowing for the creation of pseudo data bindings within a Signal against a property of a host object which is facilitated via the creation of runtime functions which are managed by the API.

    For example, suppose you are using AS3Signals and wanted to bind a label’s text property to the value of another object. With the SignalDataBinding API this could be accomplished as follows:

    Then, in the view from which the bindings are to be defined you would explicitly add bindings as follows:

    And that’s basically it. Additional levels of abstraction could easily be defined in order to provide common base classes which encapsulate the SignalDataBinding instance etc. Additionally, I do not see any reason why the SignalDataBinding API could not be utilized in AS3 projects as well as Flash projects; for the underlying implementation has no dependencies on the Flex Framework. Thus the SignalDataBinding API could be leveraged in any AS3 project as is, or adapted to implement the Flash Player Event model to provide a BindingUtils implementation for AS3 and / or Flash Projects.

    You can view a basic example as well as download the SignalDataBinding API source, docs and binary.

    Some Useful Tips to Keep in Mind

    Sunday, February 28th, 2010

    Throughout my career I have always been drawn to books which provide a practical way of thinking about software. Books of this nature tend to have an emphasis on fundamental principles which apply to all software engineering disciplines, and form much of the basis of the Agile methodologies many of us have come to appreciate.

    Often, I find myself going back to the seminal text; The Pragmatic Programmer as, it provides a great resource for some important things I like to keep in mind from day to day. And so, I just wanted to take a moment to share some of the best tips from the book which I have found to be particularly useful and inspiring.

    Care About Your Craft

    Why spend your life developing software unless you care about doing it well?

    Provide Options, Don’t Make Lame Excuses

    Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.

    Critically Analyze What You Read and Hear

    Don’t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.

    Design with Contracts

    Use contracts to document and verify that code does no more and no less than it claims to do.

    Refactor Early, Refactor Often

    Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.

    Costly Tools Don’t Produce Better Designs

    Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits.

    Start When You’re Ready

    You’ve been building experience all your life. Don’t ignore niggling doubts.

    Don’t Be a Slave to Formal Methods

    Don’t blindly adopt any technique without putting it into the context of your development practices and capabilities.

    It’s Both What You Say and the Way You Say It

    There’s no point in having great ideas if you don’t communicate them effectively.

    You Can’t Write Perfect Software

    Software can’t be perfect. Protect your code and users from the inevitable errors.

    Build Documentation In, Don’t Bolt It On

    Documentation created separately from code is less likely to be correct and up to date.

    Put Abstractions in Code, Details in Metadata

    Program for the general case, and put the specifics outside the compiled code base.

    Work with a User to Think Like a User

    It’s the best way to gain insight into how the system will really be used.

    Program Close to the Problem Domain

    Design and code in your user’s language.

    Use a Project Glossary

    Create and maintain a single source of all the specific terms and vocabulary for a project.

    Be a Catalyst for Change

    You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.

    DRY – Don’t Repeat Yourself

    Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

    Eliminate Effects Between Unrelated Things

    Design components that are self-contained, independent, and have a single, well-defined purpose.

    Iterate the Schedule with the Code

    Use experience you gain as you implement to refine the project time scales.

    Use the Power of Command Shells

    Use the shell when graphical user interfaces don’t cut it.

    Don’t Panic When Debugging

    Take a deep breath and THINK! about what could be causing the bug.

    Don’t Assume It – Prove It

    Prove your assumptions in the actual environment—with real data and boundary conditions.

    Write Code That Writes Code

    Code generators increase your productivity and help avoid duplication.

    Test Your Software, or Your Users Will

    Test ruthlessly. Don’t make your users find bugs for you.

    Don’t Gather Requirements—Dig for Them

    Requirements rarely lie on the surface. They’re buried deep beneath layers of assumptions, misconceptions, and politics.

    Abstractions Live Longer than Details

    Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.

    Don’t Think Outside the Box—Find the Box

    When faced with an impossible problem, identify the real constraints. Ask yourself: “Does it have to be done this way? Does it have to be done at all?”;

    Some Things Are Better Done than Described

    Don’t fall into the specification spiral—at some point you need to start coding.

    Don’t Use Manual Procedures

    A shell script or batch file will execute the same instructions, in the same order, time after time.

    Test State Coverage, Not Code Coverage

    Identify and test significant program states. Just testing lines of code isn’t enough.

    Gently Exceed Your Users’ Expectations

    Come to understand your users’ expectations, then deliver just that little bit more.

    Don’t Live with Broken Windows

    Fix bad designs, wrong decisions, and poor code when you see them.

    Remember the Big Picture

    Don’t get so engrossed in the details that you forget to check what’s happening around you.

    Make It Easy to Reuse

    If it’s easy to reuse, people will. Create an environment that supports reuse.

    There Are No Final Decisions

    No decision is cast in stone. Instead, consider each as being written in the sand at the beach, and plan for change.

    Estimate to Avoid Surprises

    Estimate before you start. You’ll spot potential problems up front.

    Use a Single Editor Well

    The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.

    Fix the Problem, Not the Blame

    It doesn’t really matter whether the bug is your fault or someone else’s—it is still your problem, and it still needs to be fixed.

    “select” Isn’t Broken

    It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.

    Learn a Text Manipulation Language

    You spend a large part of each day working with text. Why not have the computer do some of it for you?

    Use Exceptions for Exceptional Problems

    Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. Reserve exceptions for exceptional things.

    Minimize Coupling Between Modules

    Avoid coupling by writing shy” code and applying the Law of Demeter.

    Design Using Services

    Design in terms of services: independent, concurrent objects behind well-defined, consistent interfaces.

    Don’t Program by Coincidence

    Rely only on reliable things. Beware of accidental complexity, and don’t confuse a happy coincidence with a purposeful plan.

    Organize Teams Around Functionality

    Don’t separate designers from coders, testers from data modelers. Build teams the way you build code.

    Test Early. Test Often. Test Automatically.

    Tests that run with every build are much more effective than test plans that sit on a shelf.

    Find Bugs Once

    Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.

    Sign Your Work

    Craftsmen of an earlier age were proud to sign their work. You should be, too.

    It is my hope that you will find some of these tips helpful and, if so, I suggest keeping those which resonate with you (as well as some of your own) someplace visible for reference.

    Metadata API update for Flex 4

    Saturday, January 30th, 2010

    Back in September 2008 I published a post on Class Annotations in Flex, through which I provided an API allowing for a unified approach for working with AS3 metadata. Just recently I intended to use the Metadata API in a Flex 4 project when I noticed it no longer seemed to work as expected. After a bit of debugging, I realized the bug appeared to be related to changes in the result returned from describeType; specifically, the addition of the “__go_to_definition_help” metadata. Considering the Metadata API leverages describeType in order to introspect metadata definitions, this made sense.

    I made some simple modifications to the API to work with the new metadata returned from describeType and this resolved the issue. While I was in the process I also refactored operations to return Vectors as opposed to ArrayCollections, as was the case in the original design; effectively optimizing the API for Flex 4 (as well as Flex SDK 3.4).

    You can download the source/tests/swc/docs dist here; all of which will be available soon via SVN and a public Maven repository, more on that once it’s ready.