Google lets you code for Googlephones on Googlephones

@mike

Surely you either need to use hacks like this or have the sensors running all the time.

I would want to do editing on a PC (maybe an online Google account thing like GMail) and then update from there. My fingers are far too fat to write emails, let alone program scripts, from the tiny keyboard.

@Charles Manning

"Surely you either need to use hacks like this or have the sensors running all the time."

Perhaps I'm being too logical, but I would expect that either:

1) The startSensing() function would wait until the sensors were initialized before returning control to the script.

or

2) The startSensing() function would have an optional parameter which tells the function to wait until the sensors were initialized before returning control to the script (and the parameter should default to true). That way, the default usage would ensure that the sensors are ready when control is returned to the script, but the script could tell the function to return immediately (for example, if there are other tasks to perform and the author knows those tasks will take longer to perform than the sensor initialization). In this case, the readSensors() function should return a special value to indicate that the sensor initialization has not completed if called too early.

So no, a hack or workaround would not be required if the API was designed properly.

oh!

and a "while true do" with no getout = nasty infinite loop! tut tut

Indeed

"Surely you either need to use hacks like this or have the sensors running all the time."

Because this script may work on the current android incarnations - but what about when the android hardware becomes faster - will your current programs need patching for longer sleep? Surely the StartSensing should know when the sensors are online?

I can see why they arent on all the time (power saving) but surely the APIs are cleverer then that?

@all the above

Bleeding hell, it's alpha so saying that it wasn't designed properly and needs hacks to work is a bit premature.

AC because I'm a cowardly custard!

workarounds....

I agree that a properly designed system would render the workaround unneeded in this case, but even more curious is that the whole app would require to run constantly, and if that's the case, it would mean that the sensors would need to constantly output a signal for it to recieve. If that's the case, then what's the wake up for? If the app launches, then i see it, but if it is running continously, then i dont. and if you are going to turn the app on, why not just use it to silence the phone?

Maybe it's why i am not a coder.

Scripting phone fuctionality

Part of me thinks wow, that is actually an amazing feature to be able write scripts to define how the ringer/other functionality works. And the other part thinks, hmm that means surely that it might give another attack vector for doing malicious things.

Good grief people

a) Presumably the while true just adds the thing into the event loop, which can be killed by the system in standard ways.

b) Perhaps they'll introduce a blocking version of the sensor startup command as well, but if for now there's only one, you've got to prefer nonblocking to blocking, as you can simulate the latter with a sleep command, but you can't simulate the former.

If only

If only I could write some Java on my Blackberry for my Blackberry. All that time spent on the train/in the car/standing in queues/etc I could have written so many wonderful apps.

RIM are you listening?

@Chris C

You think that's logical? If I want to start sensor A, B and C, I've got to wait for each one to come on line before initiating the next? How about a scenario when I'm initialising the sensor for my app but don't require it immediately?

Sensible alternative ways to do it would be through an event listener or to poll the sensor until it started returning input.