I agree.
I moved my unregister call to onDestroy, which pushed the exception
back a little, but I too have it eventually throw the exception
always.
Devin Dow
On Apr 7, 10:56 am, "jim.renkel" <[EMAIL PROTECTED]> wrote:
> I agree with Dan about the logical ordering of things and programmed
> my service accordingly.
>
> Unfortunately, I get the errors that Jakob reports. I've tried the
> other order, same result. It was there with the M3 SDK, and is still
> there with both versions of the M5 SDK. And it happens every time I
> shut down my service, not randomly.
>
> I think there's a solid bug in Android here.
>
> Jim Renkel
>
> On Apr 6, 1:29 pm, "Dan U." <[EMAIL PROTECTED]> wrote:
>
>
>
> > 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 -- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
