[sword-devel] Android SWORD

Tue Sep 7 07:40:14 MST 2010

  Some thoughts on whether to use JSword or SWORD:
SWORD will be faster than JSword, but for the most part it won't matter. 
The primary work of a Bible application are:
a) Convert a reference into a disk read. For a chapter of references, 
even Psalm 119, this is so fast for both that it won't be noticed.
b) Read each reference from disk. The speed differences between the two 
are dwarfed by the IO costs.
c) Render into HTML the raw data of a chapter. Here, I'll guess that 
SWORD will seem a bit snappier if Bible Desktop's method of rendering is 
used. If another method of rendering is done, I think it will be a nit. 
If BD's xslt mechanism is used, it is more flexible allowing for 
different style sheets.
d) Do a search and get a list of hits. Presuming the use of Lucene, the 
cost will be several fold: Building an index (SWORD will be faster as it 
does less), searching an index (tie, as it is IO bound). JSword has a 
more feature laden index (e.g. verse text, notes, headers, xrefs, 
stemming, ...).

Basically, I don't think that one needs to measure "between the 
keystroke" differences. One needs to measure user experience.

Another major difference between the two is that JSword lags SWORD in 
module support. E.g. it lacks av11n. And at the moment it requires http 
download of zips.

I have an old Win98 laptop with less than 400M of RAM and Bible Desktop 
runs on it just fine. My impression is that the smart phones are more 
capable than my old laptop.

Of course, if I were to do it, I'd use JSword.

In Him,
     DM

On 09/06/2010 05:41 PM, Kenneth Arnold wrote:
> This thread got rather sidetracked by the version control issue;
> personally I use git daily but usually in a centralized workflow. I
> think between github and GUIs like TortoiseGit it's not a big burden
> for new users ("just remember to Push"). Also, many open-source
> projects I follow have switched from bzr/Launchpad to github. But I
> have no strong feelings on what direction the various projects here
> should go. Now back on topic...
>
> Once the libsword-JNI bindings are stabilized and the build process is
> smoothed out, the only significant difference between them and JSword
> for Android should be speed, so let's measure that. There may also be
> differences in formatting, so let's go with the one that formats
> better and is faster. (Caching and prefetch could smooth over most
> visible speed differences, so maybe it's just which one formats
> better.) I also once lamented the complexity of doing simple things
> with the libsword C++ API, but I wrote a Python ztext reader instead
> of what I should have done, which is: help improve the code :)
>
> It doesn't look like the current way and-bible uses WebView allows you
> to do much with the text besides display it. I'm considering replacing
> the static page with a Javascript viewer that calls Java methods using
> addJavascriptInterface [1]. This would theoretically allow accurate
> verse position information and continuous scrolling (assuming the
> ability to call Javascript from Java, which may be possible with
> loadUrl [2]), but would require some significant HTML and Javascript
> work. Are there any web-based SWORD viewers that might be adaptable to
> that purpose?
>
> Btw, PocketSword users, how do you like the interface? Should we just
> do the same thing on Android?
>
> For those that would prefer to pay now instead of waiting for
> open-source, CadreBible and Olive Tree's BibleReader both have nice
> (though not perfect) interfaces.
>
> So Martin, enjoy your holidays and see you when you get back.
>
> -Ken
>
>
> [1] http://developer.android.com/reference/android/webkit/WebView.html#addJavascriptInterface%28java.lang.Object,%20java.lang.String%29
> [2] http://groups.google.com/group/android-developers/browse_thread/thread/6ed23efa4d22f7e6
>
>
>
> On Wed, Sep 1, 2010 at 12:00 PM, Martin Denham<mjdenham at gmail.com>  wrote:
>> Hi,
>>
>> Bishop is real fast but I don't know if that is all due to C++ code or if it
>> is not doing as much html processing/formatting as and-bible.  I thought
>> about switching to the C++ libs but there are various h/w restrictions if
>> you use the ndk and also it is a long time since I use C++ and I just can't
>> understand the Sword C++ code anymore and it seems from Troy's e-mails that
>> the packaged ndk lib would need a fair bit more work.  Jsword also needs
>> some optimisations and tweaks but I am more confident with Java.  So if you
>> use C++ then feel free to continue Bishop or branch and-bible, but I always
>> planned to create a pure java bible and JSword gave me a really good start.
>> There is facade layer in and-bible that acts as an interface to JSword but
>> realistically so many helper classes are used in the ui that it would be
>> difficult to make the back-end switchable.
>>
>> Maybe the git idea is a good one and can be put on the list.  What do others
>> think?  I chose svn because I thought most developers would be familiar with
>> it and it has great eclipse integration.  Personally I have to use PVCS and
>> Clearcase at work so even svn provided challenges for me.  Nic recently
>> transferred PocketSword to Mercurial and seemed very happy.  However, as
>> everybody keeps commenting there is a whole load of functionality in
>> and-bible that is missing and that needs improvement so maybe I should keep
>> my head down and not be distracted.
>>
>> I am on holiday at the moment so don't expect any new releases for a while.
>> Why am I typing e-mails while I am on holiday!!!
>>
>> btw I just want to share we just heard that my eldest daughter got 5xA* 4xA
>> and a B in her GCSEs - the holiday begins.
>> Best regards
>> Martin
>>
>> On 31 August 2010 19:11, Bill Burton<bburton at mail.com>  wrote:
>>> Hello,
>>>
>>> On a related note, could this project be hosted on http://github.com?  It
>>> would provide much better ability to collaborate since anyone can fork, make
>>> changes and then push them back for optional inclusion.  The built-in wiki
>>> would make it easy to publish any appropriate docs.
>>>
>>> For an example of why this would be helpful, I have some libsword swig
>>> bindings for Ruby that never got committed because no one who was a commiter
>>> had the time or inclination to step up and look at them.  If I could have
>>> forked the swig bindings, and checked in my changes, then whether or not
>>> they became incorporated in the official version, they would be readily
>>> available for anyone to find, evaluate and/or fix.
>>>
>>> Just my $0.02.
>>>
>>> Thanks,
>>> -Bill
>>>
>>> On Sat, Aug 28, 2010 at 11:33 PM, Kenneth Arnold<kcarnold at alum.mit.edu>
>>> wrote:
>>>> Hi Martin and Troy,
>>>>
>>>> I finally got the AndBible source built; I needed to get the jsword
>>>> source and also raise the memory limit for Eclipse--it thrashed and
>>>> eventually crashed in the linker/dex step. There's still a dex warning that
>>>> floods the Console, but it works on my Droid X. I made a few minor
>>>> modifications to ensure I could, but nothing serious yet.
>>>>
>>>> Major things I'd like to work on as a user are navigation, continuous
>>>> scrolling, and verse number sync. Also, do you think we should replace the
>>>> backend with native libsword? That might help formatting and speed, but I
>>>> don't know how deeply it's woven into the code. The Bishop code could be a
>>>> useful example if we decide to go that way.
>>>>
>>>> Should we continue discussion on this list?
>>>>
>>>> -Ken (mobile)
>>>>
>>>> On Aug 26, 2010 1:39 AM, "Troy A. Griffitts"<scribe at crosswire.org>
>>>> wrote:
>>>>
>>>> Dear Ken,
>>>>
>>>> Thank you for the debug.  I also have had trouble with the installer and
>>>> haven't had time to look into it.
>>>>
>>>> The history is that I build Bishop as a sort of proof of concept for the
>>>> java-jni bindings for Android.  I mostly work in the engine code.  The
>>>> jni binding code I kept in SWORD SVN and the Bishop code I just backed
>>>> up occasionally to our server.  Last year my drive crashed and I lost
>>>> some work but might have pieced it all back together.  Here is an email
>>>> I sent to Gary with links to all my stuff.
>>>>
>>>> ______________________
>>>>
>>>> After last year when I started the work I had a harddrive die on my
>>>> laptop.  I had been backing up the work regularly, but lost about 2
>>>> weeks of work in the crash.  I used a recovery tool to salvage many of
>>>> the files from the bishop project and think I may have close to what is
>>>> in the apk.  Here are my resources if you want to try to piece things
>>>> together:
>>>>
>>>> Lastest binary when I stopped, dated 11-18-2009:
>>>>
>>>> http://crosswire.org/~scribe/bishop.apk
>>>>
>>>> Latest backup of source, dated 10-31-2009:
>>>> http://crosswire.org/~scribe/bishop-20091031.tar.gz
>>>>
>>>> Latest binary after reconstructing source and I think some small new
>>>> work (I think this is built with debug symbols in the native library so
>>>> it's a little bigger):
>>>>
>>>> http://crosswire.org/~scribe/bishop2.apk
>>>>
>>>> Current backup of source which built the above:
>>>> http://crosswire.org/~scribe/bishop-20100804.tar.gz
>>>>
>>>> Please excuse my ignorance of Android programming.  I am fumbling
>>>> through it all.
>>>>
>>>> I remember having trouble with the InstallMgr.  It sometimes connects
>>>> and downloads and other times it does not.  I thought it might be the
>>>> limited memory on my G1 or some trouble with the timing of the FTP code
>>>> in the native library.  I've found serious bugs in Android's system
>>>> calls, (e.g. memccpy) and reported it to them, but they still haven't
>>>> fixed it.  I use my own version in the ftp lib to avoid the bug.  That
>>>> is where I stopped-- thinking I needed to debug this ftp intermittent
>>>> issue.  I didn't compare how well the older .apk works versus the newer
>>>> .apk.  Maybe the older version worked better?  Or maybe a newer version
>>>> of Android or new phone works better?
>>>>
>>>> Let me know what you find.
>>>>
>>>> Troy
>>>>
>>>>
>>>>
>>>> On 08/24/2010 09:01 PM, Kenneth Arnold wrote:
>>>>> I just got an Android phone, and after seeing the...