Request for comment.

I'm almost done with the alpha version of flash/flex client. Attached is a sample of the layout. Any suggestions welcome. The dimmer controls in the image only show up if you click on a dimable device. Othewise a click on the list toggles the state of the device.

The layout is based on the MythTV UI for a 10 foot interface and touchscreen control. The image is wide do to my widscreen monitor but will dynamically scale down to 800x600. I'll have to add a seperate view for smaller screens.

If anyone knows, does the server send out any kind of log reset message? After a few days the flash client log varible gets pretty big. I could just reset it myself but if the server does it I'd like to keep the two in sync.

Also because I looked everywhere else, anyone with flex actionscript experience, how does one determine the number if item are currently visible in a list? I need this so the page up and down buttons compensate for the device list being resized.

Comments welcome.

I'm currently learning Flex myself for projects at work. I'm very excited about a possible flex interface for indigo as I've been running a separate virtual home interface in cold fusion for things that Indigo didn't do. To bring both together via flex would be awesome.

Matt

[matt (support)]

I like it!!! Do the items in the list properly update if another connected client (Cocoa Indigo client) adds new Devices or changes the names of existing Devices? I cannot wait to play around with it.

There is no log reset message broadcast from the server. The Cocoa Indigo client just uses FIFO queue for log lines such that anything older than 1500 lines is pushed off of the window.

FYI, the client can send a GetLogHistory request (request, not command) to the server to get the last N lines (where N is the data packet in the request). The Cocoa Indigo client does this on launch so that it can fill in the last 150 event log lines to the window.

Matt

All the items update their status no matter what changed, name, status, creation or delete. The list itself just displays the on off state of the device. When you click a dimable item then the dimmer control in the screen shot becomes visible and sets the scroll control seen to the current setting of the device.

This method just made the list look cleaner in my opinion. It could easily be changed to be the same as the native client.

I'll have to add the getlog request to the log page. Right now it only logs from the launch of the client. Does the log on the server cycle at all? Just wondering how much history it keeps so I can adjust the page up and down functions.

The last few things to do are add the actiongroup page, which is just a clone of the device page, and add a shared object to enable local password caching and host settings. A preference page. Does anyone really need to list the time and date actions in realtime? You can already tell if the action fired by looking at the state or the log. At this point the client is just a cross platform replacement for the web interface. You can't create anything in it. Hopefully in the future. But for now control is done more often then setting things up.

I do have one bug to work out and that is to determine the number of items displayed in the list so the page up and down functions adjust accordingly on resizing of the client. Right now I have a fixed list length that fits only my screen. I'm trying to keep one from having to scroll the page. I did have it working when scrolling up and down one item at a time but that takes to much input for a longer list. I also messed with using a mouse over event instead of having to click the page up down buttons but that seemed too akward and non-specific to me. Anyone's thoughts are welcome. Plus it breaks the 10 foot interface design goal.

Last question (for now), when setting up a varible do you have to define the values allowed. I'm trying to figure out a way to list the varibles and allow you to change them without to much input. Boolen values are easy. Maybe everything else should just display a value. I don't know. I don't use that funtion myself. I do it in action script instead. That option is only useful for the actionscript folks in the house.

Finally if it is of any interest I'm playing with integrating a Global Cache 100 into the client at some point. I know its on the the list to be added to Indigo at some point. I've discoverd that each device has it's own TCP port that you write too to control whatever is connected. Ok easy enough. Trying to generalize it enough to so one could use there own codes is where I get hung up. Checksum computation is different between my Sharp Aquos tv and Harmon Kardon reciever for instance. A topic for another day..

Thank

Mike

Forget the page up and down bug. I found a way using the ICollectionView class to determine the length of only the items displayed in the list.

Hopefully I have something for you to play with by the middle of next week.

Mike

[matt (support)]

Hi Mike,

Does the log on the server cycle at all? Just wondering how much history it keeps so I can adjust the page up and down functions.

The server itself also keeps only the last 1500 lines in memory. This is actually a hidden preference (MaxLogHistory2) that can be adjusted via the server's XML pref file. The native Cocoa client is hard coded, however, to always just keep 1500 lines in the UI.

The last few things to do are .... add a shared object to enable local password caching and host settings.

You shouldn't need to add local password caching. You can request from the Indigo Web Server (assuming you are having the Indigo Web Server serve the SWF file) the current user name and password. It actually also returns the domain and port number to connect to as well, so once the SWF starts executing it can automatically get everything it needs from IWS to establish a connection to the Indigo Server. This works because the request is first checked via the IWS (Indigo Web Server) HTTP authentication scheme. If the user has already typed in the user name and password to download the SWF (via the browser authentication UI), then IWS knows it is a valid user and can pass along the authentication information to the SWF. The original Flash client I emailed you has the logic to do this in it. Try accessing the path "/flash_conn_prefs" via Safari from IWS to see IWS return all the information you need.

Last question (for now), when setting up a varible do you have to define the values allowed. I'm trying to figure out a way to list the varibles and allow you to change them without to much input. Boolen values are easy. Maybe everything else should just display a value. I don't know.

Indigo Variable values are untyped. They are all just strings and get dynamically cast to booleans or integers in Indigo Server. There currently isn't any meta information stored in the Indigo database that will provide any type of hint as to what type of values are allowed/expected.

Regards,
Matt

Great. That will work for servering the client from indigo. Any suggestions on how to keep authentication on but not launching the client in the web browser?

Right now I'm am creating a projector using the flash client and launching that at startup. That way I don't have to type a url and it allows the client to run full screen without any of the browser controls or desktop controls being visible. I already have it caching the ip and port of the server so all I have to do is connect a keyboard the fist time to enter the info and have the shared object saved to the local file system. From then on a keyboard isn't needed for normal operation. Having to enter a username and password each time the client restarted would break this. As for remote use, from another computer, no problem.

So, I think I have to create a shared opbject that holds the connection setting for a stand alone client and grab the info from Indigo when using the client within a browser.

Other then that all I have left to do is clean up the code and document it inline for others to use. Mainly so they can change the interface to meet their needs. I need to rewrite the device control functions to be more generalized. Right now its kind of a mess and UI elements are changed within some of the functions. I'm need to keep the UI seperate from the logic so its easier to maintain. But that is a small task.

[matt (support)]

Great. That will work for servering the client from indigo. Any suggestions on how to keep authentication on but not launching the client in the web browser?

It sounds like in this case you will probably need to cache it locally yourself. I was originally recommending avoiding that since caching passwords locally (and not encrypted) is a security risk. But if your client machine is locked down and you aren't worried about someone trying to hack out the local cache, then I think that is likely the best sol'n in this case.

Regards,
Matt