This page last changed on Jul 31, 2009 by admin.

To anyone who has spent any time with the iPhone or iPod touch it is quite clear that touch screen computing is here to stay. While looking around for a touch screen interface for your home automation you may have experienced acute sticker shock at the prices of some of the available touch screen systems and the lack of integration with anything other than the primary vendors HA system. Mark Fluery and Mark Spencer came upon this Android based touch screen vendor :  TouchRev (make sure Javascript is enabled). They make the NIMble touch screen, a 7" touch panel with Bluetooth and WiFi. This looks like an excellent starting point for an open, intelligent, programmable touch screen.

NIMble.jpg (image/jpeg)

From what little I know of Android it looks like it will be a proper fit for it's roll as a touch screen interface. I don't agree with those who believe that Android will be a full fledge OS. I know my preferences are that I don't need a full OS for things like my touch screen.

Now for some hardware specs:

Main processor Minimum 600MHz StrongARM
Memory 128 MB DDR RAM, 512 MB NAND Flash
Expanded storage SD Card Slot
OS Embedded Linux
Middleware Android Application Framework
Screen type TFT LCD
Screen dimensions 4.3", 7", 10" Diagonal (Other custom sizes supported)
Resolution 480 x 272, 800 x 480 and higher
Touch sensor Type Multi-Touch Projective Capacitive Glass Surface
Connectivity 802.11 b/g WiFi, Bluetooth, USB 1.0/2.0, Ethernet
Audio Stereo Speakers, Stereo Headset Jack, Directional Microphone, BluetoothTM 2.0/2.1 + EDR stereo (A2DP) range of 10 meters
Camera 2MP CMOS Camera, 15fps full resolution video, 30fps 1MP video

I'm not sure about the camera but it's not a bad thing to have. I expect that the NIMble is pretty lite on power usage. In addition to a wall mount (using a power supply) I'd also like a table top unit. I'd expect a broswer to be included so I can get information on not just the home but other things too (Dammit, the Yanks lost! How'd the Mets do?).

I'd also like to see a larger touch screen model, 1024x768 or better. My eyes are having a harder time reading things like my WinCe based smart phone. I very much like the iPod touch except that on things that cover something like a page of paper it's swipe right to left, then back, then down then rigth to left. A pain to read anything but the simpliest of documents.

I'm also aware of the Always Innovating Touch Book but it's really hard to get (next available run is the end of 4Q09 if you're on the waiting list). If anyone has any other worthy contenders please post a comment adding to the list.

I also have a Nokia 770, nice touch screen, a bit small and I wish the browser supported using the touch screen better. In addition I have the Chumby. Nice hardware but I am not impressed with the software or how you get it. I could spend time getting it to talk to my local servers but that would take away from OpenRemote work. So it just languishes as a forgotten side project.

Posted by linuxha at Jul 29, 2009 19:50

Mark Spencer is investigating them as a phone provider.  So they seem to be versatile.

Last I checked we were getting an Android based XML renderer from Andy Oliver (an ex JBossian).  It seems redundant with the fact that android has its own XML screen description but whatever, for the meantime having some android support could open a few doors in terms of panels that do not suck.  I can't wait for a wall mounted one.

Completely agree that I don't want a full OS on these things. I want something that is immediately on with a dedicated application mode.

Posted by marcf at Aug 04, 2009 09:56

That would be welcome news that we can extend the work MarkS has done so we can get some working units. Like I said I ordered the Touch Book (probably gonna get me in hot water with the CFO, oh well). A nice 10" model would work well on the wall.

On the Android front, excellent, I'll ask Andy if he can share what he has and then see if I can get it running on the N770. Too bad nobody's got Android running on the 3com Audrey (I've got two of those). I'm not volunteering, I've got too much on my plate and it's not my best area of work (wish I knew what my best area of work was ) Dang I forgot I had these things (way too much school!). I guess I have to tidy up this place so I can find out what I have in the way of home automation.

Posted by linuxha at Aug 05, 2009 01:58

As I stated on the OpenRemote Chat, I've placed an order for the Always Innovating Touch Book.I don't think I'll see it until end of the year (I hope it's earlier). Maybe I can get my hands on a Touch Revoltion touch screen running Android. I have the Android SDK on my development machines.

Looks like the Nokia 770 running Android has a few problems (no network, no Bluetooth). So I won't be playing with Android on the N770.

Today I saw a nice ( ) article from CNN titled: Why consumers won't buy tablets. Uhm, I'm not sure the author understands touch tablets. These computers are not meant to replace your main computer (What is real work? Word processing, programming, ??? Most computers aren't desktops ... ). He is correct in that if the machines are too expensive then they'll just stick to what they're currently using (mostly laptops). I'm not so sure how Apple will effect the market. They're too expensive ($500+) for our requirements and I agree that for much of the desktop processing that the touch screen is annoying. I know I wouldn't use it for development work (how do I type ^X^C on a touch screen). Man, Emacs would be really tough on that thing!

Posted by linuxha at Aug 07, 2009 05:07

By marc's comment, the "redundant" was that the android panel be compatible with the iphone panel.  So it just uses the iphone.xml.  I also went to great efforts to replicate the layout system of the iphone.  The Amsterdam demo makes some assumptions based on the iphone's behavior that I had to emulate.  The normal behavior of layout on the android is different.  I actually think the layout system needs to change with regards to the iphone because right now there are 3 phones (the new Android phone with no keyboard just went mass market) and all have the same screensize.  However none of the screens will behave when the resolution is different. For that we need more disciplined layout system.  I still think it can be granny compatible/wysiwig, yet support different sized screens.  Its a matter of coming up with sensible layout artifacts and using those.

The android XML format isn't really what you'd want for OR.  I thought about doing this as one big fat XSLT-like thingy to change the iphone.xml to android, but screen compatibility would not have been possible and it wouldn't have been good.  ATM the android and iphone should render the same minus the iphone bugs that I couldn't replicate and the android G1 battery lasts 5s of 10s of minutes

Posted by acoliver at Sep 02, 2009 23:29

Two separate topics here and neither is really relevant to the original post. However:

1. What should the UI XML look like?
2. How to handle the differing screen dimensions?

For #1 I do think we should render on the native XML schema – as much as possible. For a couple of reasons: a) it removes the parsing and UI building code from the consoles, making them even thinner which I like and b) it allows some slight stylistic tweaks to be done to the UI via XML document editing even if the designer tools do not support certain features directly. That's hard to do if we build the UI in code by parsing our custom XML.

The native XML instances should be generated by the online UI composer. I like Android's XML UI definition, it looks quite reasonable and is worth investigating further. David Reines is working on a GWT based generic web console – GWT too will have a UI XML bindings once UIBinder is released. We could then in theory generate the XML bindings for Android console, GWT web console and iPhone (using OR XML definition since iPhone lacks a native one).

For #2 I don't think there's a one-size-fits-all solution. For slight changes in screen dimensions there needs to be layout elements that define how the UI adjusts (cf. Swing layout managers and HTML documents). However, going from phone-sized screen to larger display will mean a complete rearrangement of the UI – easily seen by websites that support both "regular" computer screens and mobile devices with different UI layouts. This should be done via the UI designer by creating the profiles – not for granny vs. power-user scenario although the same implementation can be used for that type of profiling – but simply for different device capabilities. Same applies for layout designs that rely on images such as discussed here – any kind of image scaling to adjust to different screen sizes will lead to poor visual results so each individual device is likely to need its specific profile to adjust the UI appropriately.

Posted by juha at Sep 03, 2009 18:09

Well for #1, that will mean accepting some divergence in behavior. It is possible to define some/most of it using the android xml.  It isn't possible to replicate the amsterdam demo using only the andorid xml.  You'd need more information (like "i intend this to be a background image and not a button).  This really becomes "do the interpretation in the GUI designer or in the individual apps". Right now you have a reference platform and anything else should emulate that.  You suggest something that is aken to moving towards a compiler with backends for different platforms.  I'm not sure one route is better than the other (your current route is more like Java, what you propose is more like a C crossplatform compiler).

#2 I agree.  Of course a phone gui will look stupid blown up to my 1900x1600 (or like a darn shame waste of space), but it should look ok on the next generation iphone or android with say an extra 100 pixels on each side (which apple will market as the most revolutionary idea they've had since cut and paste).  Layouts and template will help that a lot.  I'm not entirely convinced that Android XML is enough... but with some reasonably defined layouts we could probably do a good large chunk of it though.  Its possible to dyanmically load panels and things from the XML.   I think defining layouts (ala swing layout managers,html,etc) is more important than profiles though (not that both shouldn't be done).  With layouts you can at least get the iphone app to render correctly at 1900x1600 (even if it would look stupid).

For android I also wonder if the GUI designer could deliver apk files with the images in them.  It is quite slow over say WAP or EDGE and I'm not very patient for things to load.

I wrote up the current android source walkthrough here btw:

Posted by acoliver at Sep 06, 2009 01:44

Move this topic to a separate thread as it is sufficiently interesting not to hide here in the comments.

Posted by juha at Sep 06, 2009 17:23
Document generated by Confluence on Jun 05, 2016 09:32