On May 10, 2014 11:41 AM, <[email protected]> wrote:
> Today's topic summary > > Group: http://groups.google.com/group/android-developers/topics > > - Handling touch events inside a > listview<#145e4c1adb00dd20_group_thread_0>[2 Updates] > - Activity Back Stack and > OutOfMemoryError<#145e4c1adb00dd20_group_thread_1>[4 Updates] > - override earphone click button <#145e4c1adb00dd20_group_thread_2> [2 > Updates] > - Does the Android emulator run inside a > VM?<#145e4c1adb00dd20_group_thread_3>[3 Updates] > - Alarm Intent not triggered <#145e4c1adb00dd20_group_thread_4> [1 > Update] > > Handling touch events inside a > listview<http://groups.google.com/group/android-developers/t/6342592fee94ce84> > > dashman <[email protected]> May 09 10:41AM -0700 > > I've got custom views inside a listview. > > I've noticed that built-in widgets and other apps have a certain > behavior. > > 1. When an item is tapped (DOWN) to initiate a move - the item is not > hi-lighted (the listview starts to scroll) > > 2. When an item is held down for a little bit longer - then it's > hi-lighted. > > 3. Of course if it's a quick DOWN and UP - it's also hi-lighted. > > How can I get a similar behavior - notably the one in the 2nd entry > above. > > I'm doing this with a custom view items in the listview. > > > > > TreKing <[email protected]> May 09 01:07PM -0500 > > > > How can I get a similar behavior - notably the one in the 2nd entry > above. > > > I'm doing this with a custom view items in the listview. > > Your view's background should be a state-list drawable that defines the > drawables to use for the relevant states. > > > > ------------------------------------------------------------------------------------------------- > TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago > transit tracking app for Android-powered devices > > > > Activity Back Stack and > OutOfMemoryError<http://groups.google.com/group/android-developers/t/5fc3cadb4cbc48bc> > > Daniel Rindt <[email protected]> May 09 02:59PM +0200 > > > Are you absolutely sure that your code does not leak memory? > > How to be "absolutely sure". :-) Just kidding. > > > Have you tried using Eclipse MAT and putting the app through the > usual > > paces, like rotating the screen, pausing / restarting, etc.? > > This i have done: > * app started, before killed > * dump hprof and load with mat (leak suspects) > * rotate, rotate, rotate... > * dump hprof again load with mat (leak suspects) > > i compared the mat reports with the suspects and i see no differences > in the > "leak suspects report". Which sould differ in the occupied size when i > am not > wrong? > > > You'd mentioned the app being heavy on image processing -- is your > memory > > allocation strategy based on how much memory your app's process > gets? You > > can use ActivityManager#getMemoryClass for that. > > Actually i am aware of this complicated and consequences so i use the > universal image loader which is configured to scale the images exact > in the > bitmap which cost cpu time, but preserves memory. > > > Runtime.getRuntime().totalMemory() > > Runtime.getRuntime().freeMemory() > > ActivityManager.getMemoryClass() > > I am new to the memory thing, and it doesn't happen a lot. It happens > mostly on a rare ressource device. But question again starting lots of > activities > where you can go back should not be the issue? If the activity itself > isn't leaking > anything it can be gc'ed? The backstack just fire the intent again? > > > > > Kostya Vasilyev <[email protected]> May 09 05:53PM +0400 > > > "leak suspects report". Which sould differ in the occupied size when > i am > > not > > wrong? > > Well, personally, I usually use the object histogram at the starting > point > -- filtered by my app's package. > > When I see something that looks strange, I right click on a object > class > and do "merge shortest paths to object roots" to investigate. > > That's just me -- I've not used "leak suspects" -- but maybe you'd be > able > to see something interesting in the histogram? > > > > > Actually i am aware of this complicated and consequences so i use the > > universal image loader which is configured to scale the images exact > in the > > bitmap which cost cpu time, but preserves memory. > > That's a well known library, but I guess it still needs to be > configured in > a way that makes sense for your app's flow. > > > > > ActivityManager.getMemoryClass() > > > I am new to the memory thing, and it doesn't happen a lot. It happens > > mostly on a rare ressource device. > > > You can create an emulator image with lowered per-process memory > quotas. > Don't know if it actually works the way it's supposed to, but the > setting > is there. > > > > where you can go back should not be the issue? If the activity itself > > isn't leaking > > anything it can be gc'ed? The backstack just fire the intent again? > > There have been a few discussions on this list about it -- with no > clear > answer that I can remember. This should be fairly easy to verify in the > debugger. > > Maybe you can use the lifecycle callbacks (onStop / onStart) to release > some memory? > > -- K > > > > > Daniel Rindt <[email protected]> May 09 04:37PM +0200 > > > do "merge shortest paths to object roots" to investigate. > > > That's just me -- I've not used "leak suspects" -- but maybe you'd > be able > > to see something interesting in the histogram? > > I tried what you said, but please tell me what i can recognize as > "strange"? > I don't find a definitve guide to find a leak. I can't really see any > weird thing. > The only conclusion i come to is that every new opened activity > consumes > more heap and i have the feeling that this causes the oom. > > >> bitmap which cost cpu time, but preserves memory. > > > That's a well known library, but I guess it still needs to be > configured in > > a way that makes sense for your app's flow. > > I've set it for now just to preserve memory. > > > debugger. > > > Maybe you can use the lifecycle callbacks (onStop / onStart) to > release some > > memory? > > You mean set collections to null? > > > > > Kostya Vasilyev <[email protected]> May 09 09:52PM +0400 > > > "strange"? > > I don't find a definitve guide to find a leak. I can't really see any > > weird thing. > > Well, I usually look at instance counts of large objects that act as > allocation roots (e.g. allocate and own lots of other objects). In my > case, > they're fragments (more or less) and activities. > > For you app, you may want to dump total memory used by the image > loader / > cache -- although MAT won't help here. > > > > The only conclusion i come to is that every new opened activity > consumes > > more heap and i have the feeling that this causes the oom. > > An activity instance is not that heavy by itself -- but in your app, > sounds > like it also owns a fair amount of bitmap data. > > > > in > > > a way that makes sense for your app's flow. > > > I've set it for now just to preserve memory. > > Well, that sounds like a nice magic switch but personally, I would > verify > what actually happens to memory allocations. > > For example, would this library, with this setting, be able to get rid > of > in-memory bitmaps used by stopped activities? > > In ImageViews still attached to the content of their respective > activities? > > > > some > > > memory? > > > You mean set collections to null? > > Yes, that sort of thing, and verifying that it actually did something > (I'd > trigger GC in DDMS a few times, until it reaches a stable point). > > -- K > > > > override earphone click > button<http://groups.google.com/group/android-developers/t/7aca5fec6fccbff4> > > Sadhna Upadhyay <[email protected]> May 09 01:02PM +0530 > > Hi Guys, > can some one tell me that,can we override headphone functionality in > android 4+ version please let me know if any one have idea > > Thanks: > Sadhna > > > > > TreKing <[email protected]> May 09 11:22AM -0500 > > On Fri, May 9, 2014 at 2:32 AM, Sadhna Upadhyay > > > can some one tell me that,can we override headphone functionality in > > android 4+ version please let me know if any one have idea > > > You may want to explain what "headphone functionality" you're looking > to > override. > > > > ------------------------------------------------------------------------------------------------- > TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago > transit tracking app for Android-powered devices > > > > Does the Android emulator run inside a > VM?<http://groups.google.com/group/android-developers/t/a8cc31d98b3e1231> > > Charles <[email protected]> May 09 05:45AM -0700 > > Thanks, > > Yeah, it does work if I choose WXGA; RAM 512, heap 64; against latest > 4.4.2 > ARM/x86 images. Does takes a long time to load. > > On Wednesday, May 7, 2014 11:32:56 PM UTC-7, Ruud wrote: > > > > > Kristopher Micinski <[email protected]> May 09 11:15AM -0400 > > I remember doing this last year, I had to unlink some of the GL > drivers to get things to go through... I used a testing suite which > did GUI interaction and had no need to use UI. > > > Kris > > > > > > > Charles <[email protected]> May 09 09:14AM -0700 > > Right. Also, if you are using the SDK tools on 64 bit Linux, then > additional steps are necessary because the Android SDK was compiled > for > 32-bit systems. I used the following guides to figure out the 32-bit > libraries: > > * Ubuntu: > > > http://www.vogella.com/tutorials/AndroidInstallation/article.html#installation_linux64 > * CentOS: http://www.redips.net/android/emulator-fedora-linux/ > > On Friday, May 9, 2014 8:15:06 AM UTC-7, Kristopher Micinski wrote: > > > > Alarm Intent not > triggered<http://groups.google.com/group/android-developers/t/4236b5a5de27ff93> > > Sunil K <[email protected]> May 09 08:12PM +0530 > > No, made it work. But now the real problem is alarm is raised only > when my > activity is running, otherwise it will not. Currently trying to make my > alarm activity as background service but no luck still. > Any suggestion? > > > On Wed, Apr 23, 2014 at 10:57 PM, Raymond Rodgers > > -- > Thanks & Regards > **** Sunil ***** > > > > -- > 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] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Android Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
