Office Hours — Today, November 29

← Tuesday, November 22

Nov 29
7:25 PM
Mark M.
has entered the room
Mark M.
turned on guest access
7:30 PM
Ron T.
has entered the room
Mark M.
howdy, Ron!
how can I help you today?
Ron T.
Hello Mark, thought I'd give this a try. I have a couple of questions regarding my app and Wakelocks
Mark M.
fire away!
Ron T.
I have a multiple activity app with a standalone background service (non-binding). I have one activity that can be launched from the service. that activity needs to be running if the device is in 'sleep' mode...
I have declared at the top of the app:
View paste 
// Wakelock
private PowerManager myPM;
private WakeLock myWakeLock;


    public void onCreate(Bundle savedInstanceState) {
        /** Called when the activity is first created. */   	
        super.onCreate(savedInstanceState);

        myPM = (PowerManager)this.getSystemService(Context.POWER_SERVICE); 
        myWakeLock = myPM.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakeLock"); 
        myWakeLock.acquire();
Mark M.
um, this can't be in the "top of the app"
7:35 PM
Mark M.
do you mean "top of the activity"?
Ron T.
I will do the Wakelock release in the onDestroy. This seems to work fine and eliminate the problems I had before. Is this the proper way to use wakelocks? (OOPS, top of activity!)
Mark M.
well, it's not what I'd do
Ron T.
What do you recommend?
Mark M.
first, for activity-level keep-the-screen-on stuff, I'd use android:keepScreenOn
that's an attribute you can put on any widget in a layout
so long as that widget is around, the screen stays on
Ron T.
Customer does not want the screen on all the time (I tried that)
Mark M.
well, either it's on or it isn't
you said the screen should be on
now you're saying the screen should not be on
which is it?
ok, wait a moment
Ron T.
What they like to do is a momentary depress of the Power button. Also, if the screen times out. The real issue is that the activity has a timer going that must run until the user exits the activity. If the screen times out, the timer MUST continue!
Mark M.
what does it mean to you for an activity to be running without the screen being on?
then the timer shouldn't be part of an activity
that's what your service is for
Ron T.
Here is more...
The activity is launched by the service which informs the activity that it needs to notify the user. The activity will display a notification in its own view and give the user the option to acknowledge. It starts a timer to nag the user to acknowledge. The nag is vibrate and beep. The nag must continue if the screen is off!!
7:40 PM
Mark M.
then the "vibrate and beep" should be done by the service
in particular, your current approach means the CPU will never turn off if the user presses HOME while your activity is on-screen
Ron T.
Yeah, I thought about retro'ing it to the service but.. the activity can also be launched by a C2DM Receiver.
Mark M.
then the C2DM receiver should be notifying the service, not starting the activity
rephrasing a previous point, the device's CPU will stay on for possibly hours, until Android destroys the activity
and, since I haven't tested leaking a WakeLock and having my process be terminated, if Android does *not* call onDestroy(), you might be in bigger trouble
I assume Android does the right thing there, otherwise lots of people are in trouble, but it's something I need to research someday
Ron T.
We have been considering an architecture change but it has 95% of the functionality with the current evolved design. We tested the HOME issue with the wakelock and it works fine.
Mark M.
well, you asked for my opinion, so I'm giving it to you... :-)
7:45 PM
Ron T.
No Problem! I'm looking for other ideas. The client views this as a 27/7 app and is always running. Once this activity is on, it is the users responsiblity to acknowledge it (button press) at which point I finish the activity.
OOPS 24/7!
Mark M.
blech
don't much care for everlasting services
users care for them even less
Ron T.
If I move the nag to the service, won't that still use CPU?
Mark M.
sure
anything using a WakeLock keeps the CPU on
but usually partial WakeLocks are used by background things
like services
Ron T.
The only other concern I have is that since the activity can be launched from my service and also from a C2DM receiver, is the Wakelock implementation I have sufficient or does there need to be some sort of 'overlap'?
Mark M.
what is causing the service to be executing code at the time when it decides to display the activity?
(e.g., AlarmManager?)
Ron T.
It has posted a REST service push request. It will hang on the REST request until a message appears or it times out. In the event of time out, I just re-issue the REST request.
7:50 PM
Ron T.
Essentially it is our version of C2DM!
Mark M.
um, that doesn't make much sense, unless you are keeping the CPU on 24/7
yeah, well, C2DM had to go through some pains to get that to work without keeping the CPU on all the time
regardless
you need to be acquiring a WakeLock *immediately* upon receiving the REST message
Ron T.
PS: my Service holds a partial wakelock as well.
Mark M.
um, when, and for how long?
Ron T.
Now, I acquire it on service start and release it on stop.
Mark M.
There is no "on stop" in a service
Ron T.
it's in onDestroy
Mark M.
when is the service ever being destroyed?
7:55 PM
Ron T.
it runs all the time except when the activity is launched. The activity issues a stop while it is waiting for the user to acknowledge the notification. When the activity finishes (user presses button), it restarts the service.
Mark M.
is this device powered by a battery?
because you are effectively saying you are keeping the CPU on all the time -- either the service holds a WakeLock, or the activity does
which means the battery life will be pathetic
if this is a normal phone or tablet
Ron T.
The attractive thing about C2DM when we started it was that it would 'wake up...' But we can figure out if that meands waking up the app or waking up the device.
Both phones and tablets.
Mark M.
C2DM will wake up the device and send a broadcast to your receiver
your receiver needs to acquire a WakeLock before doing much else, though, as there is no guarantee that the device will stay awake
the objective with WakeLocks is to use them for seconds, not weeks
having a service with an always-acquired WakeLock is evil
Ron T.
This led me to various Googling session regarding the definition of 'sleep' and how I found your posts...
8:00 PM
Mark M.
AFAIK, Android only has one sleep level
certainly, that's the case in terms of the SDK
we've been told that sleep mode on an Android device powers down the CPU
Ron T.
We can disable my service and currently rely on C2DM but when the user selects 'sleep' mode from the power menu, we do NOT see C2DM waking up the device!
Mark M.
whether that's really true, or if it goes into some ARM C-level sleep state, I can't say
there is no "sleep mode" in the power menu of any Android device I have ever used
which is about 20 or so
Ron T.
Yeah, my biggest grip is that there is no formal specification for 'sleep'. Either it needs to be an Android specification or something at the Mgr level.
Mark M.
um, OK
Ron T.
I have a DROIDX running 2.3.3, when I long press the power button I get a context menu with: 'Silent Mode', 'Airplane Mode', 'Sleep', 'Power Off'.
Mark M.
you'd have to ask Motorola
I would expect that to just do the same as a simple tap on the power button
which turns off the screen
and eventually will lead the device to sleep mode
during which time C2DM definitely still works
Ron T.
Don't get me wrong, I would like to architect to improve battery life. Since this is my first Android app, I'm assuming all the difficulties on my side.
8:05 PM
Ron T.
As far as the C2DM receiver, do I need a wakelock in it?
Mark M.
yes
there is no guarantee how long you will stay awake
the only place where there *is* a guarantee is if you are using AlarmManager, and have the PendingIntent you schedule set to send a broadcast
then, and only then, Android will guarantee that the device will stay awake, long enough for the onReceive() call to complete
C2DM, AFAIK, is not using AlarmManager for this
(there's a presentation from the 2010 Google I|O conference that goes into details)
so, if you're doing much of anything, I'd nab a WakeLock long enough to get that work done
and then release the WakeLock ASAP
Ron T.
Right now, both my service and my C2Dk receiver are launching the activity with regular intents. I'm not up on the Pending Intent use.
Mark M.
you don't need PendingIntents there
in my description above, that was related to AlarmManager, and the one scenario where Android guarantees that your device will stay awake
when your C2DM receiver gets control, there is no guarantee how long the device will stay awake
if you need a guarantee, acquire a WakeLock
Ron T.
In the C2DM receiver, if I get a wakelock at the top of the onReceive and release at the bottom of the onReceive then would it be enough til the onCreate of the activity fires?
Mark M.
no
because startActivity() does not take immediate effect
the activity will not even begin to start up until after onReceive() ends
8:10 PM
Ron T.
Yeah, that is what I thought. Can I define a wakelock that is public, i.e. spans those events?
Mark M.
yes, carefully
Ron T.
Any complete code examples out there anywhere?
Mark M.
I recommend reading up on AlarmManager and WakefulIntentService in your copy of _The Busy Coder's Guide to Advanced Android Development_
WakefulIntentService has an implementation of the handoff pattern, with WakeLock management
while WakefulIntentService itself is not necessarily relevant for your use case, understanding what it does and why will help you apply the same sort of pattern for your scenario
Ron T.
I remember seeing the WIS code there but it seemed to be out of my skill set. I hear alot about Alarm Manager but not sure how to use it in this case, namely we don't schedule anything.
Mark M.
I feel like I'm saying the same thing several times
you do not need AlarmManager
I repeat: you do not need AlarmManager
you do not need to *use* WakefulIntentService
Ron T.
Just wanted to make sure (my boss and the client keep saying I do)
Mark M.
it will help you understand how to solve your problem if you understand how WakefulIntentService works
and, who knows, your boss and client may be rigth
er, right
nothing in what you have written here screams "AlarmManager" to me
however, I don't know your whole app
8:15 PM
Mark M.
the C2DM-starts-an-activity scenario is just not terribly common
if there's more than a couple dozen apps in the world that do that, I'll be surprised
hence, you need to learn to triangulate techniques
WakefulIntentService shows you how to have a WakeLock span components -- in that case, BroadcastReceiver to a Service
you can, in principle, apply the same technique to your BroadcastReceiver to Activity scenario
along the way, you'll learn about AlarmManager, not so much that you absolutely need it, but that it's tied up in the WakefulIntentService coverage
Ron T.
The big thing is that once a notification comes in either through my service or C2DM, my obligation is to wake up the device/app and present a screen to the user with nagging until it is taken care of.
Thanks for the info! I've got enough to continue on for now. I had thought about attending your NY class but could not schedule it!
Mark M.
there's an NYC class every two months
DC ones should be starting up again soon as well, on the opposite months
Ron T.
Also, we may still want to contract you as per my email a couple of days ago. I do like this chat feature and I'll try not to newbie you to death! Thanks again. over and out!
Mark M.
thanks, and have a pleasant day!
Ron T.
has left the room
8:30 PM
Mark M.
turned off guest access

← Tuesday, November 22

 

Office Hours

People in this transcript

  • Mark Murphy
  • Ron Thomas