Controlling An Embedded Device Using Flash
JimCricket writes "Art & Logic has just released a web server toolkit based on the open source GoAhead WebServer. The cool part is that it can communicate with Flash presentations using XML-RPC. The idea is to create GUI's to control embedded devices using Flash in addition to (or instead of) HTML. They've posted a little demo running on Windows, but in the real world the server would run on a low-power device. Seems like a great idea for the embedded world, given that Flash interfaces _can_ be very low-memory (as long as Flash designers stick to the vector-based graphics and ActionScript)."
...would listen to its customers. We run one of Germany's largest flash-based web sites. We are happy with Flash and what it can do, but we encounter little bugs and annoyances every now and then.
Macromedia doesn't fix them.
To make things worse, the German product manager basically tells us "we don't have to fix this. We don't care. Without us, your site wouldn't exist. You better be grateful."
If only there was an alternative to Flash to escape this.
(Yadda, yadda, closed source, I know, I know. Trouble is, there is no alternative to Flash at this time.)
the first thing i thought when i read this was "controlling blah blah using sector-programmable EEPROM"... sigh; been in the hardware side too long.
side point: flash programs themselves are small and neat -- but the actual client (that reads, processes, and displays the animations and all that) always have seemed quite processor intensive to me, though... so besides being fancy and neat -- i am sure there are more power-saving interfaces you can use if that's really what you are after.
My life in the land of the rising sun.
SVG and DOM don't include synced audio. Granted, you don't need audio for this particular application...
------------------
You may like my a cappella music
Requires Macromedia Flash Player 6
on the little demo page. Too bad I removed FLASH due to it's abuse by web advertisers. I hope Macromedia will put out a player that can be set by default to not play flash. HINT HINT! I'm not going to install it to watch a demo and remove it for the rest of my browsing. Is a play button too much to ask?
The truth shall set you free!
I am a home theater addict and have been very disturbed by the fact that the home theater industry moves just as fast as the computer industry but you can't upgrade your components unless you get something from manufacturers like Krell, Meridian, Theta Digital.
So... many of us are using what we call Home Theater PC's (HTPC) to play DVD's in Progressive scan mode to feed our DLP projectors, using MP3/Ogg/Wav files for our home audio collections, HDTV decoder cards, etc. The problem is that all this stuff needs to be easily controlled with a remote. Many people have designed interfaces using flash/webserver and they tie it into an IR controll system. Maybe this will make it easier to hide the computer-ness of our HTPC and make them more appliance-like.
If interested, avsforum.com has some nice forums for discussion in the realm of HTPC's.
fyi:
/
macromedia has a mobile device development center for flash
http://www.macromedia.com/desdev/mobile/
and there is this book:
http://www.amazon.com/exec/obidos/ASIN/0735711771
The real advantages here aren't so much in the "hey neat" category, but in the application of this technology. Not all of us are all that efficient at gathering information from text logs or what have you - many of us are more visual. If I could have a small flash application based on this technology that used images or even sounds to say, help me visualize the load on each of my servers from home, great! Instead of browsing through several megs (or gigs) of logs, I just look for the image of the server on fire. It won't eliminate the need for "down and dirty" work, but I can certainly think of many examples of where it could minimize it.
flash for an interface is just a stupid idea.
why goto the trouble/expense of including a vfd or a full color lcd. then emulating all the things flash needs to run. vs making a custom lcd/vfd display with your buttons on it (even if it looks just like the flash) and use that.
oh morphing interfaces you say. the answer... do we really need a remote control with skins. do we need a tv that has some silly panasonic movie running on it all day.
Look at all the crap thats gotten into car stereo head units these days. I mean the rice-boys love it but i still cant find a decent nice sounding stereo system for under 500 bux that has all the outputs and FUNCTIONAL abilities i want. Instead to get (rca) instead of line leads off a device you have to goto the $700 (cdn) range and end up gettin these stupid pixel usually like 320x100 displays and they distract the hell out of you while driving... I DONT NEED A GRAPHIC EQUALIZER...
oh yes you can turn the crap off but at the end of the day you've paid an extra 200 for the stupid display.
leave hardware alone, keep it away from macromedia and microsoft. embedded linux is nice because its just so barebones simple when it gets to that level. flash would seriously gum it up.
keep hardware devices simple. provide functionality not flash. its not a website they're not sitting there for the purpose of that site. With hardware you want to use the damned thing not have it look pretty.
The ONLY exception might be in the intergrated appliance market eg a microwave that has a vfd display that is a picture on the wall for example (like in anti-trust the movie).
in which case however flash still isnt the answer. a custom application is. faster better and most importantly designed to do the job specifically.
flash really is bloat ware when it comes to the stuff needed to properly impliment it and short of a specialty product from macromedia trying to adapt it is just plain silly.
Note that it doesn't matter whether the Flash player is smaller than the Java runtime because that part of it runs in the web browser, not the embedded system. From the point of view of the embedded system, what matters is the footprint of the Flash or application specific class files, and Java is probably competitive there.
For a lightweight interface system that talks XML-RPC/SOAP and is easy to port to other platforms.
It's written in Java, but natively compiles on Linux/Win32. None of the speed problems of Java (thanks to a different design tack with Box rendering).
Of course, the obvious advantage over Flash is the fact it's open source (GPL).
They wouldn't have done this unless there were some good reasons to do so. The Flash engine is small and runs on embedded devices due to Macromedia's tireless attempts to get it everywhere they can. A simple Flash player and Flash application can come in under 500k and there is no browser on earth that can match this. Flash supports XML calls although it doesn't validate them. This idea neglects a security model as Flash doesn't have one with respect to the server so I hope these guys are not planning on doing stock quotes or transactions or something like that. The Flash interface is a good idea on precisely those devices and may yet gain more acceptance than Flash in the browser ever did, because the browser is really meant for HTML and nothing else.
Problem 1: Flash is a very common kind of memory chip used in embedded devices. In fact, it's a multi-billion dollar industry. And it has nothing to do with Shockwave or Macromedia.
Problem 2: There's no embedded computer in the example - it's a Windows box.
The point of this story was to illustrate the use of Flash in building user interfaces for remote web-based control, not for use as a primary interface on the device itself.
the reason why people can't set the clock on their vcr is that technical people make the interfaces, not interface designers.
Yeah, right: if your VCR were designed by interface designers, like Microsoft Word, it would have 200 buttons, be bigger than the TV set, crash with regularity, and cost $500. The reason why VCR clocks are hard to set is because there isn't much room for buttons or much money for fancy software. It's called an "engineering tradeoff". Get used to it. If you want a better VCR, pay more: the high end ones are simpler to use or set themselves automatically.
I'd think that if you want this to be a low-bandwidth interface, XML-RPC is about the last thing you'd want to use. What's wrong with good old fasioned URL-formatted parameters?
I mean,
<?xml version="blah"?>
<methodCall>
<methodName>eat_cheese</methodName>
<params>
<param>
<name>amount</name>
<value>lots</value>
</param>
</params>
</methodCall>
just seems like overkill to me when you could just do:
action=eat_cheese&amount=lots
I guess I'm just behind the times...
Duct tape, XML, democracy: Not doing the job? Use more.
I doubt you'll find a development environment that is as easy to use and as quick to learn as Flash is for mocking up applications and interfaces.
Just wanted to point out that an application written for flash uses a proprietary application to run and a proprietary ide to develop. This should cause people concern.
Market infrastructure should not be based on monopolistic proprietary technologies.
Something along the lines of translated bios codes.
Maybe a Over Temp on a CPU could play the "FIRE BAD! FIRE BAAAADDD" clip from the Metallica/Napster flash movies.
That's be so funny.
Have you read the moderator guidelines? Well, have you, PUNK? (and I want a Karma: Gnarly option)
Ergg. My first thought was of turning on the microwave, and getting a light show with a cheesy tune played using the beeper, along with a prompt to 'Press here to skip intro and begin cooking.'
That said, the only practical use anyone has actually found for Flash is those "Skip Intro" pages that everyone skips with a grunt of mild irritation.
That's simply not the case. There are some compelling Flash applications, such as the...
Korean Arse Shooter .
Da Blog
I use my VCR in the same way about; setting the is a waste of time, it would enable a feature I don't use anyway. However, apparently people who design devices don't like it when users don't want to use all the features, like the clock. So they do things like this:
* Make 12:00 blink annoyingly on the VCR, so you end up with setting it or leaving the VCR on (with a tape in) to get it to not do that.
* Going even farther, the folks who design GE microwave ovens feel so strongly that the clock is an important feature that they device cannot be used at all for its main purpose, without first setting the clock (time/date) which has nothing to do with that purpose.
Unfortunately I am not a software author. I haven't the slightest idea of where to begin. Before you call me dumb, I am a ISCET Certified Tech. I'm a hardware tech. I can but a Broadcast radio station back on the air that has been hit by lightning (ask for photos) so my field of expertise is not software coding. Would you know how to fix a 50 KW FM transmitter dammaged by lightning? I know how to use a Motorolla D2000. My debuging tools is not compilers and such, it's storage oscilloscopes, spectrum analyzers, time domain reflectometers, digital multimeters, directional wattmeters, etc. We are only experts in our own fields.
The truth shall set you free!
sorry, I was kinda kidding. I think it just illustrates how ridiculous the "write it yourself" response is for 99% of the people who use computers.
DO NOT DISTURB THE SE