Have you ever wished that your Chumby had a secret menu that would allow you to enable all sorts of cool functionality like SSH, and the ability to get Screenshots? No? Well too bad, I’m gonna tell you how to do it anyways!
If you missed part one of this series “Creating You First Chumby Widget – Part One: Setting up Your Files,” I suggest you take a moment and browse through it before starting this section. For those of you who have already completed part one, welcome back! In this part of the series I will walk you through the process of updating the firmware on your Chumby device, enabling SSH, and finally connecting to your device over SSH.
Get Yourself a Chumby:
Now that everyone’s caught up and has a working application that they want to publish to the Chumby, there is just one more thing you need: A Chumby device. This may sound like common sense, but I feel it’s important to note that in order to properly test your application, you will need to get a Chumby device. At the time of this writing there are no Chumby emulators available, so the only way to fully test your application is to get your hands on a device. That being said, not all Chumby devices support Actionscript 3.0, so before deciding which device to buy, you will want to make sure that it supports Actionscript 3.0. You can find a list of Chumby devices that DO support Actionscript 3.0 HERE.
Update Your Firmware:
In order to run AS3 based applications on your Chumby device, you will need to make sure that you have the latest developer firmware installed. You can get the latest firmware for your device at the links below:
I know to some of you SSH might sound like some hard-core technology reserved for uber-nerds and computer science majors, but fear not, by the end of this tutorial, you too will be able to wield the pure power of SSH to allow you to test your application on your Chumby device as well as getting trace output and other debugging info.
The first step to connecting to your Chumby via SSH is to enable SSH on the Chumby Device (logical, right?). You can find out just how to do that at the links below:
Connect to Your Chumby Over SSH:
Now that SSH is enabled, let’s put it to work. The first thing we are going to need to do is open our SSH client, and connect to the Chumby. If you are unfamiliar with using an SSH client, or have no idea what I am talking about, check out my post “Connecting to Your Chumby Device Over SSH,” which explains what an SSH client is, where to get one, and how to use it to connect to your Chumby. If you are already a master of the command line, and know how to use SSH, you still want to briefly review the steps in the tutorial that outline how to connect to your Chumby using an SSH client.
I know this may seem like a lot of work, but were almost there! I promise you, once you get through setting up and testing this first application, this will all be a breeze. In the part three of this series, we will finally get down to the fun stuff: Getting your application running on the Chumby!
So you’ve got yourself a shiny new Chumby Device and want to know how to connect to it over SSH so you can start testing all the cool Flash apps your building for it (obviously this would be the first thing anyone would think to do, not, I don’t know, playing with the device or loading it up with hundreds of cool apps that other people have created.. I digress..) The first, and most important, step in this process is to make sure that you Enable SSH on your Chumby device. Luckily for you, I have written a couple of blog posts outlining just how to do this on a number of Chumby devices.
Once SSH is enabled on your device, you will need to get your hands on an SSH client (this is what allows you to connect to the device and enter commands). How you accomplish this will depend on whether you are using a Mac or a PC:
A while back I downloaded the Flock, a new “social” browser that had a bunch of nice tools to help you stay connected with your social networks and various other online outlets. While it did not replace Firefox and Chrome as my defacto browser, some of the built in features (specifically the offline/online blog editor) earned it a stable place in my application folder. Today, while looking for a new desktop blog editor, I decided to give Flock another shot. I opened up the built-in blog editor and, after being unable to load up a saved draft from my WordPress account, decided to upgrade to “New Flock” (The resemblance to “New Coke” would soon become apparent), hoping that this feature would have been added by now. To my surprise, not only was the feature not added, but the entire blog editor had been removed from the Flock browser altogether! They didn’t stop with the Blog editor though, they decided to pull every feature that made their browser unique and even remotely useful, and stripped it down to a half-assed Firefox competitor with a few features to connect you to Facebook and Twitter. Long story short, Flock has now been permanently removed from my computer. I feel bad for anyone that invested in that company…
With all the new devices coming out these days (tablets, mobile phones, set-top boxes, etc.), it can be a bit overwhelming to try and figure out just how you’re supposed to create and submit apps for all the different platforms that are becoming available. Enter Chumby: With no strict API’s to learn, and running plain-old .swf files for all of its applications, all you have to worry about is learning a few tricks on how to upload, test, and debug your app on a Chumby device. To make things even better, Chumby runs on a number of different platforms, from mobile devices, to tablets, to HD TV’s; so once you have learned the basics, you will be able to immediately start developing apps for any of these devices! OK, enough with the sales pitch, let’s get started building your first Chumby Widget!
I ran into an issue today where I was receiving multiple events from a single view component. I did a little digging and quickly discovered it was due to the fact that my view mediator was using the RelaxedEventMap and I was not performing any sort of cleanup routine to unregister the listeners of the eventmap. The key piece of information to understand when using the RelaxedEventMap is that there is only ONE eventmap shared across all of your mediators (unlike the normal eventmap which each mediator has an individual copy of). The result of this is that if you do not properly clean up after yourself (i.e. removing listeners to the RelaxedEventMap from your mediators upon removal), then the listeners will still exist and will continue to pickup events even after the view has been removed. Continue Reading
The problem: You’ve created a custom event which has some custom properties (say an array of data you’d like to pass along), and are dispatching it via the Robotlegs context. You create your new event, populate your data property, and send it on its’ way via the dispatch method:
var e:MyCustomEvent = new MyCustomEvent( MyCustomEvent.SEND_DATA );
e.data = myArray; // or some other data you want to pass along
trace("My array is an array = " + (myArray is Array) ); // returns true
dispatch( e );
The event dispatches nicely; however, when it is received (by a command, or listening mediator), the data property is null!
// Code snippet from command mapped to this MyCustomEvent.SEND_DATA
public var event:MyCustomEvent;
public override function execute():void
trace("My events' data is an array = " + (event.data is Array) ); // returns false!!!
While implementing the Robotlegs framework into my first application, I came across a rather common issue: How do I properly manage my views? To give you the basic run-down, my application has a number of different views (menus and various other screens) that need to be shown on the display at different times throughout the application lifecycle. What I wanted was a way to store all of my views, and be able to map events to show a specific view at a given time (ex: a user clicks the logout button in some component, I want the login menu to be shown). Add to this situation the fact dependency injection (while wonderful) has one pretty major flaw: If the object that needs to listen for a particular event is created after the event is dispatched, you end up with a race condition, and the object usually loses (and as such could be shown in an invalid state). For the example of the login menu, let’s say that the use clicks the logout button, the event is fired to trigger a logout command, which then tells the application to display the login menu. This is all well and good unless there is some event that the login menu needs to listen for that gets fired before it is created (ex: The logout Command fires an event to tell the app that the user has logged out and this event contains a message “The users has been logged out successfully” that the login menu is supposed to display). If you’re still managing to follow my confusing-ass example, give yourself a high five!
THE SOLUTION: Continue Reading
If you’re anything like me, then you will most likely agree that loading assets (images, videos, xml files) in your Flash/Flex projects is a huge pain in the ass! Well today’s your lucky day my friend! The team over at greensock (the guys that made Actionscript based tweening a breeze with TweenLite) have come out with a new addition to their library: LoaderMax!
For a long time I’ve struggled with determining whether or not a property exists in Actionscript 3.0. Like many people, I would often find myself writing somewhat tediously repetitive conditional checks such as:
if (myObject["myProperty"] !=null &&
myObject["myProperty"] != undefined)
trace("Do the happy dance, my property has a value!");
Other than the fact that this is a lot of code to write (especially when you have a long conditional that checks 10 or 15 properties), this would work “most” of the time. I say most, because if the property you were trying to validate didn’t exist at all (i.e. there is no property name “myProperty” in your object), then you would get a nice “null object reference” error.