They could save the wait on opening shelves by re-writing the code so that they retrieve the data necessary just to build the first page of shelf view, and then display it and then continue to process whatever it is they are doing that seems to take so long. It seems like they are processing something(covers? or just searching the whole database to round up a complete list of all titles they would need if they were going to display all pages of the shelf, if so silly. What if what you want is just a few pages in? Why process all that data first?) for all the titles that will open on all the pages of the shelf prior to displaying the first one! If so, DUMB.
The other question, and it's a good one, is why are those sqlite databases so large? Based on the size reported by one poster for a given number of books they are storing 40KB on average per book? What is all that, and is it why it appears accessing the DB takes so long? That's a lot of space to store a book title, path, current page, some reading stats, and some metadata... so what else are they bogging the Db down with? If it's annotations or the like, reference them by storing a path and filename and dump them into their own text files already.
These are portable devices, they should be lean and mean and so should the databases.
Last edited by TechniSol; 06-11-2013 at 04:43 PM.
|