A lot of people don't run into this because they don't work with services
running in other processes.  As a high level thing, I don't know what your
application is doing, but there are very few cases where you need to have
the service in a different process so if appropriate you might want to
consider just not doing that.  Keeping everything in the same process is
going to make your code 10x simpler since you can take a lot of shortcuts --
see the local service examples in ApiDemos.

On Tue, Mar 9, 2010 at 7:54 PM, Moto <medicalsou...@gmail.com> wrote:

> OK!
>
> So I used DDMS to capture the hprof from my leaky app using the
> registerCallback() and also of a non leaky by not using the
> registerCallback().  I was able to notice that my activity leaked it's
> context at every rotation. "Not too familiar with MAT ^.^"
>
> I tested just calling unregisterCallback() without ever calling
> registerCallback() and my app would leak!
>
> In short as I came to post that I ran upon Dianne's post and well it
> somewhat resolved the issue!  That was to make my callback function
> static!  So how is everybody else not running into this issue!?  I'm
> not doing something out of the ordinary according to the Android
> samples...
>
> So now I got to figure out how to call from those static functions...
> I'm one step closer!
>
> Thanks everyone!
>
> On Mar 9, 9:32 pm, Dianne Hackborn <hack...@android.com> wrote:
> > Keep in mind that if you are giving a reference to one of your objects to
> > another process, the lifetime of that object is at the mercy of the other
> > process (via the remote reference it holds on to it while it is using
> it).
> >  In particular, at the java level, the reference won't be released until
> the
> > other process does a GC.  For that reason, if your callback holds on to a
> > significant amount of state (like an activity), you might want to
> consider
> > using a WeakReference to hold the object the callback works with (and of
> > course make sure the callback is a separate class or static inner class).
> >  This will allow your big object to be GCed even if the callback is still
> > around.
> >
> >
> >
> > On Mon, Mar 8, 2010 at 3:31 PM, Moto <medicalsou...@gmail.com> wrote:
> > > Mark,
> >
> > > Yes, I'm using:
> > > final RemoteCallbackList<IRemoteServiceCallback> mCallbacks
> > >            = new RemoteCallbackList<IRemoteServiceCallback>();
> >
> > > to register my callback.  But I'm sure that RemoteCallbackList is not
> > > the issue since I completely removed the register and unregister calls
> > > and still have the leak issue.  So somehow one of the idls is leaking?
> > > Thanks for your help!
> >
> > > // ====================================================
> > >                // registerCallback(IRemoteServiceCallback)
> > >                // Info: Register callback
> > >                // ====================================================
> > >                 public void registerCallback(IRemoteServiceCallback cb)
> {
> > >                        if (cb != null) {
> > >                        //      mCallbacks.register(cb);
> > >                        }
> > >                }
> >
> > >                 // ====================================================
> > >                // unregisterCallback(IRemoteServiceCallback)
> > >                // Info: Unregister callback
> > >                // ====================================================
> > >                 public void unregisterCallback(IRemoteServiceCallback
> cb) {
> > >                        if (cb != null) {
> > >                        //      mCallbacks.unregister(cb);
> > >                        }
> > >                }
> >
> > > On Mar 7, 9:44 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> > > > Moto wrote:
> > > > > I start the service at onStart() and stop it at onStop()
> >
> > > > > // This is how I connect
> > > > > // Start Service
> > > > > this.startService(i);
> >
> > > > > // connect to service
> > > > > this.bindService( i, this, Context.BIND_AUTO_CREATE);
> >
> > > > You do not need to call both startService() and bindService(). The
> > > > Context.BIND_AUTO_CREATE parameter will cause the service to be
> started
> > > > if it is not already started.
> >
> > > > With respect to your leak, if you are convinced the problem relates
> to
> > > > the callback registration, you can use logging or breakpoints to
> confirm
> > > > that your code is actually getting called when you think it is, and
> that
> > > > the RemoteCallbackList (which is what I'm assuming you're using) is
> > > > cleanly getting emptied when you unregister.
> >
> > > > --
> > > > Mark Murphy (a Commons Guy)http://commonsware.com|
> > >http://twitter.com/commonsguy
> >
> > > > Android Training...At Your Office:http://commonsware.com/training
> >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Android Developers" group.
> > > To post to this group, send email to
> android-developers@googlegroups.com
> > > To unsubscribe from this group, send email to
> > > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com>
> <android-developers%2bunsubscr...@googlegroups.com<android-developers%252bunsubscr...@googlegroups.com>
> >
> > > For more options, visit this group at
> > >http://groups.google.com/group/android-developers?hl=en
> >
> > --
> > Dianne Hackborn
> > Android framework engineer
> > hack...@android.com
> >
> > Note: please don't send private questions to me, as I don't have time to
> > provide private support, and so won't reply to such e-mails.  All such
> > questions should be posted on public forums, where I and others can see
> and
> > answer them.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>



-- 
Dianne Hackborn
Android framework engineer
hack...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails.  All such
questions should be posted on public forums, where I and others can see and
answer them.

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to