Rich's comments on GLA Implementation
Posted: Mon Sep 20, 2010 12:26 pm
On Fri, Sep 17, 2010 at 8:23 PM, Rich [last name withheld] [email address withheld] wrote to the GLA team: (edited to leave out references to statements made exterior to this thread)
I am new to [Gospel Library for Android (GLA)] (but not Android) so feel free to correct/steer me if I misunderstood the implementation intent, here are some personal observations my first walk through that address some of Tom's requests at design level. Below are some ideas or things we can look at when balancing conflicting design trade-offs of 'more generic cross-platform LDS content publishing' server side & maintaining native Droid format(s) for 'time to display', 'small footprint of local-data-at-rest' & 'CPU optimization' on the device side:
1. Currently ScriptureProvider.downloadContentDB pulls in a Droid specific SQLite DB and stashes it in /sdcard/ldsscriptures.##.db along with some index files in a separate directory - There appears to be no actual data conversion going on when the original monolithic Droid content is downloaded & stored on the sdcard, (correct me if I am wrong)
- Does it make sense to augment the content importing methods on the Droid itself? (in either ScriptureProvider or DownloadService) with 'one-time' conversion methods to massage more generic published material into optimal android.webkit formats 'after' the content is initially
downloaded and 'before' it's pushed into the Droid's persistent store (SQLite DB), e.g. BEFORE the user even knows the content is there...
2. Also appears the SQLite DB is pre-populated with compressed scripture strings which are uncompressed by ContentInflator and re-dressed into Droid webkit friendly HTML for each book+chapter+verse+page access with a background task unzipping and prepping surrounding chapters that may or may not be viewed
- Can this be optimized? I know decompression is generally faster than compression, so the decompression may not be perceptible...
- But storing webkit enabled content could help and utilizing webkits cachemanager would offload a bunch of code when displaying or predicting content that will be viewed next
- I agree a look-ahead or predictive cache loader is something that should be implemented specifically for the GL ScriptureViewActivity.
- Implementing an historical view cache manager, could be offloaded though
- Doesn't look like we are using android.webkit.CacheManager, does it not work with local URI's? Or am I missing something??
3. I guess a concern over data size (wireless bandwidth & device storage usage concerns - I expect) is causing nested compression unnecessarily, one-time GZIP compression for OTA distribution should be good enough, need to evaluate what an uncompressed scripture strings in SQLite DB would look like. Most droids are shipping with a 2 or 4GB sdcard, I believe GL has more headroom for static DB store much bigger than 18.857MB (ldsscriptures.21.db current size)
4. To support generic published XML content received from LDS.Org (zip or gzip'd compressed) could/should have imperceptible performance changes to the end user so long as GL stays with a background download, local data conversion to a suitable SQLite local store and ultimate webkit rendering. Most folks don't mind long one-time initial downloads and conversion so long as it is done in the background & view/search is snappy once the content gets there
5. Republishing a new monolithic DB as [GLA] adds more dynamic & segmented content like various conference text, LDS mag text, church music, select video and keeping coherent cross-references means the content management flow on the device needs an update
- I would guess the best approach is to provide the user 'settings' to control how much of the GL is sync'd to their device
- Yep I just swapped over from looking at [Mormon Channel for Android (MCA)] and asked about the overlapping feature concerns...
- [MCA] is the polar opposite of [GLA] in terms of caching. [MCA] relies heavily on dynamic web-pull & web-cache to display content
- [GLA] is almost entirely focused on local store content at the moment
- Does a shared Droid webkit extension between the [GLA] & [MCA] approaches make sense? Seems a waste that [MCA] needs [GLA] features and [GLA] needs some of [MCA] features.
Thanks for entertaining a long email from an uninformed new guy...
I am new to [Gospel Library for Android (GLA)] (but not Android) so feel free to correct/steer me if I misunderstood the implementation intent, here are some personal observations my first walk through that address some of Tom's requests at design level. Below are some ideas or things we can look at when balancing conflicting design trade-offs of 'more generic cross-platform LDS content publishing' server side & maintaining native Droid format(s) for 'time to display', 'small footprint of local-data-at-rest' & 'CPU optimization' on the device side:
1. Currently ScriptureProvider.downloadContentDB pulls in a Droid specific SQLite DB and stashes it in /sdcard/ldsscriptures.##.db along with some index files in a separate directory - There appears to be no actual data conversion going on when the original monolithic Droid content is downloaded & stored on the sdcard, (correct me if I am wrong)
- Does it make sense to augment the content importing methods on the Droid itself? (in either ScriptureProvider or DownloadService) with 'one-time' conversion methods to massage more generic published material into optimal android.webkit formats 'after' the content is initially
downloaded and 'before' it's pushed into the Droid's persistent store (SQLite DB), e.g. BEFORE the user even knows the content is there...
2. Also appears the SQLite DB is pre-populated with compressed scripture strings which are uncompressed by ContentInflator and re-dressed into Droid webkit friendly HTML for each book+chapter+verse+page access with a background task unzipping and prepping surrounding chapters that may or may not be viewed
- Can this be optimized? I know decompression is generally faster than compression, so the decompression may not be perceptible...
- But storing webkit enabled content could help and utilizing webkits cachemanager would offload a bunch of code when displaying or predicting content that will be viewed next
- I agree a look-ahead or predictive cache loader is something that should be implemented specifically for the GL ScriptureViewActivity.
- Implementing an historical view cache manager, could be offloaded though
- Doesn't look like we are using android.webkit.CacheManager, does it not work with local URI's? Or am I missing something??
3. I guess a concern over data size (wireless bandwidth & device storage usage concerns - I expect) is causing nested compression unnecessarily, one-time GZIP compression for OTA distribution should be good enough, need to evaluate what an uncompressed scripture strings in SQLite DB would look like. Most droids are shipping with a 2 or 4GB sdcard, I believe GL has more headroom for static DB store much bigger than 18.857MB (ldsscriptures.21.db current size)
4. To support generic published XML content received from LDS.Org (zip or gzip'd compressed) could/should have imperceptible performance changes to the end user so long as GL stays with a background download, local data conversion to a suitable SQLite local store and ultimate webkit rendering. Most folks don't mind long one-time initial downloads and conversion so long as it is done in the background & view/search is snappy once the content gets there
5. Republishing a new monolithic DB as [GLA] adds more dynamic & segmented content like various conference text, LDS mag text, church music, select video and keeping coherent cross-references means the content management flow on the device needs an update
- I would guess the best approach is to provide the user 'settings' to control how much of the GL is sync'd to their device
- Yep I just swapped over from looking at [Mormon Channel for Android (MCA)] and asked about the overlapping feature concerns...
- [MCA] is the polar opposite of [GLA] in terms of caching. [MCA] relies heavily on dynamic web-pull & web-cache to display content
- [GLA] is almost entirely focused on local store content at the moment
- Does a shared Droid webkit extension between the [GLA] & [MCA] approaches make sense? Seems a waste that [MCA] needs [GLA] features and [GLA] needs some of [MCA] features.
Thanks for entertaining a long email from an uninformed new guy...