Rich's comments on GLA Implementation

Discussions around the Android version of the Gospel Library application.
Post Reply
User avatar
jackcholt
New Member
Posts: 34
Joined: Mon Nov 23, 2009 8:55 am
Location: Fallbrook, CA, USA

Rich's comments on GLA Implementation

#1

Post by jackcholt »

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...
User avatar
jackcholt
New Member
Posts: 34
Joined: Mon Nov 23, 2009 8:55 am
Location: Fallbrook, CA, USA

#2

Post by jackcholt »

1. We would probably find the need to do some content massaging on the device to adapt to what is best for Android. More on this below.

2. I don't know that anyone on the GLA team has investigated CacheManager. Someone should and make a decision as to whether there is a benefit to GLA.

We store the content compressed because historically (and currently for probably many devices still out there in, for instance, many "third world" countries) Android devices have had small amounts of internal memory and only a few gigabytes of SDCARD style storage. We are trying to make the storage footprint as small as possible. We cannot afford to judge available devices by those available in more affluent countries. One of the objectives of Mobile Gospel Library is to make the scriptures and other church materials available to as many people as possible; especially in places like China where they may have a smart phone but printed materials are restricted or hard to come by.

3. see 2

4. Agreed for the most part. One problem we DO have at the moment is the initial download over EDGE or slower networks or over weak network connections, is subject to failures. Not sure what to do about that. Of course, lack of network connection might keep someone from installing GLA in the first place, so...

5. Yes. We need to get away from the monolithic db approach. I don't think it would be wise to try to include more content in the existing db than is already there. We may even want to split out the lesson manuals into separate downloads.

Rich;

Please explain further about the shared needs of MCA and GLA. I occasionally get an email saying they wish GLA could read them the scriptures but I view that as clearly in the bailiwick of MCA. All the user has to do is have both loaded, listen to the scriptures through MCA and follow along in GLA if they want.
rich
Member
Posts: 56
Joined: Mon Aug 24, 2009 6:52 pm
Location: Branchburg, NJ USA

#3

Post by rich »

Thanks for the historical insight...

Miniumum Hardware Support for GLA:
As to Android devices in foreign countries, the minimum hardware footprint for Droid is pretty small to be sure - 32MB RAM, 32MB Flash and 200 Mhz GPU for a VERY basic droid O/S experience, assuming DSP's are handling voice & radio. I was in the mobile middleware business till my work was offshored for the most part. Many of my customers were global. I would call the mini-me Droid specs mentioned here a 'feature phone' not a 'smartphone' class device and unsuitable for GLA. I would think GLA gets reasonable coverage globally with a basic assumption to spec a requirement for a minimum 1GB sdcard, where the user can 'choose' how much or how little of the Gospel Library they store locally. The GLA code today doesn't appear to support storing DB's in system flash (a good design approach GLA should stick with).

CacheManager relevance:
I will investigate and see if webkit.CacheManager can handle some of the new GLA content browser like features and local content viewing cache traversal.

Restart of Large Downloads on Flaky Nets:
Sounds like we need HTTP 1.1 session resume to handle picking up where a large download failed, need to make sure the server-side is ready for HTTP 1.1 session resume as well. As long as the device's IP address doesn't change, most servers can handle this pretty easily.

Mini GL DB partitioning and/or federating:
Anyone know how is iPhone breaking up diverse content and handling cross DB references (i.e. an ensign article referencing a scripture)? Or is everything (scriptures, ensign, conf's, etc...) monolithic for iPhone SQLite stores??

GLA and MCA common features:
Keeping it simple - MCA is more of a streaming browser application at the moment, Heavily dependent on quasi-R/T streaming from a server. MCA doesn't store local content for offline reference. For the next release, the customer (MCR) does want to add off-line storage content complete with user annotation. GLA has the capability for local content storage and annotation but lacks the ability to reference & display audio or video streams which are part of the general Gospel Library. That's the basic future overlap I am referring to. I am not suggesting cross-referenced local store & multi-media streams can or should be accomplished in 1 or a few releases. I am just making more of a general note that these 2 apps are coming at the 'cross-linking & user annotation features' from opposite sides of local viewer versus a streaming web app. It will be a good time for ALL of the mobile platforms (not just Droid) to have a 'common or similar' middleware approach for viewing, cross-referencing and web sync'd annotation. Webkit is a good place to start for viewing (realizing there are differences between iPhone and Droid webkit), a consistent URI agreement and syncml (OMA) based annotation web services.
Post Reply

Return to “Android Gospel Library”