The firing between those calls is a race condition. If you notice, the
location manager updates in the emulator get fired off in rapid
succession if you give a small interval value. There is enough time
between an unregisterReceiver call and a removeUpdates call for this
to happen.
In terms of designing it, I suppose it would be nice for it to not
fail (or really do anything) once the last receiver is unregistered.
But that is probably there to give us an indication that there's
something sending out updates, but nothing there to receive them.
Think about it in terms of an email. You are the LocationManager. You
send someone an email. That person is the IntentReciever. Whether they
are have a valid e-mail account is determined by the registerReceiver
call. As long as they have that valid account, you can send them email
and they will respond somehow. But, lets say they disabled their
account and didn't tell you. That's the equivalent of calling
unregisterReceiver. As long as you don't make a removeUpdates call,
you'd still send out an email and you'd expect to have it bounce back
or else you'd think everything is fine.
And yes, you are right about the documentation. Some of it is hit and
miss. You may want to look for info outside of the official docs. I'd
guess anddev should have a good tutorial and there may be one in the
andbook. There will also be a book coming out soon which will have a
good discussion on this topic, but it won't be available for awhile.
On Apr 6, 6:34 am, Jakob Bjerre Jensen <[EMAIL PROTECTED]>
wrote:
> Hi Dan,
>
> From what you explain, I can see, why the problem might arise (still
> being a bit suspicius
> about how the firing can happend between the two consecutive calls,
> but alright, it might occur).
>
> However I might disagree with the whole design semantic, unless you
> can convince me otherwise
> (which I of couse will be happy to accept given good arguments!):
>
> Consider the situation where two IntentReceivers A and B are
> registered for updates (activity.registerReceiver()
> called twice).
>
> Now the class A no more wants notifications, hence it calls
> unregisterReceiver(). No call to removeUpdates()
> since class B still wants notifications. Now the other class B also
> wants to unregister. However in this situation,
> since it is the last registered IntentReceiver class, it must first
> call removeUpdates() and then unregisterReceiver in
> order to avoid the problem, you described. This in my view, is
> problematic.
>
> Also in my original code I registered an IntentReceiver by first
> calling locationManager.requestUpdates, then calling
> activity.registerReceiver.
> Following your argument, this might also be subject to problems, if
> the location manager fires between the two calls, right? Hence
> the correct order for registering is first calling
> activity.RegisterReceiver at least once (to be sure that there is an
> IntentReceiver, once I
> call requestUpdates), then call requestUpdates?
>
> I might have got the whole concept about location manager and
> IntentReceivers wrong. But at least I hope you agree, that the
> documentation
> is not very clear on the subject.
>
> Best regards,
> Jakob Bjerre Jensen
>
> On 6 Apr., 01:23, "Dan U." <[EMAIL PROTECTED]> wrote:
>
> > Sounds like you are thinking backwards in terms of when things
> > happen.
>
> > Lets say I unregistered the receiver, but have not made the
> > removeUpdates call. The location manager does not know this, and still
> > sends out an update. Being that there are no more registered receivers
> > for that update, it can't do anything but complain.
>
> > However, if have only made the removeUpdates call, no more updates are
> > sent. The receiver just sits there doing nothing at this point.
>
> > Actually, in your original code, I could see it working part of the
> > time. If removeUpdates were to get called before the location manager
> > fired another update, not having a receiver registered wouldn't
> > matter.
>
> > On Apr 5, 3:56 pm,JakobBjerreJensen<[EMAIL PROTECTED]>
> > wrote:
>
> > > Hello Dan,
>
> > > Thanks for your answer, which seems to solve the problem. However to
> > > me the logical order is
> > > first to call unregisterReceiver(ir) (saying this specific ir instance
> > > is no more interested in notifications),
> > > then calling removeUpdates() (saying skip all notifications to me).
>
> > > Is that the correct interpretation/semantics of the calls?
>
> > > Could you please tell me, why the other order of calls work?
>
> > > I don't feel confident unless there is an explanation to this (which I
> > > hope there is).
>
> > > Best regards,
> > >JakobBjerreJensen
>
> > > On 5 Apr., 22:02, "Dan U." <[EMAIL PROTECTED]> wrote:
>
> > > > If I have some time, I'll look into it more, but for now, have you
> > > > tried to reverse the order of these calls:
>
> > > > activity.unregisterReceiver(ir);
> > > > locationManager.removeUpdates(new Intent("test"));
>
> > > > On Apr 5, 3:20 am,JakobBjerreJensen<[EMAIL PROTECTED]>
> > > > wrote:
>
> > > > > Hello,
>
> > > > > I have an IntentReceiver IR, which I register as follows:
>
> > > > > locationManager.requestUpdates(..., new Intent("test"));
> > > > > IntentFilter filter = new IntentFilter();
> > > > > filter.addAction("test");
> > > > > IR ir = new IR(...);
> > > > > activity.registerReceiver(ir, filter);
>
> > > > > This works excellent. However doing my unregistration as follows:
>
> > > > > activity.unregisterReceiver(ir); // ir = same concreate class
> > > > > instance
> > > > > as above
> > > > > locationManager.removeUpdates(new Intent("test"));
>
> > > > > still seems to produce broadcasts, which results in an error with
> > > > > message
> > > > > "Error receiving broadcast null in IR".
>
> > > > > What is wrong with my unregistration code, and what is the correct
> > > > > way?
>
> > > > > Also, should'nt it be enough just to call
> > > > > locationManager.removeUpdates(new Intent("test"))? Basically this
> > > > > says: "Don't inform me of any kind of broadcast from that location
> > > > > manager anymore".
>
> > > > > Best regards,
> > > > >JakobBjerreJensen- Skjul tekst i anførselstegn -
>
> > > > - Vis tekst i anførselstegn -- Skjul tekst i anførselstegn -
>
> > - Vis tekst i anførselstegn -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
