Well, it sounds to me like a bug then. I guess check the bug tracker
to see.
On Apr 8, 3:00 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
