litl SDK Available, Developers get webbook for $199
At FlashAndTheCity, we officially launched our Developer Center at http://developer.litl.com. You can now sign up for the SDK, which is in private beta. To date, we’ve approved 75% of developer signups based on Flash experience, and more importantly, ideas for channels developers want to build. The latter is important to ensure we dedicate support early on to those developers most interested in building compelling channels for our users.
We have decided that while coding with the AIR-based Simulator included with the SDK package is sufficient, having a webbook to test and play with is much more fun. Upon signing up for the SDK, developers can get a litl webbook (plus FREE remote) for a subsidized/discounted price of $199.
Visit http://developer.litl.com to sign up, learn more, get your discounted webbook and start building fun channels for our users.
Twitter making its own apps concerns developers
My HTC Intredible shipped with a Twitter app built-in called Peep. It was cool, but lacked some polish I enjoy with Seesmic’s Twhirl AIR app on my desktop. Being new to Android, I didn’t realize that features like taskbar notifications were available to other apps — so I was really impressed when I saw a little ‘birdie’ icon whenever someone replied/dm’d/or included me in their tweet.
Days after I got my Incredible, I learned that Twitter, themselves, had launched their own Android app. I downloaded and fell in love. Not only did it beat Peep in terms of usability, navigation and ‘Android’ integration, it also surpasses Twhirl. It’s got me wondering now, when will Twitter put out its own desktop-integrated app (not counting the web site) as an alternative to existing 3rd party apps. And if they do, what will the makers of Twhirl, Tweetdeck and many others have to say about it.
Turns out, Twitter is already fostering some bad blood among its own developer community. Up until now, I think developers integrating Twitter APIs felt they had the franchise on building 3rd party, OS/Desktop/Mobile integrated apps. To see the service company now build/acquire apps and offer them as their own is sending the wrong message to developers. It says, “we appreciate you doing what you did and helping grow our user base to millions. Now let us take it from here…”. This is a dangerous message for a service providing company with an abundant platform like Twitter to send.
Members of the developer community have been voicing their opinions starting around Twitter’s developer event “Chirp” (see
“Tensions Rise for Twitter and App Developers” and “Why is Twitter suddenly making its own apps?“) and you can see there’s something interesting brewing here. I’m interested to see how this pans out. While the ‘mashup’ scene has all but faded over the past few years, building apps around 3rd party APIs remains hot. Other companies who have no intention to compete with their developers, as Twitter seems to be doing, will need to make it super clear to avoid potentially negative comparison.
AIR mobile and the mystery that awaits us!
I started writing a lengthy comment in response to brother Kevin Suttle’s very concise and well-written celebration post on the announcement of AIR for Android and Mobile. Please read that first here: http://kevinsuttle.com/2010/02/15/air-mobile-will-spark-the-era-of-contextual-applications/
In response to that post and many other announcements today, I have a lot of thoughts and questions I’d like to air out post. Before I get into this, I feel the need to state now that I love AIR. I’ve loved building AIR apps, coding with both CS4 and FlashBuilder. I am thrilled that Adobe is pushing this further into the mobile realm and hope the adoption skyrockets! I think it is the future of the Flash platform.
And now, some of my thoughts/questions and issues:
A. Aside from the use of a common language and platform in Flash, how can/will building AIR mobile apps be a unified advantage over building native apps on the device? As Ryan Stewart noted, “Depending on the device, you may want to make some small modifications, but you’ll be able to reuse your assets and a bulk of the code to quickly create cross-platform mobile applications with AIR mobile.” As we know some of the pave-over pitfalls of building AIR apps across Mac and Windows, there are some conditionals required to handle things like docking and alerts. My hope is that Adobe can continue to offer more seamless pave-over/common solutions that will let us tap into unique device platform features with a unified code approach.
B. It’s hard for me to envision how the same windowing, alert and docking functionality I’ve implemented in a desktop-based AIR app will appear/function on a mobile platform and smaller screen size. Assuming the mobile device/platform implementation of AIR supports this, will they work in a familiar way so the user knows how to handle them? Example: Twhirl. On Android, will the identical AIR app (if supported verbatim) actually load multiple windows for each of my Twitter accounts and lists? Will the app’s taskbar/docked icon (or mobile equivalent, if there is one) blink or bounce when I have a new tweet? Will a notification window popup over whatever app I’m using (or if/when I’m on a phone call) with new tweets? Hard stuff to imagine, but very exciting possibilities.
C. How will the AIR API proxy unique device functionalities like GPS, Accelerometer, orientation (landscape/portrait), touch/mult-touch, etc? Will we see separate classes for each, or something similar to the Flash Lite implementation of System.Capabilities.hasStylus? Furthermore, if I write such functionality into an app, will AIR ignore or intercept such calls if the same app is installed on a device without that functionality?
D. Most important (to me, anyway) of all, is the issue of distribution. There was an exchange earlier today between Ted and Scott about distribution and monetization. If AIR-built apps are to be listed in respective ‘app’ stores on different device platforms, will that require the developer to build/package the app for each device they wish to distribute too? Will there be a unified certificate or similar approach to protect source and assets from onedevice/store/platform to the next?
I’ve got more questions, but I’ll leave that for another post. Forgive me as I know the announcement is super fresh, and I’m sure many of these questions will be answered soon. My excitement has me desiring many answers and discussion now. If you have any thoughts or answers, similar or on other aspects, please post them and let’s get a dialogue going here. (Feel free to direct responses/comments to brother Kevin Suttle’s post.)
Flex Example: Populating Value Objects with web service XML
I am working on a little AIR application that stores data both locally (SQLlite) and on a web service (PHP/MySQL) that I’m building in parallel. When the app starts, it requests initial data to populate a pair of DataGrids in the AIR app. I’m sending a URLRequest against a URLLoader with simple params and getting back XML. I am then looping through the items in the returned XML and adding them to an ArrayColletion that acts as the data provider for each DataGrid in the UI.
To bridge the data, I’m storing each item in a value object, so it is easier to reference the item’s properties when viewing and modifying data chosen (and moved around) in the DataGrid. I’m using a nifty trick which seems to be working great for mapping the XML child’s value right to the value object property. Take a look and see if this works for you:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | private function resultHandler(e:Event):void { var resultXML:XML = XML(e.target.data); var items:ArrayCollection = new ArrayCollection(); var item:itemVO; // Convert XML to ArrayCollection for each(var itemXML:XML in resultXML.item){ item = new itemsVO(); for each (var itemProp:XML in itemXML.children()) { //Use XML node name to reference matching property in value object item[itemProp.name()] = itemProp; } items.addItem(item); } } |
Of course, this only works if you create properties in your value object that match the xml nodes you are returned (or that are being returned) from the web service’s XML.
Presenting to a packed house at FOTB
I’ve heard rumors that over a hundred were turned away from my session today at FOTB. I’m happy to say that my debut presentation at Flash on the Beach was super fun and very successful. The stereo microphone demonstrations were flawless. All in all, the questions and audience participation were the best I’ve ever experienced. Tons of positive feedback!
Presenting at FOTB Brighton from Chuck Freedman on Vimeo.
Even after I was done, nearly 20 folks lined up to meet me, ask deeper questions and talk some more on stereo microphone usage and ideas. Thankfully, I had a bunch of Ribbit shirts and Moleskins to give away.
I also noticed a bunch of very respected community members in the audience. To a speaker at any level, it’s always great to see other fellow speakers interested in what you’re doing.
In light of the fact that so many people had to miss my sesison due to limited space, I hope to have a bigger room next year. But, as FOTB organizer John Davey pointed out, the intimacy between speaker and audience that the FOTB Pavilion provides is often a very coveted thing. I loved it and hope to experience it for years to come.
FOTB is living up to it’s amazing reputation, and per 2 Adobe attendees I’ve talked to, it’s now considered the best in the world!
Coding iPhone and Flash Mobile, back to back
After spending the bulk of my ‘personal coding time’ over the last 6 weeks on building my first iPhone game/application, I’ve moved on to another mobile coding platform. After 6 weeks of learning Objective C and Xcode (also my first time coding on a Mac), I’ve jumped back in time to a mobile platform called Flash Lite. Pretty insane. It’s a mobile coding mind bender. The developer’s equivalent to a gender transformation.
These are completely different platforms, and the approach, ‘vibe’ around them, and outcome couldn’t be anymore different.
With the iPhone, with each compile & build, seeing and feeling the app load on a my sleek iPod Touch, I felt like I was an Olympic swimmer, making a sleek dive off a precision diving board into a crystal clear pool surrounded by people sunning themselves and drinking vibrant cocktails.
On the other side, cracking open Flash Professional, coding archaic ActionScript 2 and compiling into the Flash Lite simulator they call Device Central, the experience was much different. It feels like you’re climbing up those wet and slimy stairs of a pool slide, making your way down the insufficiently watered and windy curves, somewhat burning your skin on the sides of the dry plastic, before getting dumped into a pool of a few senior citizens floating on foam noodles and sort of applauding at me.
Strangely… I still really love the latter experience. Why? Because it feels unique and un-crowded. The stuff I’m doing seems far more untouched, less shiny, yet way more revolutionary. And the stuff I build with the latter process can be published to a comparatively infinite number of brands and devices. The same Flash Lite (FP6 level) .swf I coded co-exists on both a Chumby, as well as my Sony PSP. (Pause for a second and imagine that. Two companies, produce two devices, meant for a much different purpose and market. Yet, they are bound by a common mobile platform that tells me, the developer, that I can WRITE ONCE!] I haven’t even tried my Flash Lite app on actual mobile phones yet. The thing is… I don’t need to. I know what I’ve done and accomplished. Feels good.
The app I built will be demo’d at http://developer.ribbit.com/blog in the near future.
While the process still needs a lot of help, I can see how Flash Lite (soon to be much grandeur Flash Mobile development) still has a huge place in this mobile application movement. And now that I’ve had my moment with Flash mobile coding, it’s back to iPhone to build another app that I hope thousands will enjoy — at Apple’s discretion, of course!
Going under Flash and Flex, Ribbit to release RESTful API
Internally, much of the company has been chanting “we are going beyond Flash and Flex”, but I don’t think the word ‘beyond’ is right to say. Maybe ‘to the side’. Definitely not ‘over’. Probably not ‘in a tangent’. However I can get myself to say it, Ribbit is about to offer the global developer community the ability to code our communications platform into their applications in more ways than just Flash and Flex. And this is a very good thing…
Since launching the initial SWC (now called our Flex SDK) back in August of 2007, the platform has enjoyed an incredible run as the leading provider of telephony, voice, messaging and user management services to developers. Our community of over 11,000 developers has built some amazing apps, many of which are hot contenders for our $100K Killer App Challenge, which culminates this week!
The RESTful API release is really an evolution for the platform as a whole. Unlike Flash Platform, developers will now be able to code machine to machine, schedule calls, perform advanced user management, create user tokens and so much more. The real gem presented in the RESTful API approach is that deploying this as a core platform API gives us the means to tightly wrap almost any other programming language (in demand) around it.
Essentially, you are going to see Ribbit offered to developers in languages like PHP, Javascript, Obj C, .Net, AS2 (for Flash lite development), Java, and pretty much whatever the community wants. The true potential for reaching the global community is unlimited and the wide array of language offerings means Ribbit apps can be built on almost any platform out there. And the RESTful API is going to go literally right under our Flash and Flex offerings, since those APIs can now leverage a much tighter data delivery protocol.
So, what does this mean for a lead evangelist (me, me) who wakes up and goes to bed dreaming of Flash Platform Apps? Well… if the Ribbit Platform was a chest of toys, I certainly have a much wider variety of things to learn, play with and show off to others! It also means I have access to another side of a web technology I still (sincerely) regard as the most innovative I’ve ever seen, touched or heard!
This news will officially come out from Ribbit while we’re at SxSw. There will be a special site launched (url to be announced soon) where developers can even go ‘vote’ on which language they want to see Ribbit release the most! And as for evangelism, I make my first non-Flash conference appearance in a week. It’ll be in Las Vegas. Sounds like MAX, ‘cept not spelled the same way.
Flex Example: simple slide out menu using effects
A lot of Flex developers resort to Flex ’states’ when adding interactivity and transitions to their applications. I built the sample below to show a colleague that using Flex ‘effects’ are some times easier and involve less code than ’states’. This simple example (very beginner) shows how you could build a slide out menu bar without the use of states, which I consider a bit difficult to maintain and skin. The code is available for you just below the working sample.
Click the button on the yellow panel to see it slide out like a shelf.
You can cut and paste this code into your FlexBuilder project and test it out. Feel free to use this in any project or app you are working on.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 | <?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="init()"> <mx:Script> <![CDATA[ [Bindable] private var bPanelStartX:Number = 0; private var bPanelEndX:Number = 0; //set position values for back panel private function init():void { bPanelStartX = frontPanel.x - 25; bPanelEndX = frontPanel.x - 100; } public function movePanel():void { //set target of move transition panelMover.target = backPanel; //determine direction of panel based on position if (backPanel.x == bPanelStartX) { panelMover.xFrom = bPanelStartX; panelMover.xTo = bPanelEndX; } else { panelMover.xFrom = bPanelEndX; panelMover.xTo = bPanelStartX; } //play transition panelMover.play(); } ]]> </mx:Script> <mx:Canvas id="backPanel" width="250" height="250" x="{bPanelStartX}" verticalCenter="0" backgroundColor="#FFFF00" backgroundAlpha="1.0"> <mx:Button click="movePanel()" x="0" verticalCenter="0" width="25"/> </mx:Canvas> <mx:Canvas id="frontPanel" width="250" height="250" horizontalCenter="0" verticalCenter="0" backgroundColor="#FF0000" backgroundAlpha="1.0"> </mx:Canvas> <mx:Move id="panelMover" /> </mx:Application> |
If you know or a more simple way to do this, please feel free to post it on your blog and comment the URL here. If you’ve got other examples of using transitions without states, feel free to post those as well.
MAX 2008 session videos are being posted
Ted has announced the initial videos of sessions from MAX North America are starting to be posted. This is exciting. Having videos from 360Flex San Jose has been excellent. Since I was working the Ribbit booth during the conference, I missed out on a lot of sessions I wanted to see. I’ve asked Ted if there will be a publish schedule for the session videos, and I’ll post an update when he responds to my comment.
The videos will be featured on the Adobe TV MAX channel.
UPDATE: Ted says that there will be no schedule and that we should want to watch every video anyway. 290 hours is a ton of content to produce.
My favorite ActionScript interview questions to ask
I’m about to interview someone for an ActionScript-related position here at Ribbit, and in my preparations, I thought I should post my top 5 favorite sets of questions to ask candidates. I have done a lot of interviewing in my 10 year Flash career, and these questions usually engage the candidate in a unique and effective way:
1. What do you like best about Flash or Flex? What can you do with those features you can’t do in another technology?
[This first set of questions shows a general appreciation for the technology.]
2. What version of Flash Player was most prominent when you started coding? What key features of that player did you target? What features in Flash Player {current version} do you wish you had back then?
[Getting a little more technical, this set of questions reveals the candidate’s history with Flash Player, identifying their awareness of features years ago as well as with new versions of the player.]
3. What is the most efficient (or profound) code tip you’ve discovered that you always share with other developers?
[A question like this demonstrates code expertise as well as a bit of community/team orientation. I find that a developer who likes to share efficiency tips is a bit more code proficient as well as a more senior member of a working team.]
4. Have you ever coded for a project with bandwidth, file size or other performance limitations? What were those limitations and how did you accommodate them?
[Delving a bit more into the candidate’s experience, this question explores awareness of architecture and code efficiency. Although the bandwidth question is less and less applicable, most ‘seasoned’ AS developers have dealt with it.]
5. Of all the projects you’ve worked on, which one were you most proud to see launched, and why?
[This is my favorite and a great closing question. I want to work with a developer who loves what they are doing, and this demonstrates passion and focus towards their past efforts.]
Candidates find these questions refreshing, especially after being usually grilled by more 1,0 colleagues of mine. I find these questions bring out the more creative and inspiring side of a candidate. Let me know if you use these questions in the future. Expect positive results!
Follow Me
Follow Me
Upcoming Engagements
-
