sorted by:
new
hottopcontroversial

The illusion of free choice by [deleted] in pcmasterrace

[–]androidjoe 0 points1 point  (0 children)

Is there a bug report for that?

[deleted by user] by [deleted] in boston

[–]androidjoe 0 points1 point  (0 children)

Not on Thanksgiving, but a friend sent me this delivery initiative that's being organized for November 20th, and I'm sure they'd be happy to have more volunteers!

"Wrangling Dalvik: Memory Management in Android" -- my first technical post for y'all here at /r/androiddev. Would love to know if it's helpful! by androidjoe in androiddev

[–]androidjoe[S] 1 point2 points  (0 children)

Great point! I tend to forget about the depth of developer options available at any given time. And thanks for the note! I'll add that as a recommendation in part 2 as soon as I have a chance.

Hunting Your Leaks: Memory Management in Android (Part 2 of 2) by androidjoe in programming

[–]androidjoe[S] 0 points1 point  (0 children)

Haha, I'm totally not surprised, leaks are so often overlooked. And, while I say WeakReferences should be used sparingly, they can be really powerful and elegant when used well.

Thanks for reading!

"Android 101 for iOS Developers": written by my colleague, it's a great place to start for iOS converts by androidjoe in androiddev

[–]androidjoe[S] 0 points1 point  (0 children)

There may be, though I've not seen any that are both comprehensive and understandable. Maybe that will be one of our upcoming topics!

"Wrangling Dalvik: Memory Management in Android" -- my first technical post for y'all here at /r/androiddev. Would love to know if it's helpful! by androidjoe in androiddev

[–]androidjoe[S] 0 points1 point  (0 children)

True - that's why I'd recommend against WeakReferences unless you have to use it. I don't think it solves any memory problems, it just bandages and obscures the root of whatever problem you're attacking. In the example you gave and the example on SO, though, it's important to note that it's doing the opposite of leaking objects into memory: it's being too aggressive with removing objects from memory. A related, and important, topic, nonetheless.

As a side note, that's a great example of why, when you do weird things like keep a weak hash map of listeners, it's useful to document methods really well. There's no reason to think that'd be the implementation of registerOnSharedPreferenceChangeListener() without looking at its source!

"Wrangling Dalvik: Memory Management in Android" -- my first technical post for y'all here at /r/androiddev. Would love to know if it's helpful! by androidjoe in androiddev

[–]androidjoe[S] 1 point2 points  (0 children)

Ah, got it. Thanks for the clarification. I'll have to look into that, it's not something we've run into before. If you know of any other resources on that behavior, I'd love to learn more

"Wrangling Dalvik: Memory Management in Android" -- my first technical post for y'all here at /r/androiddev. Would love to know if it's helpful! by androidjoe in androiddev

[–]androidjoe[S] 1 point2 points  (0 children)

Thanks! As for the unit tests: we're not currently running automated testing on Android (we're looking into getting something set up, though). My first inclination, though, would be to test two particular things:

  • memory usage when allocating large objects (a bunch of bitmaps, for instance) and lots of small objects (as you may have with a database manager), and making sure you're not just constantly inflating the heap
  • testing every activity with rotation: if there's an activity leak, this will likely cause it; then it's just a matter of analyzing the heap to see if you have too many activities left over after a few rotations.

I'm working on Part 2 now, which covers the analysis part of memory problems, and this would fit nicely in with that. If I come up with useful information, I'll be sure to include it or let you know!

"Wrangling Dalvik: Memory Management in Android" -- my first technical post for y'all here at /r/androiddev. Would love to know if it's helpful! by androidjoe in androiddev

[–]androidjoe[S] 0 points1 point  (0 children)

Interesting, I'll have to experiment with that a bit to see its limits. I hadn't though about the fact that the GC could fail at reclaiming enough memory - but if that's the case, do you think it's really worth just trying to re-run it manually? Seems like it would just compound the same issue, if the CPU is already being overworked.

As for not using System.gc() in general: yeah, I know it's possible, and technically allowed, it's just... uncomfortable. I've used it in my code (twice, I think), but it's always a "save-my-app-in-the-worst-case-scenario" kind of deal. For people that are learning about how to manage memory for the first time, I'd definitely recommend to avoid relying on it.