Android App

RikTheVeggie

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).

-Richard

caperberry

The most useful thing for buyers would be something which gives you the cheapest way of buying your wanted lists. @atxdad has now developed this, but in an environment called Matlab, which not many people have. He has asked that others help by making an exe version, but an Android app version would be pretty great. The thread about it is here.

RikTheVeggie

Thanks for the input. When the app is complete, if I have the time I'll take a look at porting the Matlab scripts to a Windows app or Android (there are some retired sets I'd like to build, hoping it's cheaper to buy the bricks than a complete set).

graphite

^^ I'm going to guess that it is highly unlikely at this point that any of the phones out there have the processing power to handle the number crunching for doing what the matlab scripts do. Maybe for 1 or 2 vendors but once it gets to 3 it is going to chew up a 1ghz processor and eat battery life like there is no tomorrow.

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.

RikTheVeggie

Yeah, I'm planning on writing any Bricklink based app on Windows first then only port it to Android if the speed seems ok (I'll write the guts in C++ rather than Java, plus I've got a background in AI and optimising apps).

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.

RikTheVeggie

The latest version is now online here.

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.

Si_UKNZ

My ph is enabled for third party apps and I keep getting app not installed msgs

RikTheVeggie

Thanks for testing.

I messed up when exporting the apk, I've reposted and it should work now (have just tested on a clean handset).

andhe

If I have to be connected to the internet, why would I not just use the brickset website?

RikTheVeggie

Maybe you're away from a PC and using the phone is easier than a website on a phone?

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..

Steve_J_OM

Offline browsing would be spectacular. At the moment I can't think of anything that m.brickset.com doesn't fulfil, but I look forward to the updates.

RikTheVeggie

Your help needed!

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.

cheshirecat

[2] is no good - 60 seconds is far too long to wait each time you run the app. [4] seems redundant as [3] would be far better - I don't mind waiting a few minutes the first time I use an app.

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 [1] if not then go for [3].

RikTheVeggie

Thanks for your input cheshirecat. Updates to the db are done in the background without having to redownload a new db & imageset, the problem only comes when upgrading to a new version (with bugfixes, new functionality, etc).

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.