Sorry for the delay in responding -- I haven't been able to keep up
with the volume lately -- and I'm amazed at how well you do.
On Jul 6, 12:47 pm, Dianne Hackborn wrote:
> On Mon, Jul 5, 2010 at 11:56 PM, Bob Kerns wrote:
> > Actually, they CAN return different Application objects, and are
>
On Mon, Jul 5, 2010 at 11:56 PM, Bob Kerns wrote:
> Actually, they CAN return different Application objects, and are
> actually documented to do so, if you read it carefully.
>
Well I wrote the functions and looked at the code to double-check, and as
intended they return the Application singleto
Actually, they CAN return different Application objects, and are
actually documented to do so, if you read it carefully.
I don't think it's exactly a bug that they do -- but I do think the
platform would be improved by removing getApplicationContext() from
the public API somehow. Perhaps by deprec
The getApplicationContext() should return return the same Application object
as getApplication()... however, they do go through slightly different
code-paths (the Activity has its Application handed to it during
initialization, while the base Context implementation needs to retrieve it
for its pac
On Jun 21, 11:03 am, Nathan wrote:
> True enough.
>
> In the case I am using it, I would be happy with an activity context
> *if* Google Analytics would not hold on to it, causing a huge memory
> leak and subsequent crashes.
>
> Nathan
>
> On Jun 21, 10:46 am, Bob Kerns wrote:
>
I have gotten
True enough.
In the case I am using it, I would be happy with an activity context
*if* Google Analytics would not hold on to it, causing a huge memory
leak and subsequent crashes.
Nathan
On Jun 21, 10:46 am, Bob Kerns wrote:
> My claim is that it is always incorrect but will usually work. (A b
My claim is that it is always incorrect but will usually work. (A bad
combination!) I've raised the issue many times, and nobody, from
Google or otherwise, has come up with an example of when it is correct
to use it. (Unless I missed it, which is possible, but I think the
reason is simply there is
I hope some Google engineers can way in when and when not to use
getApplicationContext().
I use it all the time for getting a context that isn't tied to an
activity life-cycle, which - as i am now learning - may be incorrect.
On Jun 20, 9:06 pm, Bob Kerns wrote:
> You should read the documentati
You should read the documentation for getApplicationContext(), and not
simply believe what the name says.
It does NOT, repeat, NOT, return your application. Well, it might, but
it might not.
"Return the context of the single, global Application object of the
current process. This generally should
On Jun 19, 5:45 pm, Mark Murphy wrote:
> Well, as I wrote:
>
> "A number of GUI-related things fail outright if you use
> getApplicationContext() instead of an Activity, for example."
>
> Off the top of my head, I can't name any specific methods. Resources
> don't map right, IIRC, and you can't
On Sat, Jun 19, 2010 at 8:37 PM, Streets Of Boston
wrote:
> "I ask only because the Application object returned by
> getApplicationContext() is a bit brain-dead in terms of being a
> Context"
>
> Not to hijack the thread, but which things do fail? I assume that the
> call to tracker.start takes a
"I ask only because the Application object returned by
getApplicationContext() is a bit brain-dead in terms of being a
Context"
Not to hijack the thread, but which things do fail? I assume that the
call to tracker.start takes a Context as parameter and
getApplicationContext() is a proper Context.
On Jun 18, 3:51 pm, Mark Murphy wrote:
> On Fri, Jun 18, 2010 at 6:43 PM, Nathan wrote:
> > In the short term, I've replaced:
> > tracker.start("UA-YOUR-ACCOUNT-HERE", this);
> > with
> > tracker.start("UA-YOUR-ACCOUNT-HERE",
> > this.getApplicationContext());
>
> Have you confirmed that
On Fri, Jun 18, 2010 at 6:43 PM, Nathan wrote:
> In the short term, I've replaced:
> tracker.start("UA-YOUR-ACCOUNT-HERE", this);
> with
> tracker.start("UA-YOUR-ACCOUNT-HERE",
> this.getApplicationContext());
Have you confirmed that you actually get the analytic data after this
change? I a
I found the culprit. It is Google Analytics.
Warning to others, if you follow the instructions for Google Analytics
as described here, you will get a context leak:
http://code.google.com/mobile/analytics/docs/android/#startingTheTracker
Using the find path to GC, I found that the tracker, a sing
So far I'm still getting multiple activity instances. I've succeeded
in saving some expensive objects by nulling out references in
onDestroy
So I haven't stopped a leak but I'm slowing it down.
Nathan
--
You received this message because you are subscribed to the Google
Groups "Android Develope
On Jun 18, 6:56 am, Streets Of Boston wrote:
> Stopping a thread does not necessarily garbage collect them...
>
> Put your references to your background threads/async-tasks inside an
> object that you pass back with onRetainNonConfigurationInstance and
> call getLastNonConfigurationInstance in y
On Jun 18, 3:58 am, Mark Murphy wrote:
> On Thu, Jun 17, 2010 at 11:43 PM, Nathan wrote:
> > Are anonymous inner classes okay?
>
> Yes, so long as they are only referenced by the Activity (or things
> related to the Activity).
>
That's been my assumption. I'm hard pressed to find anything that
Stopping a thread does not necessarily garbage collect them...
Put your references to your background threads/async-tasks inside an
object that you pass back with onRetainNonConfigurationInstance and
call getLastNonConfigurationInstance in your onCreate().
If the android getLastNonConfiguration r
After thinking I made a major breakthrough by stopping that thread, I
still find that Activity Instances stack up.
I'll still need to analyze all the inner classes.
Nathan
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this g
While my inner classes could be wrong, I have a bigger suspect.
It seems one of my custom views has a background thread that waits for
work requests and communicates back through a handler. When the
activity ends and restarts, the thread is still alive, waiting for a
work request. Since that threa
21 matches
Mail list logo
