[android-developers] GridView ImageView and performance
I've managed to successfully connect to the picasa web services using JSON and download a list of thumbnails from my picasa album. The thumbnails are all very small but I'm getting pretty terrible performance (especially when compared to the native picture viewer). As my main goal was getting the application working their is obviously lots of optimisation work I can do but I just wanted to know where the most likely cause of poor performance is coming from. Is it the memory usage (so I should try cleaning up existing objects) or is it display performance (can't cope with 30 thumbnails at once)? Example thumbnail image http://lh6.ggpht.com/_QIFTbqmwS8U/Samo30_xoBI/AEk/VeBxiukdKzU/s72/IMG_1759.jpg being loaded via Drawable.createFromStream Thanks in advanced. Ian --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: GridView ImageView and performance
Hi Gesh, Thanks for the response. I'll certainly give the bitmap factory a go. I'm currently using the ImageAdapter from the Hello GridView sample. But loading the images from the web rather than using resources. The problem is immediate, in that the performance doesn't degrade after re- visits to the activity, but is instead directly proportional to the number of images I'm displaying. As well as trying the bitmap factory can I ask what you think is the best way to encourage garbage collection? Will nulling my objects be a big help. Once I have it optimized I'm going to release it for free... I think there's a big hole in androids picasa support. Ian On Mar 14, 11:38 pm, Gesh wrote: > hi, > > I have written 2 connected apps with some image content pulled from > the web and must say if you handle your resources right it shouldn't > be a problem at all. > > Do you use your own Adapter for theGridViewor do you use some of the > already available ones in the SDK? If you use your own you should keep > in mind that when you deal with AdapterViews in general they keep > references to Views you create in your adapter and recycle them, so > try to reuse the convertView reference you get in the Adapter.getView > (int position, View convertView, ViewGroup parent) method. > > And although memory leaks are difficult to achieve in what sounds like > a single activity app the other thing that comes to mind is that you > might have memory leaks due to the way you use Drawables. Try using > Bitmaps from the BitmapFactory.decodeStream(InputStream) method and > maybe read this blog for more info why Drawables could cause memory > leaks > -http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks. > > cheers, > gesh. > > On Mar 14, 12:47 pm, ifuller1 wrote: > > > I've managed to successfully connect to the picasa web services using > > JSON and download a list of thumbnails from my picasa album. The > > thumbnails are all very small but I'm getting pretty terrible > > performance (especially when compared to the native picture viewer). > > As my main goal was getting the application working their is obviously > > lots of optimisation work I can do but I just wanted to know where the > > most likely cause of poor performance is coming from. Is it the memory > > usage (so I should try cleaning up existing objects) or is it display > > performance (can't cope with 30 thumbnails at once)? > > > Example thumbnail > > imagehttp://lh6.ggpht.com/_QIFTbqmwS8U/Samo30_xoBI/AEk/VeBxiukdKzU... > > > being loaded via Drawable.createFromStream > > > Thanks in advanced. > > > Ian --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: GridView ImageView and performance
p.s. when running the debugger I don't appear to be using anything like 16mb of the allowed heap space... wonder if it's something else - if I don't have any luck I'll post my (likely very poor) code up here. Thanks again. On Mar 14, 11:38 pm, Gesh wrote: > hi, > > I have written 2 connected apps with some image content pulled from > the web and must say if you handle your resources right it shouldn't > be a problem at all. > > Do you use your own Adapter for theGridViewor do you use some of the > already available ones in the SDK? If you use your own you should keep > in mind that when you deal with AdapterViews in general they keep > references to Views you create in your adapter and recycle them, so > try to reuse the convertView reference you get in the Adapter.getView > (int position, View convertView, ViewGroup parent) method. > > And although memory leaks are difficult to achieve in what sounds like > a single activity app the other thing that comes to mind is that you > might have memory leaks due to the way you use Drawables. Try using > Bitmaps from the BitmapFactory.decodeStream(InputStream) method and > maybe read this blog for more info why Drawables could cause memory > leaks > -http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks. > > cheers, > gesh. > > On Mar 14, 12:47 pm, ifuller1 wrote: > > > I've managed to successfully connect to the picasa web services using > > JSON and download a list of thumbnails from my picasa album. The > > thumbnails are all very small but I'm getting pretty terrible > > performance (especially when compared to the native picture viewer). > > As my main goal was getting the application working their is obviously > > lots of optimisation work I can do but I just wanted to know where the > > most likely cause of poor performance is coming from. Is it the memory > > usage (so I should try cleaning up existing objects) or is it display > > performance (can't cope with 30 thumbnails at once)? > > > Example thumbnail > > imagehttp://lh6.ggpht.com/_QIFTbqmwS8U/Samo30_xoBI/AEk/VeBxiukdKzU... > > > being loaded via Drawable.createFromStream > > > Thanks in advanced. > > > Ian --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: XML parsing
JSON handling is excellent on Android - is there a possiblity you could translate the xml at source to another format? On Mar 15, 5:59 pm, nowb wrote: > The java-app. that I´m trying to port is not only parsing xml, it´s > building up graphics from the xml (the xml is quite similar to xaml) > and it uses the DOM to do that. I guess I should have written that in > my first message. > > So I do have to work with the horrible old DOM :) > > Any suggestions? > > /Nowb --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: GridView ImageView and performance
Thanks gesh - as suggested the problem was related to recycling. Preformance is pretty good now, sadly my images keep shuffling but given your recent input this should be easy to fix. On Mar 15, 10:03 pm, Gesh wrote: > > I'm currently using the ImageAdapter from the Hello GridView sample. > > But loading the images from the web rather than using resources. > > I think you need a better understanding of how adapters work to solve > your problem. The getView() method of your Adapter is inkoved every > time an image in your grid becomes visible (yes, including when you > scroll back and forth to previously visible images). So if you have > just replaced that one line image.setImageResource(int) with > image.setImageDrawable(Drawable.createFromStream()) it means you are > re-downloading images every time they get scrolled into view. > > So you need to cache those downloaded images and while you are at it > make sure you cache scaled thumbnail of the image, just as big as you > need them to avoid the possible problem Romain suggested. Use > Bitmap.createScaledBitmap() - it's worked great for me. > > Also be aware that the emulator is running on your PC using that same > network speed. If you want to test for real network problems you might > get on a real device try starting the emulator with limited network > (or on your G1 disable wireless and 3G). I alwasy run my emulator with > network speed and latency set to EDGE, or for some debugging purposes > even GPRS or GSM. > > hope that helps you, > gesh. > > On Mar 15, 7:22 am, ifuller1 wrote: > > > Hi Gesh, > > > Thanks for the response. I'll certainly give the bitmap factory a go. > > I'm currently using the ImageAdapter from the Hello GridView sample. > > But loading the images from the web rather than using resources. The > > problem is immediate, in that the performance doesn't degrade after re- > > visits to the activity, but is instead directly proportional to the > > number of images I'm displaying. > > > As well as trying the bitmap factory can I ask what you think is the > > best way to encourage garbage collection? Will nulling my objects be a > > big help. > > > Once I have it optimized I'm going to release it for free... I think > > there's a big hole in androids picasa support. > > > Ian > > > On Mar 14, 11:38 pm, Gesh wrote: > > > > hi, > > > > I have written 2 connected apps with some image content pulled from > > > the web and must say if you handle your resources right it shouldn't > > > be a problem at all. > > > > Do you use your own Adapter for theGridViewor do you use some of the > > > already available ones in the SDK? If you use your own you should keep > > > in mind that when you deal with AdapterViews in general they keep > > > references to Views you create in your adapter and recycle them, so > > > try to reuse the convertView reference you get in the Adapter.getView > > > (int position, View convertView, ViewGroup parent) method. > > > > And although memory leaks are difficult to achieve in what sounds like > > > a single activity app the other thing that comes to mind is that you > > > might have memory leaks due to the way you use Drawables. Try using > > > Bitmaps from the BitmapFactory.decodeStream(InputStream) method and > > > maybe read this blog for more info why Drawables could cause memory > > > leaks > > > -http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks. > > > > cheers, > > > gesh. > > > > On Mar 14, 12:47 pm, ifuller1 wrote: > > > > > I've managed to successfully connect to the picasa web services using > > > > JSON and download a list of thumbnails from my picasa album. The > > > > thumbnails are all very small but I'm getting pretty terrible > > > > performance (especially when compared to the native picture viewer). > > > > As my main goal was getting the application working their is obviously > > > > lots of optimisation work I can do but I just wanted to know where the > > > > most likely cause of poor performance is coming from. Is it the memory > > > > usage (so I should try cleaning up existing objects) or is it display > > > > performance (can't cope with 30 thumbnails at once)? > > > > > Example thumbnail > > > > imagehttp://lh6.ggpht.com/_QIFTbqmwS8U/Samo30_xoBI/AEk/VeBxiukdKzU... > > > > > being loaded via Drawable.createFromStream > > > > > Thanks in advanced. > > > > > Ian --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: GridView ImageView and performance
I think my shuffling and your memory errors are related. My understanding at this point is the data being displayed in a view and the view itself really need to be separated. Recycled views are simply "other views of this type" - so using the view to hold/load its own content might result in several orphaned threads. As such it's best to load the content away from the view, and then simply use the view to display the content - all the examples seem to work in this manner, although I'm just unsure of how best to do it at this stage. Given how new I am at this I expect to be corrected very soon! On Mar 18, 1:44 am, Streets Of Boston wrote: > I had similar issues. I managed to fix the performance of the list- > view, but i ran into memory issues. > > My app downloads images from Smugmug, images that are 'front-page' > images of galleries/albums. > First, my app needed to get the information about the album, to get > the image-id of the album's front-page image. This would result in a > URL and then my app downloads the image using this URL and then shows > it in a list-item. > > I used the ExecutorService to fetch the necessary album information > and image-retrieval and image decoding in a limited number of > background threads. > > In the list-adpater's getView method, i would tag (setTag) the list- > item view with the album-id and submit a new (cancelable) task using > the ExecutorService (java.util.concurrent packages). This task > downloads the album info and then downloads the image. While the album > information and the image were downloading, i showed a place-holder > picture in my list-item's imageview (a bitmap from the res/drawable > directory) > > When the task that has been submitted finishes, it posts the result > back to the main-thread: Loop over the current list-view children > (which are the visible list-items). For each child get its tag > (getTag) and if this tag matched the task-result, i would set the > child's imageview's bitmap to the image i just downloaded. > > This all worked quite well, with images downloading at their own pace > and the list-view kept performing well. > However, at some point i got memory errors when calling > ImageView.setImageBitmap(Bitmap). I checked my code. I made sure to > recycle not-used bitmaps, i did not cache bimtaps, etc., but i kept > getting memory errors (note that the smugmug images downloaded were > small: 100x100 pixels). > > I was not able to solve these memory errors and i abandoned this idea. > Any ideas to prevent these memory errors? :-) > > On Mar 17, 7:28 am, ifuller1 wrote: > > > Thanks gesh - as suggested the problem was related to recycling. > > Preformance is pretty good now, sadly my images keep shuffling but > > given your recent input this should be easy to fix. > > > On Mar 15, 10:03 pm, Gesh wrote: > > > > > I'm currently using the ImageAdapter from the Hello GridView sample. > > > > But loading the images from the web rather than using resources. > > > > I think you need a better understanding of how adapters work to solve > > > your problem. The getView() method of your Adapter is inkoved every > > > time an image in your grid becomes visible (yes, including when you > > > scroll back and forth to previously visible images). So if you have > > > just replaced that one line image.setImageResource(int) with > > > image.setImageDrawable(Drawable.createFromStream()) it means you are > > > re-downloading images every time they get scrolled into view. > > > > So you need to cache those downloaded images and while you are at it > > > make sure you cache scaled thumbnail of the image, just as big as you > > > need them to avoid the possible problem Romain suggested. Use > > > Bitmap.createScaledBitmap() - it's worked great for me. > > > > Also be aware that the emulator is running on your PC using that same > > > network speed. If you want to test for real network problems you might > > > get on a real device try starting the emulator with limited network > > > (or on your G1 disable wireless and 3G). I alwasy run my emulator with > > > network speed and latency set to EDGE, or for some debugging purposes > > > even GPRS or GSM. > > > > hope that helps you, > > > gesh. > > > > On Mar 15, 7:22 am, ifuller1 wrote: > > > > > Hi Gesh, > > > > > Thanks for the response. I'll certainly give the bitmap factory a go. > > > > I'm currently using the ImageAdapter from the Hello GridView sample. > > > > But loading the images from the web rathe
[android-developers] Re: Serious bug in 3.2 ResolverActivity
Same problem on 3.2 on Asus transformer. On Aug 9, 2:22 pm, asqz wrote: > I have the same problem on Xoom with Honeycomb 3.2 > > On Aug 8, 6:55 pm, webmonkey wrote: > > > > > > > > > In Honeycomb 3.2 when you start an intent and there are multiple > > activities that are capable of handling the intent the > > ResolverActivity is displayed but it does not show the choice menu so > > the user is unable to do anything. This is quite a serious bug and I > > have got quite a few reports about it from users who have upgraded to > > 3.2. I have also confirmed the behavior myself using an Asus > > Transformer with 3.2 and Android Movie Studio. You cannot pick any > > media to insert because the Gallery/ File Manager won't open. > > > There are some solutions: > > > - Flip the device once to portrait orientation, after that, the menu > > does appear. Until you reboot. > > - If there is only one Activity that can handle the Intent or if you > > have set a default Activity for the Intent, it works because the > > ResolverActivity does not have to display the choice Menu. > > - If you use createChooser the choice menu is displayed successfully. > > > Can anyone confirm if this also happens with any of the 3.2 updates on > > the Xoom. -- 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
[android-developers] Re: Serious bug in 3.2 ResolverActivity
What does this mean? On Aug 18, 4:09 am, Gavin wrote: > It was fixed at latest version. -- 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
[android-developers] Re: com.google.wireless.gdata
Hi James, do you have the source for your modified gdatarequest and
abstract entity. I'd like to go a tried and tested route or just parse
the RSS manually. Am I right in thinking you've successfully connected
to a google service?
I'm pretty new to Java (c and as3 background) so I hope the questions
make sense?
On Jan 14, 3:11 pm, James wrote:
> I've been able to use the 1.0 version of the java gdata api
> successfully from Android. I created custom implementations of
> GoogleAuthTokenFactory and GoogleGDataRequest.Factory. The second one
> meant I had to create a custom GDataRequest and AbstractHttpEntity.
> The code needed utilizes the same apache http client library supported
> in the phone. My use is specific to the "print" or BooksService,
> Though I suspect that it would work in other services. Let me know if
> you're interested in more information. I noticed more than one
> code.google.com project focused at porting the gdata api to Android.
> The farthest along I found ishttp://code.google.com/p/android-gdata/.
> I'm hesitant to start yet another gdata-porting project -- yet none of
> what I found met my requirements. First on my list is using the same
> gdata public api. Second is unit tests. Here's one of my integration
> tests:
>
> @Test
> public void makeAuthenticatedQuery_usingCustomFactories() throws
> Exception {
> BooksService service = createAuthenticatedCustomService();
>
> VolumeFeed volumeFeed = query(service);
>
> Assert.assertNotNull("volume feed is not null", volumeFeed);
> Assert.assertFalse("volume feed has entries",
> volumeFeed.getEntries
> ().isEmpty());
>
> }
> private BooksService createAuthenticatedCustomService() throws
> AuthenticationException {
> HttpClient httpClient = new DefaultHttpClient();
> String serviceName = "print";
> BooksService service = new BooksService("app name", new
> CustomRequestFactory(httpClient),
> new CustomAuthTokenFactory(serviceName,
> applicationName,
> httpClient));
>
> service.setUserCredentials(username, password);
> return service;
> }
>
> On Dec 31 2008, 7:29 am, schtieF wrote:
>
> > Someone found the com.google.wireless code stuff in the open source
> > repository of android? so we can compile and include it in our
> > applications?
>
> > Stefan
>
> > On Dec 24, 6:21 pm, paxus wrote:
>
> > > OK, I agree that they could easily remove inner classes if it hasn't
> > > been published as common API. But I can't get what should I do to work
> > > with Gcalendar, for ex.? Can you show me the way? I can find several
> > > apps which somehow get calendar events, so there must be an API,
> > > right? Does anyone know a workaround?
>
> > > On 3 дек, 23:02, AndroidEngineer wrote:
>
> > > > Yet you had them in the previous version of the library? Uh huh. I
> > > > see.
>
> > > > On Dec 2, 10:42 pm, Jean-Baptiste Queru wrote:
>
> > > > > I'll try to simplify.
>
> > > > > In a nutshell, the com.google.* APIs are Google-specific add-ons that
> > > > > are not part of the Android core. Those APIs won't be present on all
> > > > > Android devices, and aren't ready to be officially supported as public
> > > > > Google-specific APIs.
>
> > > > > JBQ
>
> > > > > On Tue, Dec 2, 2008 at 10:27 PM, AndroidEngineer
>
> > > > > wrote:
>
> > > > > > It's wierd that even in the section where its supposed to describe
> > > > > > the
> > > > > > changes from 0.9 to 1.0 they don't have any mention of the apis that
> > > > > > have been removed. I am only hoping it was a mistake and the apis
> > > > > > are
> > > > > > going to be back.
>
> > > > > > Please enlighten.
>
> > > > > > On Dec 2, 12:33 pm, loty wrote:
> > > > > >> I'm also very much interested in these libraries. Can someone from
> > > > > >> Google enlighten us on when if ever these libraries become
> > > > > >> available
> > > > > >> again.
>
> > > > > >> On Dec 1, 11:27 pm, AndroidEngineer
> > > > > >> wrote:
>
> > > > > >> > Howcomecom.google.wireless.gdataand com.google.android.gdata have
> > > > > >> > been removed from the 1.0 r1 library. I see these packages in
> > > > > >> > 0.9 and
> > > > > >> > previous versions but not in 1.0. What is the reason behind
> > > > > >> > removing
> > > > > >> > the libraries? From what I've seen, they seem to be very useful
> > > > > >> > libraries.
>
> > > > > >> > Please give me heads up. I am trying to write an application to
> > > > > >> > access
> > > > > >> > google calendar and its events.
>
> > > > > >> > Thanks.
>
> > > > > >> > Android Engineer
--~--~-~--~~~---~--~~
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
and
