Thank you for visiting the BlackBerry Support Community Forums.
BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)
BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.
"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."
- Kevin Michaluk, Founder, CrackBerry.com
Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.
04-22-2010 03:48 PM
I have a question just to pick at the genius minds on this forum and gather your thoughts.
What would be the best way to implement the retrieval of a long array list or list to the blackberry device from a database? When I say long I am referring to a list of around 60,000+ schools and objects containing their detail information to go with it.
I am looking for the best and smartest approach so any insight would be helpful.
Solved! Go to Solution.
04-22-2010 04:35 PM
Is this from an SQLite database on the phone or a database on a server somewhere?
In either case, the answer, I think, depends in large part on why you are retrieving the data. To save for future use? To process each record independently and be done with it? To summarize it? Do you need to access the records randomly, or is sequential access in the order they arrive good enough?
Too many unknowns to have my genius picked at.
04-22-2010 05:12 PM
Thanks for the reply.
Im Sorry I was very vague in my explanation.
Basically the application works with an API to communicate and call on a SQL Server 2008 database. It will search for a large list of databased schools, 60000+, and bring that data on the phone. What I want to try to avoid is an extreme lag in the amount of time it needs to display on the device, so optimization is a must.......thats particularly why I am looking for input on such an approach.
thanks again for your quick response, it is much appreciated.
04-22-2010 05:19 PM
To bring down 60,000 records via HTTP is somewhat problematic: (a) the user will not want to wait for it, and (b) you may not have room for the data on the device.
A more "wireless friendly" approach would be to pass some parameters that bring down the part of the list you are working on at the moment, or to implement some type of paging operation to bring the list down a chunk at a time.
04-22-2010 05:54 PM
I agree with RexDoug. You surely don't want to present 60,000 records to the user all at once. Even with no detail (just a dot on a map, for instance), there would be too much data to be of any use.
In addition to "chunking" the communication load, you should also take a close look at moving as much work as possible to the server. So, for instance, any results that require access to a significant number of records should be done server-side if possible. Even if a calculation requires combining database records with data only available on the device (such as GPS coordinates), the device data can be sent to the server to be crunched, rather than sending (pieces of) the database to the device.
It may mean that you have to compromise on your application's requirements: some functions that would be do-able with a local copy of the database just won't be available if there isn't any connectivity.