Thanks for good thoughts! What I did not explain was that my idea is to eventually publish my app. Then servers of other users will be returning data to the app - and possibly returning much more data (list items). I do not have access to a "huge" worst-case data-source and I do not know how to simulate one.
Here is where my questions arose: Is there a way to find a suitable "happy medium" without trial and error testing on a huge database? Some reflections on your ideas: - Prefetch and cache: It would be perfectly ok for the user to wait a few secs for "loading" at application startup. I have been thinking about reading the complete data from the server, and filling a background array of custom data-objects with it. Then the listView could be fed and filled from the background array independently of what the user-selection might be (different content depending on selection). However, I get back to the same question: How do I know there is enough memory to hold the complete background array, and if not - what the "happy medium" is? - Reusing: If only enough items for one display is loaded (added to the ArrayAdapter) - won't this then interrupt the nice sliding feel / momentum feel of the scrolling listview? - XML: No plans for XML, however, the data returned by the server is a huge long URL-encoded text string, So after parsing out the single elemnts with String-methods, I am currently using the URLDecoder-class and the decode-method to get the pretty-printed strings out. I do not see a way around this. - Load and decompress in a non-UI thread: I understand what you mean, and also sense this might be a good solution. Though, I do not have any idea how to begin with this. Links to any guidelines would be appreciated. Thanks! /Andy On 24 Juni, 19:33, "Yusuf T. Mobile" <yusuf.s...@t-mobile.com> wrote: > Hi Andy. Some ideas are: > - implement the simplest design first (i.e., load everything into > memory) and profile early and often > - iff (if and only if) and wherre (where and only where - I made that > one up:) it croaks, some possible optimizations are: > - don't put thousands of items on one list. Sublists may be an > alternative. > - prefetch and cache data - especially the images, rather than > loading them real-time from URLs. Loading everything is in theory the > most efficient, but may make the user wait at first, which ruins > responsiveness. Depending on the data characterization and use cases, > you will have to find a happy medium. > - reuse objects rather than incur the cost of memory allocation > and GC. For example, if you have a custom list item class, only create > as many as are needed to display on the screen, and update their data > as the user scrolls up and down, rather than creating lots of new ones > and abandoning old ones as the user scrolls. > - don't use XML, it has many advantages, but bandwidth and parsing > efficiency are not among them. Use a streaming (rather than tree) > parser, with a compressed protocol. Google's protobuf may be an > option. > - load and decompress in a non-UI thread. You don't have to wait > until everything is loaded and decompressed to show something, you can > do so selectively depending on what the user is looking at and may > soon be looking at. > > Yusuf Saib > Android > ·T· · ·Mobile· stick together > The views, opinions and statements in this email are those of the > author solely in their individual capacity, and do not necessarily > represent those of T-Mobile USA, Inc. > > On Jun 23, 2:06 pm, Andy_Sthml <andreas.sc...@gmail.com> wrote: > > > > > This is mainly a design question : > > > My app connects to a server from where data is retrieved and presented > > in a listview. Depending on user-selection different data is retreived > > and filled in the list. A typical list item consists of a text string > > of up to some 50 or 60 characters depending what the server returns. > > Additionally, a small image icon is shown next to each string. The > > server may return any number of items from 0 up to many hundred or > > even thousands. It is possble to ask the server to iteratively return > > subsets of the content. The images are actually links to http- > > addresses, but I guess this still requires/allocates memory for the > > listview by Android. > > > How do I design for efficiency and responsiveness, considering memory > > consumption? > > Are there any generic guide lines on how many list items, Strings or > > Bytes to keep in memory? > > > On the one hand I would like to have as many items in the list as > > possible - from a users perspective *all* items returned from the > > server would be expected. On the other, sending many queries to the > > server makes the app slower. I am not sure how to handle this > > situation since I do not have a feel for what android can handle in > > terms of memory. > > > Any ideas would be of help.- Dölj citerad text - > > - Visa citerad text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
