Open GoogleCodeExporter opened 9 years ago
[deleted comment]
Sounds like a good idea.
In practice this would mean to disconnect from the server when the application
receives a "pause" signal and reconnect when it receives a "start". These
signals are
the only way to detect a background state. The reconnect would result in some
delay
(1-4s, depends on phone) when bringing Remuco to the foreground. AFAIK there is
no
more elegant power saving possibility in JavaME-Bluetooth.
Usually the "pause" signal gets triggered when the application is "minimized"
or when
a phone call comes in. I'm not sure if this also works for screensaver - for
sure
every device has its own behavior here :/ .
Original comment by obensonne@googlemail.com
on 4 Feb 2010 at 11:01
I think that disconnecting will be not very usable. Maybe try to pause data
stream
but not disconnect from server? Like BT handsfrees - they are always connected.
Original comment by yaroslav.khomyak@gmail.com
on 5 Feb 2010 at 10:51
This is possible too, but does this significantly save power? Do you know of
some
(approx.) numbers of BT energy consumption when transmitting something and when
holding a connection?
Original comment by obensonne@googlemail.com
on 5 Feb 2010 at 2:00
For example, my BT handsfree can be always connected to the phone, power
consumption
is almost unsensible when idle.
Another example - I have Nokia Suite installed on my laptop, which connects to
the
phone everytime I'm nearby. But that idle connection doesn't impact phone's
battery life.
So I think that holding a connection is a right idea.
Original comment by yaroslav.khomyak@gmail.com
on 5 Feb 2010 at 2:59
AFAIK bluetooth consumes energy only when transmitting/receiving data
Original comment by yaroslav.khomyak@gmail.com
on 5 Feb 2010 at 3:09
This issue was updated by revision 3c6a1b003e.
When the JavaME client receives a pause signal, it stops pinging the
server and sends a SLEEP message to the server. The server then stops
to send update messages (except BYE) to the client. Later, if a resume
signal arrives in the client, it re-enables pinging and sends a WAKEUP
message to the server which then restarts to send player information to
the client.
When pause and resume signals arrive in the client is completely up to
a phone's Java-VM. Usually it works for incoming phone calls or when the
client app get's 'minimalized' manually. Don't know if it works for
screensavers.
@yaroslav.khomyak:
Could you please test this? See
http://code.google.com/p/remuco/wiki/BleedingEdge for some instructions.
Original comment by obensonne@googlemail.com
on 7 Feb 2010 at 6:01
How's the status on this one?
Currently i'm closing the connection on pause/resume cycles in the Android
Client.
Original comment by fha...@gmail.com
on 16 Feb 2010 at 10:17
Hi!
I had broke my linux server installation, so I can't test this feature by now.
As
soon as I will bring up my server, I will test it.
Original comment by yaroslav.khomyak@gmail.com
on 17 Feb 2010 at 7:59
@fhaust:
The commit linked in comment 7 explains it quite well. 2 new message types are
used
to tell the server that a client enters or leaves the "sleep" mode. Sleep mode
simply
means the connection is kept up, but no messages are transferred.
Basically the Android client should do this
On pause event:
Connection conn = ...getConnection();
conn.setPing(0);
Message m = new Message();
m.id = Message.CONN_SLEEP;
conn.send(m);
On resume event:
Connection conn = ...getConnection();
conn.setPing(<previous/configured/hardcoded value>);
Message m = new Message();
m.id = Message.CONN_WAKEUP;
conn.send(m);
Original comment by obensonne@googlemail.com
on 17 Feb 2010 at 6:58
Original comment by obensonne@googlemail.com
on 8 Mar 2011 at 6:38
Original comment by obensonne@googlemail.com
on 8 Mar 2011 at 6:42
Original issue reported on code.google.com by
yaroslav.khomyak@gmail.com
on 4 Feb 2010 at 9:44