You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: