Add items from DD API feed #1
Conversation
jnovinger
commented
May 1, 2016
jnovinger
commented
- Use okhttp to retrive JSON data
- Use gson to parse JSON into usable objects
- Modify ListActivity to use feed data rather than static list of string
- Use okhttp to retrive JSON data - Use gson to parse JSON into usable objects - Modify ListActivity to use feed data rather than static list of string
|
@moagrius , this is the next bit I've got working. I still feel like this is kind of jumbled/disorganized, but I think I'm just not sure about the Java methodology yet. As always, would appreciate any feedback you might have. Next up are working with more interesting views for the items in the list (with a small image and better formatting) and a |
| @Override | ||
| public void run() { | ||
| list.remove(item); | ||
| list.trimToSize(); |
There was a problem hiding this comment.
Derp, didn't mean to commit this. Was experimenting, trying to understand why used memory was increasing when a click was handled and an item removed.
I'm guessing it has something to do with GC not needing to run and new, anonymous Runnable instances being created, just to be used and thrown away. I suspect that if the list was long enough and available memory reached a certain level, a GC would occur and reclaim this memory.
There was a problem hiding this comment.
Yep, I upped the number of articles to load by default to force a larger allocation and then interacted with the activity to force more usage. As soon as it ran out of memory, it GC'd and was happy again.
There was a problem hiding this comment.
you can force a GC with System.gc() - it's not 100% reliable and shouldn't be used to try to free up memory (which is pointless) but is very handy for seeing what your app is doing
There was a problem hiding this comment.
Ah, good to know. I think just having access to the view of memory in use excited me. This is the same behavior I'd expect in Python, I just don't usually work with the tooling to watch memory usage in real time.
There was a problem hiding this comment.
yeah that's exactly when i use System.gc - lets say I'm doing some crazy bitmap manipulations, but i think I'm managing memory correctly - say we're on a modern tablet with a large heap - we decode the bitmap (memory), scale it (memory, memory, memory), then we made a BitmapRegionDecode (because we only want to show a part of it) (MEMORY!!!), then we return the small piece we want to show (memory), then we exit the stack (end of function, as we return the small bitmap) - we look memory monitor it probably shows 118 being used out of the 120MB we have available (because of all that bitmap allocation), but since that memory is available for GC (since we left that method's stack), if we now run a System.gc (to emulate what would happen if the system needed more memory than was available at the moment), we'd probably see that monitor dip back down to single or double digits... yay!
that all said, even if we do get to reclaim it, there's still heap limits for devices: http://stackoverflow.com/a/9940415/429430, so while we may think "oh this is temporary (on the stack), no problem", if we actually run out of memory before we're done, we'll crash - even if we catch the OOME, we'll still fail to create that small bitmap we wanted... memory management is a bitch :/
There was a problem hiding this comment.
Oh, this is awesome, thanks!
I've always wanted to work in more constrained environments. I think this will be a fun challenge at times and a good way to set any app I do apart from others in (from a quality perspective).
