Developing widgets for chumby

From Chumby Wiki
Revision as of 00:38, 24 October 2006 by 24.19.12.13 (Talk)

Jump to: navigation, search

Summary

Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video).

As of right now,

  • PNG and GIF image format aren't included. This could change in the future.
  • Progressive JPEG support isn't included.
  • It does not support video (Sorenson or On2) or Nelly Moser audio
  • It does not support LocalConnection or XMLSocket.
  • It does not support the Flash Communication Server
  • There are no device fonts - all fonts must be embedded in the movie
  • Playback of external audio files (MP3, etc) are not yet supported.

Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate.

For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost.

Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).

Widget Environment

Widgets are given a set of parameters about the environment of the chumby: For example: 

this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'
this['_chumby_chumby_name']='TestChumby'
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'
this['_chumby_profile_name']='Default'
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'
this['_chumby_user_name']='johndoe'
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'
this['_chumby_base_url']='http://www.chumby.com'

A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create: 

this['sign'] = 'Scorpio'

Security

The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate crossdomain.xml file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:

One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.

In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.

Testing a widget locally

  • Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.
  • Create a file on the dongle called "debugchumby" with the contents 
#!/bin/sh
/usr/bin/chumbyflashplayer.x -i <name of flash file>.swf
  • Plug the dongle into the USB port on the back of your chumby
  • Power it up - after the opening animation, your widget should run


Using SCP to Test Applications

Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!

In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".

I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow. Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.

  • Create a VFAT formatted usb key as described above.
  • Create a file on the dongle called "debugchumby" with the contents 
#!/bin/sh
/bin/sshd
  • Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development. 
 ssh -l root chumby

You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)

  • Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)
  • Put usb key back in your development box.
  • Get a copy of scp either by compiling it for ARM-linux, or take the somewhat easier route of cracking it out of the Zaurus (also and ARM processor) OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. There's no real trick to it - you can simply ungzip & untar the ipk and then data.tar file and eventually grab scp which will be tucked under ./usr/bin (make sure you get the arm version you've just untarred, and not the one from your development box!). Grabbing pre-compiled ARM code from the Zaurus was a real effort saver.
  • place scp' in the usb key root directory.
  • place usb key back in the chumby, and then reboot the chumby again
  • cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother.

(on Chumby) 

 cd /usr/bin
 ln -s /mnt/usb/scp /usr/bin
 cd /mnt/usb
 chmod +x scp
  • from your development box terminal window, as sudo (or root), you should now be able to copy a file 
 sudo scp -l <filename> chumby:
  • from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename>

Good luck! This is much easier than moving the usb key back and forth!

  • Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. Or maybe not...
  • Samba would be very nice.

-hbchumby

Iterating With Chumbyplayer.x

Now that you can move files to the Chumby easily, how can you iterate? What I is create a similar script on the Chumby (in /mnt/usb) that kills the current Chumby player and restarts it with my test application: 

 #!/bin/sh
 killall chumbyflashplayer.x
 /usr/bin/chumbyflashplayer.x -i mytestapp.swf

This works, but some other process is killing my instance and running the 'default' chumbyplayer.x instance after a minute... Still investigating.

-hbchumby

Retrieved from "http://wiki.chumby.com/index.php?title=Developing_widgets_for_chumby&oldid=1402"