What the Flux!? The future of Flash at FOTB

What the flux?

What the flux?

I’ve been working hard on my upcoming talk at Flash on the Beach over the last few weeks, it’s actually one of the most difficult talks I’ve ever given. Trying to unravel all the trials and tribulations in our industry to come up with a some reasonable and helpful conclusions is surprisingly difficult!

As you may know, I’ve been learning and learning and learning. Unity3D, HTML5, JavaScript, iOS, and on the Flash side, AIR Android, multi-user technology, mic input and more.

This is because I love learning, but as a side effect, it really helps me to appreciate the benefits and disadvantages of one platform over another. This has been invaluable when it comes to understanding where Flash fits into the technology landscape.

In the Flash community we have a tendency to be insular, especially when our beloved technology gets such a bad rap in the press. But why is that? In order to find out what Flash looks like from the outside, I interviewed (on camera) 3 open web experts, Andy Budd, Jeremy Keith and Remy Sharp. If you’ve even got half an eye on the web community at large you may have heard of these people!

Andy Budd, Jeremy Keith and Remy Sharp

They were extremely honest and frank on their thoughts on Flash and its relevance in today’s web. Trust me, you need to hear what they’re saying.

Branden Hall, Brendan Dawes, and Jer Thorp

But it wouldn’t be very balanced research unless I spoke to respected members of the Flash community. I also interviewed Jer Thorp, Brendan Dawes and Branden Hall about the changes in Flash over the last few years, and how the emerging new tech has affected their work.

But that’s not all! I want to hear what you think too! Please fill in my questionnaire if you want your own opinions to be added to the mix. [UPDATE : Survey now closed with over 300 respondents – thank you!]

I’ll be presenting these video interviews, alongside some key web articles and tweets, and adding a sprinkling of my own thoughts at my Flash on the Beach session. It’s certainly been an eye-opening year for me, and I hope you’ll find it as interesting as I have.

How to debug AIR for Android

The requester of doom

The requester of doom

At first, it seemed like no matter what I did I’d just get the Enter IP Address or Hostname requester in my AIR app. So, to get rid of this dreaded requester once and for all follow my handy debugging AIR Android checklist!

If you’re new to Air for Android I’d recommend checking Lee Brimelow’s getting started tutorials here and here, and a couple of extra tips here on my AIR Android getting started report.

It is currently a little fiddly to get debugging, but as Air for Android is still in beta, this will hopefully become more seamless in future. But in the current build, here’s a list of things to check:

  1. Check that your phone has debugging enabled in Settings-> Application Settings -> Development -> USB Debugging
  2. Make sure that USB storage on the phone is turned on. (These two settings are required to publish your apps onto the phone)
  3. Make sure both your computer and your device are connected to the same wi-fi network. Sounds obvious I know but sometimes my phone disconnects from the wi-fi.
  4. Within the Flash CS5 AIR Android Settings in the Deployment tab check the Device Debugging radio button.
  5. In the same settings, check Install Application on the connected Android device and uncheck Launch Application on the connected Android device.

    AIR Android debug settings

  6. Enable INTERNET_PERMISSIONS in your app by adding the following to your app’s xml config file. This should be in the same folder and have the same name as your fla file, but with the suffix -app.xml. Open it in your text editor of choice and add the following XML :
        <android>
            <manifestAdditions>
                <manifest>
                    <data><![CDATA[ <uses-permission android:name="android.permission.INTERNET" /> ]]></data>
                </manifest>
            </manifestAdditions>
        </android>

    Make sure you add this to the top of the XML, not the bottom! I put it between the <copyright> and the <initialWindow> definitions:

    ...
        <copyright></copyright>
        <android>
            <manifestAdditions>
                <manifest>
                    <data><![CDATA[ <uses-permission android:name="android.permission.INTERNET" /> ]]></data>
                </manifest>
            </manifestAdditions>
        </android>
        <initialWindow>
            <content>MyApp.swf</content>
    ...

    If you put it under the <initialWindow> definitions, the AIR Android extension seems to wipe it! It took me a while to work this one out, I expect they’ll fix it in the final build. I’ve also suggested that they set this permission by default if you’re publishing a debug build, it’d kinda make sense to me. 🙂

  7. Now you’re ready to publish the file, so hit Publish in the AIR Android Settings window. Your app will compile and get copied over to your device. But it won’t automatically run.
  8. Start remote debugging in Flash CS5: select the Debug -> Begin remote debug session -> Actionscript 3.0 menu item.

    Set up a remote debugging session

  9. And now run your app. With any luck, you should see the name of your swf in the debug output window.

    Yayz! We have AIR Android debugging!

    You may still get the Enter IP Address or Hostname dialogue box but I must admit I only ever saw this if I didn’t set up the other options correctly. But if you do see it try typing the local IP address of your computer first, then the global one.

  10. So! There you have it. Let me know how you get along and if there’s anything I missed.

AIR for Android first steps

My first AIR on Android app

My first AIR on Android app

Having finished my first iPhone app in Objective C I thought it was probably time to have a go at setting up my Nexus1 with AIR for Android. Yes. I’m a digital slut. And no. I’m not gonna pick a side. Deal with it. 🙂

But anyway, I digress! I found Lee’s very cool intro to Android videos which have been a big help. But I did get a warning from Stephan Jones on Twitter who tells me that there is a virus on the site, so possibly make sure you’re running virus software first! UPDATE : Lee and Serge both assure me there’s nothing wrong with their sites so I can only assume Stephan’s virus checker was being a little overzealous!

A few things caught me out, if you navigate to the tools folder in terminal you can’t just type adb devices as the permissions on the files didn’t seem to be set right. the easy workaround is to type ./adb devices or else change the permissions with chmod if you like that sort of thing.

But the biggest thing was that it just wasn’t recognising my phone. I’m not sure if Lee mentioned it or not (maybe I wasn’t paying attention) but you need to turn on USB debugging on the phone itself. Go to Settings->Applications->Development->USB debugging. That’ll do it!

Also the link for AIR for Android wasn’t on the front page of Adobe Labs and it was surprisingly difficult to find it. But it’s here : http://labs.adobe.com/technologies/air2/android/

And finally I couldn’t actually get my app to deploy from Flash CS5 – the reason? I hadn’t turned USB Storage on – doh!

And it’s working! Lunar Lander on Android, anyone? 😉