Ok so my application is basically an entertainment package which is used for Music Playback on the device The App fetches information for songs from the server(Song info ,Artist Info ,Album info ,Genre etc etc) and then shows it on the UI as different lists Ex All Songs List, Artsist,Inside Artists there are Albums and at end of each ListView leaf node is a song I am using a Single common ListView for each screen and at runtime changing the contents of ArrayAdapter to change contents of List. There are a few non list screens for which i am using setContentView and inflating those XML files. So basically from the replys i need to check for the leaks in memory for UI as well as putting things only in database and loading them as required I can actually load the data succesfully after its received from the server but its consuming almost 16 mb. The listview behaves very cool and fast to show the info just as it does for 100 songs. But ,later on i will get 30000 songs from the server ;) So i need a logic where i shd not waste much time in loading songs from the database . Also there is requirement of the Default Music App scrollbar where a user can directly jump to say song starting with X ,Y. So scrolling is a major concern here .. I know that this is becoming too heavy and i need to have a tradeoff between memory and speed :) Thanks, Alok.
On 3/24/10, Yahel <kaye...@gmail.com> wrote: > Hey Jonathan, > >> A few clarifying comments to Yahel > > Sorry, my answer was not really meant at you directly, more to the > original poster :) > Your app seems successful and to work the way you want so I wouldn't > dare tell I can do best :D > >> I guess it depends what the items are, but in my particular tree 95% of >> the lists are quite short and being sortabel should help a lot to get >> the particular PART of the list you are after. > > Still, even if it was a single letter or numbers, 1 000 entries is > just too much on a 3.2'' screen and for the resources of a mobile > device. > I strongly believe developers are here to take decisions on behalf of > their users. > > If your users can try to call for 30 000 entries and generate a OOM > then you are not doing your job. > And since I'm mean and everything I'm going to the market right now to > download your app and asks for the 30 000 items and then post a "your > app sucks"/One star rating :D > I'm just kidding I wouldn't do that :D > > >> No need for Flurry&CO - it is trivial to see in the web service log. > > And so what is the result ? How many of your users scroll down the 500 > item mark ? > > What is your app by the way ? > > Yahel > > > > On Mar 23, 3:34 pm, "Jonas Petersson" <jonas.peters...@xms.se> wrote: >> Yo again, >> >> A few clarifying comments to Yahel: >> >> Yahel wrote: >> > There is no way anyone is going to actually browse more than a few >> > hundred item in a list. Ever !! >> >> I guess it depends what the items are, but in my particular tree 95% of >> the lists are quite short and being sortabel should help a lot to get >> the particular PART of the list you are after. >> >> > Jim is right : Search & Pagination. >> >> In my case, that was already there. A nice side effect is that it is now >> easy to get a list of other products in the same category. >> >> > If your users are dumb enough to asks the full list and you are >> > actually going to do it, then implements a list like the android >> > market and fetch a 100 items at a time. >> >> Done done. (T-50 days) >> >> > I'm pretty sure if you use Flurry to check what your users are doing. >> > You'll find only one or two users sliding below 200 items. >> >> No need for Flurry&CO - it is trivial to see in the web service log. >> >> > And a user that asks you to get 30 000 items, is probably a >> > competitor that just wants to steal your database through your >> > webservice anyway :D >> >> Nah, 30000 was just the extreme case. The data is freely available >> anyway and it is continously updated, so stealing it is hardly an issue. >> The point of my app is to make is easily accessible on the phone (well, >> along with using GPS and barcode scanning etc to make it even more >> powerful). >> >> Best / Jonas > > -- > 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 > > To unsubscribe from this group, send email to > android-developers+unsubscribegooglegroups.com or reply to this email with > the words "REMOVE ME" as the subject. > -- 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 To unsubscribe from this group, send email to android-developers+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
