I haven't been able to find an Android app for Brickset, so have started writing one myself. It's primarily for viewing/updating wanted/owned sets etc, but might be updated to do other things.
Before I get too far into development, is this anything that anyone thinks would be useful? Or is there an existing app that does this already?
If I finish development and make it available I'm planning on keeping it free, but donations would of course be gratefully accepted (to buy a Google Market licence, fuel my Lego addiction, put food on the table, etc!).
There's a copy of the current version available here
. You'll need to allow installation of 3rd party content to run it.
The app doesn't do much at the moment (allows you to login, remembers your details for next time, shows owned minifigs & sets etc) but it's a good proof of concept. Bear in mind it's a pre-alpha release, but it's stable enough on my SGS. Images are cached, but everything else requires an internet connection (may eventually cache limited data so it can be referenced offline).
Please let me know if you have any ideas for development, maybe how to rework the interface so it's not just a bunch of buttons, or if there's anything you'd like to see in there. New names are accepted (don't want to stick with 'myBricklink' unless the app becomes good enough it gets officially affiliated) as are icons for the app if anyone's a graphic artist (currently using a minifig head I found on the web).
In terms of the Brickset side of it, just access to the database and maybe even an option to fully cache or at least cumulatively cache the set info would be great. I've found myself at WMs in nowhere-ville where I can't get data service when I'm trying to look up set info to see whether it is worth buying sets on sale.
I have a droid incredible and will try grabbing the app tomorrow and playing with it as a test on another hardware platform.
Caching the whole database is something I'd definitely like to do, for exactly the reasons you said. It shouldn't be too hard once I've got it working fully against the live database (of course, I could be wrong..).
Thanks for testing the app, don't expect too much out of it yet though as it's still at the proof of concept stage.
It still requires an internet connection (no offline browsing yet), but is much more mature than the previous proof of concept. The set database can be queried, and there are shortcuts for owned and wanted sets & minifigures. Sets & minifigures can be updated too (wanted, owned, qty owned).
No price information is shown for the sets, as the webservice doesn't include any. I've yet to see if I can access this information another way (I don't really want to scrape webpages).
To save hammering the database, I cache all images locally on the SD card (/Android/data). As some images are large (>100kb) this can quickly eat up space so I'll look later at either limiting the max cache size or reducing the size of cached images (but this will obviously reduce quality).
I've tested against Samsung Galaxy S (Gingerbread, 2.3.6) and Asus Transformer Prime (ICS, 4.0.3). It should work fine on all devices from Donut (1.6) onwards.
I messed up when exporting the apk, I've reposted and it should work now (have just tested on a clean handset).
Anyway, the connection to the internet is a restriction in the current version which is more of a proof of concept. Full offline browsing is on the way..
The app is almost ready for public release, possibly limited initially to more technical people willing to download & install the apk manually before being published on Google Market.
As it's going to include a full mirror of Brickset (many, many thanks to Huw for letting me do this) it includes almost 30MB of thumbnails. I'm trying to figure out the best way to distribute these, and have come up with 3 solutions:
1. Include them as part of the apk. Nice and easy, no performance issues for the user but each update will also include all the images so this could result in a lot of wasted bandwidth over time. If total images increase by about 20MB, will have to move to another solution.
2. Ship them separately (will auto download) so they only download once and use Google's recommend method to access them on the fly. Minimises the amount of data downloaded, but leads to approx 60 seconds whenever the app is started before images can be accessed (as Android is mounting the zip file for random access).
If you have Wi-Fi on, images will download on-demand so you can still see them whilst the data is mounted, but this can lead to wasted space (as there'll be two copies of the files). If Wi-Fi is not on, you'll just see a placeholder image until the mount operation has completed.
3. Ship them separately (will auto download) so they only download once and extract them to SD for instant access in the future. Minimises the amount of data downloaded, but extracting images takes several minutes during which time not all images will be available (and about 10 seconds before any are). If Wi-Fi is on, images will be downloaded on-demand to the same location to minimise duplicate files. Does end up with 30MB wasted space on the device though, as the images will still remain in their compressed format as well as extracted on the SD. Would have to code this so that if the operation is cancelled (user closes the app), extraction resumes rather than starting again from scratch.
4. Just thought of this, a hybrid of 2 & 3. Once the file has mounted, extract images to SD but whilst they're extracting load images from the file on the fly (obviously, there'll still be the 60 second delay whilst the file is mounted).
Can you give me your ideas on which of the above you'd prefer? None of them are ideal, but seem to be the best I can do with the current API. I'm leaning towards (1) atm but am open to input.
The question then is - when an update is made to the brickset database (i.e. a new product is added) do the users have to download the entire archive file of thumbnails etc or just an update containing the new/modified files? If all files, go for  if not then go for .
I think I'm going to go with (1) for now, simply because it's quicker to code/test and I can get a build out sooner (and 30MB bandwidth is nothing to most people now with always on broadband). Was hoping to have it ready for public beta by Friday but that's going to be doubtful because I've got lots of non-app work to do this week.