Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Weapons & vehicles - the backstory #46

Open
karllindmark opened this issue Apr 30, 2012 · 0 comments
Open

Weapons & vehicles - the backstory #46

karllindmark opened this issue Apr 30, 2012 · 0 comments

Comments

@karllindmark
Copy link

The dilemma

Weapons & vehicles have a lot in common on Battlelog - not only the format, but also the data and how they're built up. On Battlelog, weapons & vehicles show some stats already at the list of these, but in-app it becomes an important decision. Let me break it down below:

Alternative a

Weapons & vehicles are loaded from the website, and can display accurate "ministats" for the user in the listing, but takes a lot longer (~6-10 seconds) to load the actual list of weapons (even on WLAN). This means that the user can't by any means reach a single weapon/vehicle view (via the list) before the data has been retrieved from Battlelog itself.

Alternative b

Weapons & vehicles are loaded from a local SQLite database, and while they can't display minor stats or anything similar - it will load pretty much instantly and enable the user to view a single weapon within a second.

Which alternative would be the best?

For me, I could easily go with the b as I'd probably be looking for a specific weapon, however I do see the use of the stats too. One could probably argue that a is the way it should be done, but given the massive JSON that needs to be 1) downloaded and 2) parsed, it just won't cut it if you ask me.

The perfect solution would be...

...if we could store the weapons & vehicles (including their perks and addons) locally in the SQLite for a faster initial load, but add the stats to the display whenever it's done loading. My guess is that it wouldn't be too hard, looking at the way ProfileActivity works with the caching, but a few changes would have to be done to the wrapper classes in question so that they can distinguish themselves in the list adapters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant