Have a look to the SchedulerManager in the BuzzBox SDK here:
http://hub.buzzbox.com/android-sdk/
It's a free library that simplifies using the Alarm Manager.
On Jan 19, 12:07 am, Danny S. danny.schi...@googlemail.com wrote:
Hi,
I have a service that is running in background. It needs to
Today I read this on googles documentation:
Broadcast Receivers listening for boot completed
The system delivers the ACTION_BOOT_COMPLETED broadcast before the
external storage is mounted to the device. If your application is
installed on the external storage, it can never receive this
broadcast.
Danny,
According to this:
http://developer.android.com/reference/android/content/Intent.html#ACTION_EXTERNAL_APPLICATIONS_AVAILABLE
The extra data EXTRA_CHANGED_PACKAGE_LIST contains a list of packages
whose availability changed. The extra data EXTRA_CHANGED_UID_LIST
contains a list of uids
Hey Kostaya,
wow, thanks. It seems I'll be forced don't support external storage.
There is really a conflict between the statements... I don't know such
missunderstandings by Google ^^
Thanks a lot for this Kostaya! You helped me so many times with
solutions and important information ;-)
-Danny
Hi,
for information:
I changed the android:installingLocation in the AndroidManifest.xml to
internalOnly and now the broadcast received successfully. Installing
the app on external storage was the reason like expected after I read
the docs.
-Danny S.
On Feb 2, 1:06 pm, Danny S.
OMG, today I determined, that my BootReceiver is not called
again :'( But I changed nothing in relation with this :( it looks like
an issue to me. I don't do anything in the onReceive yet, only log out
something. This morning it worked very well then I started to
implement code to start my
Hi,
I tried to implement a receiver that will be called when the device
booted:
receiver android:name=.AlertReceiver
intent-filter
action
android:name=android.intent.action.BOOT_COMPLETED /
receiver android:name=.BootCompletedBroadcastReceiver
intent-filter
action android:name=android.intent.action.BOOT_COMPLETED /
/intent-filter
/receiver
public class BootCompletedBroadcastReceiver extends BroadcastReceiver
{
@Override public
Danny,
You don't need a category in the filter to receive BOOT_COMPLETED,
just action. In fact, that's probably the cause of your code not
receiving it.
Also I don't see the other action in the manifest, for receiving your
own alarms.
-- Kostya
27.01.2011 16:00, Danny S. пишет:
Hi,
I
Hey Kostya,
you were right. I dont need to hold the intents in java, I can cancel
it this way:
mAlarmManager.cancel(PendingIntent.getBroadcast(this, intentId,
myBroadcastIntent, 0));
Thanks a lot for this!!! ;-)
-Danny S.
On 20 Jan., 10:33, Kostya Vasilyev kmans...@gmail.com wrote:
Danny,
Hi Kostya,
I removed the category, but have still the same issue: boot completed
is never recognized. You said you dont see the other action. I create
the Broadcast- Intent and put it into PendingIntent.getBroadcast(),
without a action in AndroidManifest:
...
alertReceiverIntent = new
Danny,
Your app's manifest for the broadcast action, as well as the permission,
look fine.
When you start the emulator, make sure you don't have Wipe user data
enabled, as that will erase the application, so it won't be available at
boot.
Other than that, maybe you're just not seeing the
Kostya,
yeah, I am with you and think my AndroidManifest looks correct. I
figured out too, that all data get lost when Wipe user data is
enabled. I started the emulator always without Wipe user data but it
does not work. Maybe it is an emulator problem... I can try to figure
out on my real device
Hi together,
using a second receiver worked for me:
...
receiver android:name=.AlertReceiver /
!-- only for device is booted detection: --
receiver android:name=.BootedReceiver
intent-filter
Good Morning!
Wow, you helped me to get it work. I create a PendingIntent with a
unique id and store the intent mapped to their IDs in a HashMap. I
collect all intents with the known id and can the cancel them using
the AlarmManager. I dont know if it is recommended and efficient to
store those
Danny,
Android already keeps a global registry of pending intents, so keeping a
parallel hash map should not be necessary.
To cancel an alarm, you don't need a reference to the original Java
object, you can just construct a pending intent the same way as you did
when setting the alarm
Hello Kostya,
WOW, thank you very much, I'll have a look and reply with results and
questions if I have ;-)
-Danny S.
On Jan 19, 9:09 am, Kostya Vasilyev kmans...@gmail.com wrote:
19.01.2011 10:07, Danny S. пишет:
Hi,
I have a service that is running in background. It needs to send
Hi,
the AlarmManager is exactly what I need. It works fine, but I don't
figured out yet how to set more than 1 alarm on a AlarmManager.
I am using a BroadcastReceiver to receive that is called if the
scheduling time is reached. First I forgot to add the receiver- Tag in
the AndroidManifest.xml
Danny,
The issue with multiple alarms comes up quite often, this is one of
several responses:
http://groups.google.com/group/android-developers/browse_thread/thread/57d0d40c542db6cc
-- Kostya
19.01.2011 19:09, Danny S. пишет:
Hi,
the AlarmManager is exactly what I need. It works fine, but
19 matches
Mail list logo
