hmmm. i'd suggest not killing any processes. the problem would be if under normal OS usage, the alarm is not activated. i can't say i understand exactly how the OS handles alarms, but perhaps forcefully killing processes interrupts it's workings.
On 10/30/09 4:04 AM, marc wrote: > jeffrey, how did you solve the problem? > i made a own process for the broadcastreceiver (as said in the linked > theme), so i have 2 processes now: > cycle: > 1. user starts application > 2. user schedules the alarm in the application > > current processes: > - application > > 3. scheduled alarm expires, broadcastreceiver will be started > 4. broadcastreceiver execute his work and SCHEDULES A NEW ALARM > > current processes: > - application > - broadcastreceiver > > 5. scheduled alarm expires, broadcastreceiver will be started > 6. broadcastreceiver execute his work and SCHEDULES A NEW ALARM > > > if i kill the application after step 2, the scheduled alarm survives. > if i kill the alarm after step 4. the scheduled alarm is lost, step > 5/6 will not be executed. > > how did you do it?! > > thank you for a answer. > marc > > > On Sep 13, 12:33 am, Jeffrey Blattman<jeffrey.blatt...@gmail.com> > wrote: > >> well, i found this,http://code.google.com/p/android/issues/detail?id=2886 >> >> works for me now. >> >> On 9/12/09 2:00 PM, Mark Murphy wrote: >> >> >> >> >>> Jeffrey Blattman wrote: >>> >> >>>> mark, "perhaps some sort of service" is a little vague. >>>> >> >>> Generally speaking, if your manifest-registered BroadcastReceiver will >>> be doing things that are short (say, under a second), you won't need one >>> -- just do all your work in the BroadcastReceiver. >>> >> >>> If you are going to do things that may take longer than that, such as >>> uploading something via the Internet, you'll need to delegate that work >>> to a service that can do things in a background thread (e.g., >>> IntentService). A manifest-registered BroadcastReceiver cannot fork a >>> thread, and it is called on the "UI thread", which does not support >>> time-consuming operations. >>> >> >>>> the AM schedules an alarm that calls a receiver that does three things, >>>> >> >>>> 1. updates some data that is shared with the activity >>>> >> >>> You don't indicate where, but I'm going to assume the data is on the >>> device, not the Internet. >>> >> >>>> 2. sends notifications >>>> 3. broadcasts back to another receiver that updates the activity, if >>>> it's running (the activity registers / unregisters the receiver in >>>> onResume(), onPause(), so it doesn't get called if it's paused or stopped). >>>> >> >>>> i *could* have the scheduled BR call a service like in your example, but >>>> why can't i just have the scheduled BR do the work? >>>> >> >>> Assuming #1 above is not too time-consuming, you can. >>> >> >>>> why would that make >>>> a difference as to whether the BR is being called or not, which is the >>>> root of my problem? >>>> >> >>> In my first reply, I wrote: >>> >> >>> "You could encounter that behavior if you registered your >>> BroadcastReceiver via Java, instead of via the manifest." >>> >> >>> You never stated, in any of your messages, how your code sets up your >>> BroadcastReceiver. And, since the only way to really use AlarmManager >>> effectively is to use a BroadcastReceiver registered via the manifest, I >>> have been trying to steer you in that direction. >>> >> >>> If I am correct, and presently your alarm-catching BroadcastReceiver is >>> registered via registerReceiver() in some Java code, then that will only >>> respond to alarms so long as whatever contains it (e.g., activity) is >>> running. In this case, change your application logic to have the >>> BroadcastReceiver be its own standalone public class (vs. an inner class >>> of something else), dump the registerReceiver() and unregisterReceiver() >>> calls for it, put it in the manifest via a<receiver> element, and see >>> if that improves your results. The example I have been pointing you to >>> demonstrates receivers registered this way. There are a few other >>> examples of this technique in the SystemEvents set of projects. >>> >> >>> If you *do* have your BroadcastReceiver registered via the manifest, >>> though, and you're not getting the alarms, then something else is afoot. >>> >> -- >> > -- -- You received this message because you are subscribed to the Google Groups "Android Beginners" group. To post to this group, send email to android-beginners@googlegroups.com To unsubscribe from this group, send email to android-beginners+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-beginners?hl=en
<<attachment: qr-gmail.png>>
