A small correction *At end of each List, on the leaf node there is a list of Songs and not a single song..One thing i found out using HeirarchyViewer (or in the layout XML file itself) that the depth of the layout is 5 to 6 for some screens.So i need to resttructure that as well as i have read about the Inflation Cost increasing exponentially with the depth. Thanks, Alok.
On 3/24/10, Alok Kulkarni <[email protected]> wrote: > 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 <[email protected]> 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" <[email protected]> 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 [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 >> >> 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 [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 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.
