[sword-devel] Android Sword App in Market and Open Sourced
Hi All, Yesterday I released an Android app which uses the Sword C++ JNI Library that Troy has created for us. If you have an Android phone you can hit up the link here: http://market.android.com/search?q=pname:com.smurphete.android.esv The source code for it exists here: http://code.google.com/p/crossconnectbible/source/checkout The app has been on the market for a few years now but I only recently worked Troy's library into it. The app has roughly 85,000 downloads and good ratings. I am only a uni student and work on it on a hobby basis (so the app is not professional by any means), if you would like to help me continue to develop a free open sourced Android Bible app please let me know, there's plenty of things that Im trying to do with it but lack the knowledge/man power. Hope this is the right mailing list. Cheers, Gary ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
My two pence.. feel free to ignore. * OSIS - XSLT - XHTML is unnecessarily complicated. * Indeed, it is easy enough to get the raw text. If you still prefer to convert raw text to OSIS first, given an XML parser/sequencer and a DOM, the programming language (Java) is all you need to produce the output (HTML). Personally, I've found using XSLT/XPath a bit cumbersome. Love in Christ, David On 1 September 2010 18:23, DM Smith dmsm...@crosswire.org wrote: On 09/01/2010 12:48 PM, Manfred Bergmann wrote: Can the html rendering in JSword be simplified? I'm not sure what you mean by simplified? Do you mean the process or the output? The process is basically this: Get the verses from the module. Convert them to OSIS. (For modules already in OSIS this is almost a pass-through) Use xslt to convert the OSIS into xhtml. The output is the final step. Another stylesheet can be used to simplify the output. Alternatively, one can create another mechanism to convert the raw text into html. It is easy enough to get the raw text. In Him, DM ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
On 09/30/2010 05:24 AM, David Hollands wrote: My two pence.. feel free to ignore. * OSIS - XSLT - XHTML is unnecessarily complicated. I'm interested in other ways that OSIS (xml in general) can be rendered. Some browsers (maybe all modern ones by now) are able to apply CSS directly to xml to produce output. Flying Saucer (https://xhtmlrenderer.dev.java.net/) looks promising to me as something that can be used by a Java program. * Indeed, it is easy enough to get the raw text. If you still prefer to convert raw text to OSIS first, given an XML parser/sequencer and a DOM, the programming language (Java) is all you need to produce the output (HTML). Personally, I've found using XSLT/XPath a bit cumbersome. The biggest gain I see in using xslt is to have parameter driven output. E.g. the style of verse references, whether to show notes or not, The second gain is that it is simple, though it takes a bit of learning. The problem with raw text from an OSIS document is things like quotes, Words of Christ and Divine Name, i.e. Lord are marked up in such a way that they don't appear right in raw text. Love in Christ, David On 1 September 2010 18:23, DM Smithdmsm...@crosswire.org wrote: On 09/01/2010 12:48 PM, Manfred Bergmann wrote: Can the html rendering in JSword be simplified? I'm not sure what you mean by simplified? Do you mean the process or the output? The process is basically this: Get the verses from the module. Convert them to OSIS. (For modules already in OSIS this is almost a pass-through) Use xslt to convert the OSIS into xhtml. The output is the final step. Another stylesheet can be used to simplify the output. Alternatively, one can create another mechanism to convert the raw text into html. It is easy enough to get the raw text. In Him, DM ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
Hi, I must confess that to make JSword perform a little better and due to lack of xslt support on early versions of Android I tweaked jsword OSIS processing so as to use OSIS XML - SAX processor - HTML. I thus removed jdom and xslt. I realise there are various arguments for using jdom and xslt but performance was my main driver on such small, low powered mobile phones. I may switch back to using xslt in the future because there is a lot of logic in the xslt stylesheet that was difficult to reproduce in SAX. Also, now, I think I may have been able to get xslt going on old Android s/w but am putting my effort into other areas. Jdom may add too much overhead for such intense processing on small devices although it works great on pcs. Best regards Martin On 30 September 2010 15:07, DM Smith dmsm...@crosswire.org wrote: On 09/30/2010 05:24 AM, David Hollands wrote: My two pence.. feel free to ignore. * OSIS - XSLT - XHTML is unnecessarily complicated. I'm interested in other ways that OSIS (xml in general) can be rendered. Some browsers (maybe all modern ones by now) are able to apply CSS directly to xml to produce output. Flying Saucer ( https://xhtmlrenderer.dev.java.net/) looks promising to me as something that can be used by a Java program. * Indeed, it is easy enough to get the raw text. If you still prefer to convert raw text to OSIS first, given an XML parser/sequencer and a DOM, the programming language (Java) is all you need to produce the output (HTML). Personally, I've found using XSLT/XPath a bit cumbersome. The biggest gain I see in using xslt is to have parameter driven output. E.g. the style of verse references, whether to show notes or not, The second gain is that it is simple, though it takes a bit of learning. The problem with raw text from an OSIS document is things like quotes, Words of Christ and Divine Name, i.e. Lord are marked up in such a way that they don't appear right in raw text. Love in Christ, David On 1 September 2010 18:23, DM Smithdmsm...@crosswire.org wrote: On 09/01/2010 12:48 PM, Manfred Bergmann wrote: Can the html rendering in JSword be simplified? I'm not sure what you mean by simplified? Do you mean the process or the output? The process is basically this: Get the verses from the module. Convert them to OSIS. (For modules already in OSIS this is almost a pass-through) Use xslt to convert the OSIS into xhtml. The output is the final step. Another stylesheet can be used to simplify the output. Alternatively, one can create another mechanism to convert the raw text into html. It is easy enough to get the raw text. In Him, DM ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
On Wed, 21 Oct 2009 01:05:22 -0700 Troy A. Griffitts scr...@crosswire.org wrote: A quick update on Android progress. o Basic Bible navigation and display are working, albeit not pretty. o Text-to-Speech functionality is added. o All methods from the engine are now completely wrapped to the same swordorb.idl interface we use for SWORDWeb's Java-CORBA-C++ bridge, so a full-featured Android client should now be possible with the current engine exposure. Good to hear. I recently purchased an Android phone and hope to do some development on it soon. Thanks, Chris ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
Am 07.09.2010 um 15:40 schrieb DM Smith: Of course, if I were to do it, I'd use JSword. I would as well. Manfred 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 Denhammjden...@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 Burtonbbur...@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.
Re: [sword-devel] Android SWORD
I would use whatever had the highest speed. During a sermon you don't want to wait for the text to build. On Wed, Sep 8, 2010 at 3:26 PM, Manfred Bergmann manfred.bergm...@me.comwrote: Am 07.09.2010 um 15:40 schrieb DM Smith: Of course, if I were to do it, I'd use JSword. I would as well. Manfred 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 Denhammjden...@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 Burtonbbur...@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
Re: [sword-devel] Android SWORD
Also C++/JNI requires use of the Android NDK which only generates code for ARMv5 or ARMv7-A architectures (see http://developer.android.com/sdk/ndk/index.html) so not all Android devices would be supported. Regards Martin On 7 September 2010 15:40, DM Smith dmsm...@crosswire.org wrote: 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 Denhammjden...@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
Re: [sword-devel] Android SWORD
Yeah - This should definitely use JSword. Negligible difference in performance, and much easier to maintain for other developers who want to get involved, etc. The Android NDK is definitely not somewhere you want to go unless you have to. :) On Tue, Sep 7, 2010 at 9:26 AM, Martin Denham mjden...@gmail.com wrote: Also C++/JNI requires use of the Android NDK which only generates code for ARMv5 or ARMv7-A architectures (see http://developer.android.com/sdk/ndk/index.html) so not all Android devices would be supported. Regards Martin On 7 September 2010 15:40, DM Smith dmsm...@crosswire.org wrote: 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 Denhammjden...@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
Re: [sword-devel] Android SWORD
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 mjden...@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 bbur...@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 kcarn...@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
Re: [sword-devel] Android SWORD
I don't know but isn't it contra productive and actually a lot more work to maintain the sources on a variety on source control platforms? We end up having SWORD source trees on Github, Bitbucket and Launchpad and eventually on any other system that will come up. For all of those we need people to maintain the sources otherwise we will have a mess of different sources version and implementations. In my opinion, the main and official sources of SWORD have to be maintained by responsible people from Crosswire. And it has to be clear that Crosswire will have and is in control of the official sources. I don't actually care which source control system is used for that, though I think that Subversion is the greatest common divisor because all other DVCSs can bi-directional access Subversion. Manfred Am 02.09.2010 um 04:55 schrieb Troy A. Griffitts: Is there someone maintaining bindings on github who doesn't have access to our SVN repository? I'm happy to add more writers. Please let me know. Troy On 09/01/2010 09:45 AM, Matthew Talbert wrote: On Tue, Aug 31, 2010 at 7:11 PM, Bill Burton bbur...@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. Please consider branching http://launchpad.net/sword and publishing your ruby swig bindings. Much of the recent bindings work has been done on launchpad. I can't promise results, but the person who has been doing the recent work will definitely be able to see your work there. Matthew ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
On Thu, Sep 2, 2010 at 5:31 AM, Manfred Bergmann manfred.bergm...@me.com wrote: I don't know but isn't it contra productive and actually a lot more work to maintain the sources on a variety on source control platforms? We end up having SWORD source trees on Github, Bitbucket and Launchpad and eventually on any other system that will come up. For all of those we need people to maintain the sources otherwise we will have a mess of different sources version and implementations. In my opinion, the main and official sources of SWORD have to be maintained by responsible people from Crosswire. And it has to be clear that Crosswire will have and is in control of the official sources. I don't actually care which source control system is used for that, though I think that Subversion is the greatest common divisor because all other DVCSs can bi-directional access Subversion. As far as I know, only Launchpad is being used (other than svn). It is quite helpful, because it allows people to publish branches of code and work on them together to finish a feature before it is committed to sword svn. If there is a proliferation of source control systems being used, I'm unaware of it. Matthew ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
Am 02.09.2010 um 18:18 schrieb Dmitrijs Ledkovs: On 2 September 2010 17:28, Matthew Talbert ransom1...@gmail.com wrote: On Thu, Sep 2, 2010 at 5:31 AM, Manfred Bergmann manfred.bergm...@me.com wrote: I don't know but isn't it contra productive and actually a lot more work to maintain the sources on a variety on source control platforms? We end up having SWORD source trees on Github, Bitbucket and Launchpad and eventually on any other system that will come up. For all of those we need people to maintain the sources otherwise we will have a mess of different sources version and implementations. In my opinion, the main and official sources of SWORD have to be maintained by responsible people from Crosswire. And it has to be clear that Crosswire will have and is in control of the official sources. I don't actually care which source control system is used for that, though I think that Subversion is the greatest common divisor because all other DVCSs can bi-directional access Subversion. As far as I know, only Launchpad is being used (other than svn). It is quite helpful, because it allows people to publish branches of code and work on them together to finish a feature before it is committed to sword svn. If there is a proliferation of source control systems being used, I'm unaware of it. Matthew Plus on Launchpad it is clearly stated where the upstream svn repository is. The bzr imports are run every 6 hours for many sword projects (jsword, sword, xiphos, bibletime). And bzr is fully compatible with svn, i.e. you can seamlessly commit to svn from bzr if you have access. That is totally fine. The use case you are outlining is comprehensible. Btw: MacSword is mirrored on Launchpad as well. Who is maintaining the Launchpad repos? I mean, one of the branches probably is used to push back to SWORD svn? Manfred ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
On 2 September 2010 18:47, Manfred Bergmann manfred.bergm...@me.com wrote: Am 02.09.2010 um 18:18 schrieb Dmitrijs Ledkovs: On 2 September 2010 17:28, Matthew Talbert ransom1...@gmail.com wrote: On Thu, Sep 2, 2010 at 5:31 AM, Manfred Bergmann manfred.bergm...@me.com wrote: I don't know but isn't it contra productive and actually a lot more work to maintain the sources on a variety on source control platforms? We end up having SWORD source trees on Github, Bitbucket and Launchpad and eventually on any other system that will come up. For all of those we need people to maintain the sources otherwise we will have a mess of different sources version and implementations. In my opinion, the main and official sources of SWORD have to be maintained by responsible people from Crosswire. And it has to be clear that Crosswire will have and is in control of the official sources. I don't actually care which source control system is used for that, though I think that Subversion is the greatest common divisor because all other DVCSs can bi-directional access Subversion. As far as I know, only Launchpad is being used (other than svn). It is quite helpful, because it allows people to publish branches of code and work on them together to finish a feature before it is committed to sword svn. If there is a proliferation of source control systems being used, I'm unaware of it. Matthew Plus on Launchpad it is clearly stated where the upstream svn repository is. The bzr imports are run every 6 hours for many sword projects (jsword, sword, xiphos, bibletime). And bzr is fully compatible with svn, i.e. you can seamlessly commit to svn from bzr if you have access. That is totally fine. The use case you are outlining is comprehensible. Btw: MacSword is mirrored on Launchpad as well. Who is maintaining the Launchpad repos? I mean, one of the branches probably is used to push back to SWORD svn? Manfred Does it make sence to create crosswire meta projects for all of the sword related projects? ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
On Thu, Sep 2, 2010 at 12:47 PM, Manfred Bergmann manfred.bergm...@me.com wrote: Am 02.09.2010 um 18:18 schrieb Dmitrijs Ledkovs: On 2 September 2010 17:28, Matthew Talbert ransom1...@gmail.com wrote: On Thu, Sep 2, 2010 at 5:31 AM, Manfred Bergmann manfred.bergm...@me.com wrote: I don't know but isn't it contra productive and actually a lot more work to maintain the sources on a variety on source control platforms? We end up having SWORD source trees on Github, Bitbucket and Launchpad and eventually on any other system that will come up. For all of those we need people to maintain the sources otherwise we will have a mess of different sources version and implementations. In my opinion, the main and official sources of SWORD have to be maintained by responsible people from Crosswire. And it has to be clear that Crosswire will have and is in control of the official sources. I don't actually care which source control system is used for that, though I think that Subversion is the greatest common divisor because all other DVCSs can bi-directional access Subversion. As far as I know, only Launchpad is being used (other than svn). It is quite helpful, because it allows people to publish branches of code and work on them together to finish a feature before it is committed to sword svn. If there is a proliferation of source control systems being used, I'm unaware of it. Matthew Plus on Launchpad it is clearly stated where the upstream svn repository is. The bzr imports are run every 6 hours for many sword projects (jsword, sword, xiphos, bibletime). And bzr is fully compatible with svn, i.e. you can seamlessly commit to svn from bzr if you have access. That is totally fine. The use case you are outlining is comprehensible. Btw: MacSword is mirrored on Launchpad as well. Who is maintaining the Launchpad repos? I mean, one of the branches probably is used to push back to SWORD svn? Whoever initially configured to be the project maintainer on LP is managing the repository. In my case, I keep a branch of lp:sword, which mirrors Crosswire, and I usually branch off it when I'm pushing to LP. I also keep a bzr co http://svn.crosswire.org/svn/sword/trunk; which is basically identical to svn co. My directory looks like this: sword/ - trunk/ - cmake/ - flags-greg/ - flags-dmi/ - svn/ Trunk follows Launchpad's mirror of Crosswire. CMake is the branch I initially created as I was building the CMake system. flags-greg/ is my own version of some patches related to CFLAGS handling in CMake and flags-dmi/ is Dmitrijs's work. We've been collaborating to fix some inconsistencies. svn/ is my thin bzr co of the official Crosswire subversion. It isn't a full-fledged Bazaar branch, and uses the same commands as a subversion checkout would: update pulls down from the server, commit makes a Subversion commit back to Crosswire. When I'm done with my feature branch, I make sure to merge any changes that I get out of svn/ into the branch, do a final check to make sure nothing is broken, then I'll merge flags-greg/ or flags-dmi/ (depending on which one works better) into svn/ and commit, and the commit is made directly to Subversion. Later, Launchpad will automatically update its trunk/ to mirror Crosswire, and I'll be able to do bzr pull in my local trunk/ to see those updates. In a purely Bazaar system, I would instead merge flags-greg/ into trunk/ and then do bzr push to the Launchpad servers. But for a repository that follows a Subversion repository, you can't push into the following branch (because how would LP justify keeping developer A's credentials and letting someone else push to that and then LP would have to submit the push to SVN - but what if there were conflicts or an update needed to be run first or...). All the work done between Bazaar and SVN is handled manually by a Bazaar user, the LP system just allows me and a collaborator(s) to easily talk back and forth and then merge the result together before committing to subversion. There is really nothing to worry about from the proliferation. So long as the website keeps saying that SVN is the official source of the central repository, things are fine. People can come and find my branches or someone else's branches on Launchpad or Bitbucket if they want, but they won't be following the trunk of development, in that case. Of course, someone getting down and dirty with a VCS of any sort on the code should expect hurdles and probably will need to end up coming crying to the developers when something inevitably breaks. tl;dr - One shouldn't fret about people using the DVCSs and their convenience, so long as those people with commit access to the code are trustworthy and responsive and know how to interface between the two. --Greg --Greg Manfred ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel
Re: [sword-devel] Android SWORD
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 restrictionshttp://developer.android.com/sdk/ndk/index.html 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 bbur...@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 kcarn...@alum.mit.eduwrote: 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 scr...@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.
Re: [sword-devel] Android SWORD
You can't live without us :) Congratulations on the scores! On Wed, Sep 1, 2010 at 12:00 PM, Martin Denham mjden...@gmail.com wrote: SNIP 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 bbur...@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 kcarn...@alum.mit.eduwrote: 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 scr...@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... ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page -- Bill Burton bbur...@mail.com ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
On Tue, Aug 31, 2010 at 7:11 PM, Bill Burton bbur...@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. Please consider branching http://launchpad.net/sword and publishing your ruby swig bindings. Much of the recent bindings work has been done on launchpad. I can't promise results, but the person who has been doing the recent work will definitely be able to see your work there. Matthew ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
Am 01.09.2010 um 17:00 schrieb Martin Denham: 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. Can the html rendering in JSword be simplified? 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'm using a mixture of Bazaar and Subversion. I think that DVCSs do not make sense everywhere. Both, a DVCS and a VCS need maintenance. With a DVCS you might get a lot of branches where if no one cares you suddenly have a lot of mess. This is exactly the opposite with a VCS that is very strict with giving people write access where you need people to review and apply patches. If those people don't exist the sources will not change. However I still think that it absolute makes sense to have a shared repository with some people that are responsible for maintenance and patch review/apply. If this works well I believe it will not hinder anyone from commitment. Manfred On 31 August 2010 19:11, Bill Burton bbur...@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 kcarn...@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 scr...@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
Re: [sword-devel] Android SWORD
On 09/01/2010 12:48 PM, Manfred Bergmann wrote: Can the html rendering in JSword be simplified? I'm not sure what you mean by simplified? Do you mean the process or the output? The process is basically this: Get the verses from the module. Convert them to OSIS. (For modules already in OSIS this is almost a pass-through) Use xslt to convert the OSIS into xhtml. The output is the final step. Another stylesheet can be used to simplify the output. Alternatively, one can create another mechanism to convert the raw text into html. It is easy enough to get the raw text. In Him, DM ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
Am 01.09.2010 um 18:23 schrieb DM Smith: On 09/01/2010 12:48 PM, Manfred Bergmann wrote: Can the html rendering in JSword be simplified? I'm not sure what you mean by simplified? Do you mean the process or the output? I guess I meant both. The process is basically this: Get the verses from the module. Convert them to OSIS. (For modules already in OSIS this is almost a pass-through) Use xslt to convert the OSIS into xhtml. The output is the final step. Another stylesheet can be used to simplify the output. Alternatively, one can create another mechanism to convert the raw text into html. It is easy enough to get the raw text. Thanks for the explanation. Manfred ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
Is there someone maintaining bindings on github who doesn't have access to our SVN repository? I'm happy to add more writers. Please let me know. Troy On 09/01/2010 09:45 AM, Matthew Talbert wrote: On Tue, Aug 31, 2010 at 7:11 PM, Bill Burton bbur...@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. Please consider branching http://launchpad.net/sword and publishing your ruby swig bindings. Much of the recent bindings work has been done on launchpad. I can't promise results, but the person who has been doing the recent work will definitely be able to see your work there. Matthew ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
Hello, With the discussion on which back end to use, would it make sense to write a JSword adapter to the interface described by Troy below? This would enable the back ends to be swapped out with minimal effort (maybe even at runtime). -Bill On Wed, Oct 21, 2009 at 4:05 AM, Troy A. Griffitts scr...@crosswire.orgwrote: A quick update on Android progress. o Basic Bible navigation and display are working, albeit not pretty. o Text-to-Speech functionality is added. o All methods from the engine are now completely wrapped to the same swordorb.idl interface we use for SWORDWeb's Java-CORBA-C++ bridge, so a full-featured Android client should now be possible with the current engine exposure. Everything is still at the same location (below). -Troy. Troy A. Griffitts wrote: There is now a preliminary Android NDK / Java binding available in SVN. This is very very early and should just be considered a proof of concept. There is a package available to show things working, but doesn't really do much: http://crosswire.org/~scribe/bishop.apkhttp://crosswire.org/%7Escribe/bishop.apk the JNI libsword.so should be placed in your project/libs directory, e.g., ~/workspace/bishop/libs/armeabi/libsword.so and can be obtained from the above package-- believe me, you don't want to try to compile it yourself as the NDK does not have STL support out of the box. The Java classes can be obtained from the sword/bindings/java-jni/src directory, e.g. http://crosswire.org/svn/sword/trunk/bindings/java-jni/src/org/crosswire/android/sword/ Module library must exist on your SD card under a 'sword' directory to be found, e.g., unzip KJV.zip to /sdcard/sword/ Have fun, let me know if anyone else is interested in developing an Android frontend. -Troy. ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
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 kcarn...@alum.mit.eduwrote: 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 scr...@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.apkhttp://crosswire.org/%7Escribe/bishop.apk Latest backup of source, dated 10-31-2009: http://crosswire.org/~scribe/bishop-20091031.tar.gzhttp://crosswire.org/%7Escribe/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.apkhttp://crosswire.org/%7Escribe/bishop2.apk Current backup of source which built the above: http://crosswire.org/~scribe/bishop-20100804.tar.gzhttp://crosswire.org/%7Escribe/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... ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page -- Bill Burton bbur...@mail.com ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
Am 29.08.10 04:33, schrieb Kenneth Arnold: 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. Any reason to believe the C++ backend code is faster? I would conduct some performance tests before doing a switch. Native Java code is much more flexible than using binaries with JNI and whenever possible I would use Java code. Manfred -Ken (mobile) On Aug 26, 2010 1:39 AM, Troy A. Griffitts scr...@crosswire.org mailto:scr...@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... ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
Just my opinion but I am all for more speed ;) I use the reader during sermons and some speakers move from Bible text to Bible text quite fast. Having a history feature tracking each verse is useful for later review. Just my two sense. :) On Sat, Aug 28, 2010 at 11:33 PM, Kenneth Arnold kcarn...@alum.mit.eduwrote: 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 scr...@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... ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
I agree. Quick verse selection is highly desirable. Scrolling through all the books of the Bible is far too slow. I've found that a grid selection available on some bible readers works quite fast. Also, bookmarks and/or a history of viewed verses is very useful. Having the back arrow take one to a previous verse is very useful.Being able to navigate a set of bookmarked verses is helpful in a worship service. Dave On 8/29/2010 7:04 AM, SonWon wrote: Just my opinion but I am all for more speed ;) I use the reader during sermons and some speakers move from Bible text to Bible text quite fast. Having a history feature tracking each verse is useful for later review. Just my two sense. :) On Sat, Aug 28, 2010 at 11:33 PM, Kenneth Arnold kcarn...@alum.mit.edu mailto:kcarn...@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 scr...@crosswire.org mailto:scr...@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 http://crosswire.org/%7Escribe/bishop.apk Latest backup of source, dated 10-31-2009: http://crosswire.org/~scribe/bishop-20091031.tar.gz http://crosswire.org/%7Escribe/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 http://crosswire.org/%7Escribe/bishop2.apk Current backup of source which built the above: http://crosswire.org/~scribe/bishop-20100804.tar.gz http://crosswire.org/%7Escribe/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... ___ sword-devel mailing list: sword-devel@crosswire.org mailto:sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel
Re: [sword-devel] Android SWORD
I think the size issue could be solved somewhat if we could get the module loading system to download and open modules from the SD card rather than having them bundled into the application's .apk Also, for what it's worth, I want to throw my vote in for using libsword via JNI. -Wes On Sun, Aug 29, 2010 at 8:18 PM, David Forslund forsl...@mail.com wrote: One other request is to try to reduce the size of the application. It is over 8Mbytes on my Droid and is one of the largest applications on the phone (around the size of Google Maps).Other Biblereaders are significantly smaller. I would hope the size could be reduced. I don't know if going to the native libsword would be smaller or not. Thanks, Dave On 8/29/2010 7:04 AM, SonWon wrote: Just my opinion but I am all for more speed ;) I use the reader during sermons and some speakers move from Bible text to Bible text quite fast. Having a history feature tracking each verse is useful for later review. Just my two sense. :) On Sat, Aug 28, 2010 at 11:33 PM, Kenneth Arnold kcarn...@alum.mit.eduwrote: 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 scr...@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.apkhttp://crosswire.org/%7Escribe/bishop.apk Latest backup of source, dated 10-31-2009: http://crosswire.org/~scribe/bishop-20091031.tar.gzhttp://crosswire.org/%7Escribe/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.apkhttp://crosswire.org/%7Escribe/bishop2.apk Current backup of source which built the above: http://crosswire.org/~scribe/bishop-20100804.tar.gzhttp://crosswire.org/%7Escribe/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... ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-de...@crosswire.orghttp://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list:
Re: [sword-devel] Android SWORD
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 scr...@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... ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
Hi Ken, You can find and-bible source and builds here: http://code.google.com/p/and-bible/ Take a look and then contact me again later if you want or you could develop Bishop if you prefer. Best regards Martin On 25 August 2010 00:01, Kenneth Arnold kenneth.arn...@gmail.com wrote: I just got an Android phone, and after seeing the state of Bible software currently available, I'm excited about helping develop a good SWORD-powered Bible reader for it. I installed Troy's bishop2.apk and tried to download a module... fail (logcat at end of message). So I went looking for the code to see if I could track down the problem... but I haven't found any source code anywhere. Is that intentional, or am I missing something? As a user (previously of Laridian on WinMo), I've made this list of requirements for a Bible reader: - local storage - fast navigation UI (Laridian had specialized T9 for book names. You could get most anywhere in the Bible in about 6 keypresses.) - continuous scrolling (across chapter divisions) - cross references and footnotes - word/phrase search (perhaps fuzzy?) optional features: - scripture memory helper (I have a lot of concrete ideas here) - finding related resources (e.g., sermons) from selected resources - daily reading (or at least what's next after things I've read recently?) - screen orientation lock - song lyrics - history tracking (what passages did I look up while studying yesterday?), perhaps communally (what books have my friends been reading?) Any other interest in helping out? How can we organize a team? Martin, if you're still listening, I'd love to check out your code too. -Ken PS - here's the `adb logcat` from a failed module download. Turns out it succeeds if you create a 'modules' directory inside /sdcard/sword :) -- but then there are plenty of other issues. 08-24 23:19:46.443 2002 2021 D libsword.so: remoteInstallModule: sourceName: CrossWire 08-24 23:19:46.443 2002 2021 D libsword.so: remoteInstallModule: modName: ESV 08-24 23:19:46.443 2002 2021 D libsword.so: * InstallMgr::installModule 08-24 23:19:46.443 2002 2021 D libsword.so: * modName: ESV 08-24 23:19:47.286 2002 2021 D libsword.so: * mgr.prefixPath: /sdcard/sword/InstallMgr/20081216195754/ 08-24 23:19:47.286 2002 2021 D libsword.so: * destMgr-prefixPath: /sdcard/sword/ 08-24 23:19:47.286 2002 2021 D libsword.so: * absolutePath: /sdcard/sword/InstallMgr/20081216195754/modules/texts/ztext/esv/ 08-24 23:19:47.286 2002 2021 D libsword.so: * relativePath: modules/texts/ztext/esv/ 08-24 23:19:47.286 2002 2021 D libsword.so: netCopy: ftp.crosswire.org, modules/texts/ztext/esv/, /sdcard/sword/InstallMgr/20081216195754/modules/texts/ztext/esv/, t, 08-24 23:19:47.341 2002 2021 W System.err: Problem installing: -1 08-24 23:19:47.396 2002 2002 D libsword.so: getModInfoList returning 0 length array On Sun, Jun 13, 2010 at 4:30 AM, Martin Denham mjden...@gmail.com wrote: Hi Troy, Apologies, I was a bit confused regarding the different projects. The above was my first post to *Sword forums. I incorrectly thought that JSword, Sword and other Crosswire forums would be worked on by the same people. I have now joined the JSword-dev list which I had not spotted before. Whether the back end is built based on Sword or JSword it might be worthwhile combining with the Java Jsword guys for the front end which I think has to be in Java. I may download your apk and try it out. I can put my code/build somewhere if you want but it's still in a state of great flux. Kind regards Martin On 13 June 2010 04:54, Troy A. Griffitts scr...@crosswire.org wrote: Martin, Great news on your success of getting JSword to build on Android. I'm sure the JSword mailing list would be interested to hear about your success! I'm not sure about the speed. I will add a primitive search box to my test app and let you know how long a complete search of the KJV (a heavily marked up Bible) takes on my G1. Troy. On 06/09/2010 05:28 AM, mjdenham wrote: Hi Troy, I just thought I would mention that I have also been playing around with Android. I have spent the last few weeks creating a prototype bible viewer application for Android, but I just noticed Troy's messages in this forum. I took a slightly different technical approach to you and I don't know which is better and I also came at this project with the aim of creating a mobile bible viewer I could tweak and improve rather than specifically to write an Android front end for Sword. By way of information I thought I would outline my approach and what led me to start. I have used Pocket e-Sword for many years but development has now ceased on Pocket e-Sword and it is already looking a bit old, as is WinMob that it runs on, so I started thinking what to use in the future. Although I loved
Re: [sword-devel] Android SWORD
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 state of Bible software currently available, I'm excited about helping develop a good SWORD-powered Bible reader for it. I installed Troy's bishop2.apk and tried to download a module... fail (logcat at end of message). So I went looking for the code to see if I could track down the problem... but I haven't found any source code anywhere. Is that intentional, or am I missing something? As a user (previously of Laridian on WinMo), I've made this list of requirements for a Bible reader: - local storage - fast navigation UI (Laridian had specialized T9 for book names. You could get most anywhere in the Bible in about 6 keypresses.) - continuous scrolling (across chapter divisions) - cross references and footnotes - word/phrase search (perhaps fuzzy?) optional features: - scripture memory helper (I have a lot of concrete ideas here) - finding related resources (e.g., sermons) from selected resources - daily reading (or at least what's next after things I've read recently?) - screen orientation lock - song lyrics - history tracking (what passages did I look up while studying yesterday?), perhaps communally (what books have my friends been reading?) Any other interest in helping out? How can we organize a team? Martin, if you're still listening, I'd love to check out your code too. -Ken PS - here's the `adb logcat` from a failed module download. Turns out it succeeds if you create a 'modules' directory inside /sdcard/sword :) -- but then there are plenty of other issues. 08-24 23:19:46.443 2002 2021 D libsword.so: remoteInstallModule: sourceName: CrossWire 08-24 23:19:46.443 2002 2021 D libsword.so: remoteInstallModule: modName: ESV 08-24 23:19:46.443 2002 2021 D libsword.so: * InstallMgr::installModule 08-24 23:19:46.443 2002 2021 D libsword.so: * modName: ESV 08-24 23:19:47.286 2002 2021 D libsword.so: * mgr.prefixPath: /sdcard/sword/InstallMgr/20081216195754/ 08-24 23:19:47.286 2002 2021 D libsword.so: * destMgr-prefixPath: /sdcard/sword/ 08-24 23:19:47.286 2002 2021 D libsword.so: * absolutePath: /sdcard/sword/InstallMgr/20081216195754/modules/texts/ztext/esv/ 08-24 23:19:47.286 2002 2021 D libsword.so: * relativePath: modules/texts/ztext/esv/ 08-24 23:19:47.286 2002 2021 D libsword.so: netCopy: ftp.crosswire.org, modules/texts/ztext/esv/, /sdcard/sword/InstallMgr/20081216195754/modules/texts/ztext/esv/, t, 08-24 23:19:47.341 2002 2021 W System.err: Problem installing: -1 08-24 23:19:47.396 2002 2002 D libsword.so: getModInfoList returning 0 length array On Sun, Jun 13, 2010 at 4:30 AM, Martin Denham mjden...@gmail.com wrote: Hi Troy, Apologies, I
Re: [sword-devel] Android SWORD
I just got an Android phone, and after seeing the state of Bible software currently available, I'm excited about helping develop a good SWORD-powered Bible reader for it. I installed Troy's bishop2.apk and tried to download a module... fail (logcat at end of message). So I went looking for the code to see if I could track down the problem... but I haven't found any source code anywhere. Is that intentional, or am I missing something? As a user (previously of Laridian on WinMo), I've made this list of requirements for a Bible reader: - local storage - fast navigation UI (Laridian had specialized T9 for book names. You could get most anywhere in the Bible in about 6 keypresses.) - continuous scrolling (across chapter divisions) - cross references and footnotes - word/phrase search (perhaps fuzzy?) optional features: - scripture memory helper (I have a lot of concrete ideas here) - finding related resources (e.g., sermons) from selected resources - daily reading (or at least what's next after things I've read recently?) - screen orientation lock - song lyrics - history tracking (what passages did I look up while studying yesterday?), perhaps communally (what books have my friends been reading?) Any other interest in helping out? How can we organize a team? Martin, if you're still listening, I'd love to check out your code too. -Ken PS - here's the `adb logcat` from a failed module download. Turns out it succeeds if you create a 'modules' directory inside /sdcard/sword :) -- but then there are plenty of other issues. 08-24 23:19:46.443 2002 2021 D libsword.so: remoteInstallModule: sourceName: CrossWire 08-24 23:19:46.443 2002 2021 D libsword.so: remoteInstallModule: modName: ESV 08-24 23:19:46.443 2002 2021 D libsword.so: * InstallMgr::installModule 08-24 23:19:46.443 2002 2021 D libsword.so: * modName: ESV 08-24 23:19:47.286 2002 2021 D libsword.so: * mgr.prefixPath: /sdcard/sword/InstallMgr/20081216195754/ 08-24 23:19:47.286 2002 2021 D libsword.so: * destMgr-prefixPath: /sdcard/sword/ 08-24 23:19:47.286 2002 2021 D libsword.so: * absolutePath: /sdcard/sword/InstallMgr/20081216195754/modules/texts/ztext/esv/ 08-24 23:19:47.286 2002 2021 D libsword.so: * relativePath: modules/texts/ztext/esv/ 08-24 23:19:47.286 2002 2021 D libsword.so: netCopy: ftp.crosswire.org, modules/texts/ztext/esv/, /sdcard/sword/InstallMgr/20081216195754/modules/texts/ztext/esv/, t, 08-24 23:19:47.341 2002 2021 W System.err: Problem installing: -1 08-24 23:19:47.396 2002 2002 D libsword.so: getModInfoList returning 0 length array On Sun, Jun 13, 2010 at 4:30 AM, Martin Denham mjden...@gmail.com wrote: Hi Troy, Apologies, I was a bit confused regarding the different projects. The above was my first post to *Sword forums. I incorrectly thought that JSword, Sword and other Crosswire forums would be worked on by the same people. I have now joined the JSword-dev list which I had not spotted before. Whether the back end is built based on Sword or JSword it might be worthwhile combining with the Java Jsword guys for the front end which I think has to be in Java. I may download your apk and try it out. I can put my code/build somewhere if you want but it's still in a state of great flux. Kind regards Martin On 13 June 2010 04:54, Troy A. Griffitts scr...@crosswire.org wrote: Martin, Great news on your success of getting JSword to build on Android. I'm sure the JSword mailing list would be interested to hear about your success! I'm not sure about the speed. I will add a primitive search box to my test app and let you know how long a complete search of the KJV (a heavily marked up Bible) takes on my G1. Troy. On 06/09/2010 05:28 AM, mjdenham wrote: Hi Troy, I just thought I would mention that I have also been playing around with Android. I have spent the last few weeks creating a prototype bible viewer application for Android, but I just noticed Troy's messages in this forum. I took a slightly different technical approach to you and I don't know which is better and I also came at this project with the aim of creating a mobile bible viewer I could tweak and improve rather than specifically to write an Android front end for Sword. By way of information I thought I would outline my approach and what led me to start. I have used Pocket e-Sword for many years but development has now ceased on Pocket e-Sword and it is already looking a bit old, as is WinMob that it runs on, so I started thinking what to use in the future. Although I loved using Pocket e-sword there were one or two things that I would have loved to change if I had access to the source but the source was closed. Most pocket bible apps seem to be closed source and many charge money or depend on being on-line so I began to think about writing my own. I have been writing Java code for a living since the 90's. I looked at Java ME which
Re: [sword-devel] Android SWORD
I have posted a new build of Bishop and libsword.so built with r4 of the NDK with debug support, so you can attach to it with ndk-gdb if necessary. I had better luck with this build connecting and downloading Bibles from remote repositories. http://crosswire.org/~scribe/bishop2.apk 06/09/2010 08:01 AM, SonWon wrote: I would be glad to provide input for the user interface. On Wed, Jun 9, 2010 at 8:28 AM, mjdenham mjden...@gmail.com mailto:mjden...@gmail.com wrote: Hi Troy, I just thought I would mention that I have also been playing around with Android. I have spent the last few weeks creating a prototype bible viewer application for Android, but I just noticed Troy's messages in this forum. I took a slightly different technical approach to you and I don't know which is better and I also came at this project with the aim of creating a mobile bible viewer I could tweak and improve rather than specifically to write an Android front end for Sword. By way of information I thought I would outline my approach and what led me to start. I have used Pocket e-Sword for many years but development has now ceased on Pocket e-Sword and it is already looking a bit old, as is WinMob that it runs on, so I started thinking what to use in the future. Although I loved using Pocket e-sword there were one or two things that I would have loved to change if I had access to the source but the source was closed. Most pocket bible apps seem to be closed source and many charge money or depend on being on-line so I began to think about writing my own. I have been writing Java code for a living since the 90's. I looked at Java ME which unfortunately is not supported by recent, popular, trend-setting phones like iPhone and Android and started going that route but there doesn't seem to be much http://stackoverflow.com/questions/1414288/j2me-vs-android-vs-iphone-vs-symbian-vs-windows-ce buzz around Java ME at the moment. I briefly thought of iPhone but refuse to learn Objective-C, buy a Mac, and bend over backwards to get the app into App Store. Then I realised that Google have built Android primarily for Java Applications and Gartner predict that by 2012 Android will outsell the iPhone so I downloaded the Android SDK and am impresed by the application framework Google have put into Android. Incidentally I went to a fascinating talk on Android by Reto Meier yesterday evening. As Android hosts Java apps so well it seemed a good idea to use java front to back so I downloaded the jSword and sword-Common projects back-end to serve the OSIS documents and started creating a Java front-end for jsword on Android so I have now been doing that for the last couple of weeks off and on. I included the jsword and common jars in my Android app and simplified the xslt template I found in bible-desktop and now have a basic bible viewer app. Troy, I am interested to see that you use jni to access a C back-end. Is that right? Does this give better performance or is there another reason. In the front end I am currently using a TextView but briefly used a WebView which has better html support. I may have to switch back to WebView. I tried to copy the PocketSword verse selection screen but failed so I am just using 3 combos for now. I haven't used Crosswire code before and it took me a while to get used to OSIS and jsword but the code looks great and I am now familiar enough with jsword to find my way around the necessary parts. Here is a screen print of the current state: http://sword-dev.350566.n4.nabble.com/file/n2248754/android-bible1.jpg For now I am still happily trying to improve on the prototype but I could switch and contribute to a central project with others. My only aim is to create a good open source bible I can tweak and that others may find useful too. Best regards Martin -- View this message in context: http://sword-dev.350566.n4.nabble.com/Android-SWORD-tp360475p2248754.html Sent from the SWORD Dev mailing list archive at Nabble.com. ___ sword-devel mailing list: sword-devel@crosswire.org mailto:sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
Martin, Great news on your success of getting JSword to build on Android. I'm sure the JSword mailing list would be interested to hear about your success! I'm not sure about the speed. I will add a primitive search box to my test app and let you know how long a complete search of the KJV (a heavily marked up Bible) takes on my G1. Troy. On 06/09/2010 05:28 AM, mjdenham wrote: Hi Troy, I just thought I would mention that I have also been playing around with Android. I have spent the last few weeks creating a prototype bible viewer application for Android, but I just noticed Troy's messages in this forum. I took a slightly different technical approach to you and I don't know which is better and I also came at this project with the aim of creating a mobile bible viewer I could tweak and improve rather than specifically to write an Android front end for Sword. By way of information I thought I would outline my approach and what led me to start. I have used Pocket e-Sword for many years but development has now ceased on Pocket e-Sword and it is already looking a bit old, as is WinMob that it runs on, so I started thinking what to use in the future. Although I loved using Pocket e-sword there were one or two things that I would have loved to change if I had access to the source but the source was closed. Most pocket bible apps seem to be closed source and many charge money or depend on being on-line so I began to think about writing my own. I have been writing Java code for a living since the 90's. I looked at Java ME which unfortunately is not supported by recent, popular, trend-setting phones like iPhone and Android and started going that route but there doesn't seem to be much http://stackoverflow.com/questions/1414288/j2me-vs-android-vs-iphone-vs-symbian-vs-windows-ce buzz around Java ME at the moment. I briefly thought of iPhone but refuse to learn Objective-C, buy a Mac, and bend over backwards to get the app into App Store. Then I realised that Google have built Android primarily for Java Applications and Gartner predict that by 2012 Android will outsell the iPhone so I downloaded the Android SDK and am impresed by the application framework Google have put into Android. Incidentally I went to a fascinating talk on Android by Reto Meier yesterday evening. As Android hosts Java apps so well it seemed a good idea to use java front to back so I downloaded the jSword and sword-Common projects back-end to serve the OSIS documents and started creating a Java front-end for jsword on Android so I have now been doing that for the last couple of weeks off and on. I included the jsword and common jars in my Android app and simplified the xslt template I found in bible-desktop and now have a basic bible viewer app. Troy, I am interested to see that you use jni to access a C back-end. Is that right? Does this give better performance or is there another reason. In the front end I am currently using a TextView but briefly used a WebView which has better html support. I may have to switch back to WebView. I tried to copy the PocketSword verse selection screen but failed so I am just using 3 combos for now. I haven't used Crosswire code before and it took me a while to get used to OSIS and jsword but the code looks great and I am now familiar enough with jsword to find my way around the necessary parts. Here is a screen print of the current state: http://sword-dev.350566.n4.nabble.com/file/n2248754/android-bible1.jpg For now I am still happily trying to improve on the prototype but I could switch and contribute to a central project with others. My only aim is to create a good open source bible I can tweak and that others may find useful too. Best regards Martin ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
A couple weeks ago Troy posted this message: - Dear Vitaliy, The SWORD library has been ported to Android with Java wrapper classes via the NDK. Instructions for building can be found in the trunk of our svn repository under bindings/java-jni/README. http://crosswire.org/svn/sword/trunk/bindings/java-jni/README When developing the bindings, I had a test program I used to test the calls to the engine. I called it Bishop, but have not continued to develop it into a fully usable application. I could post the source, but I'd rather see what a real Android UI developer can do with the bindings instead. The port is very preliminary so please let me know if things seem not to work as you'd expect. - If I understand that correctly, Bishop was never intended to be the actual Android SWORD frontend but only a feasibility demonstration. When I get some time free from my other Android projects I hope to take a whack at this one but I don't use Java or C so there may be a learning curve. -- Kermit Kiser (BSV module developer) AndRexx Applications SonWon wrote: Any more progress on the Android Bible Reader? On Mon, Oct 12, 2009 at 1:46 PM, Troy A. Griffitts scr...@crosswire.org mailto:scr...@crosswire.org wrote: There is now a preliminary Android NDK / Java binding available in SVN. This is very very early and should just be considered a proof of concept. There is a package available to show things working, but doesn't really do much: http://crosswire.org/~scribe/bishop.apk http://crosswire.org/%7Escribe/bishop.apk the JNI libsword.so should be placed in your project/libs directory, e.g., ~/workspace/bishop/libs/armeabi/libsword.so and can be obtained from the above package-- believe me, you don't want to try to compile it yourself as the NDK does not have STL support out of the box. The Java classes can be obtained from the sword/bindings/java-jni/src directory, e.g. http://crosswire.org/svn/sword/trunk/bindings/java-jni/src/org/crosswire/android/sword/ Module library must exist on your SD card under a 'sword' directory to be found, e.g., unzip KJV.zip to /sdcard/sword/ Have fun, let me know if anyone else is interested in developing an Android frontend. -Troy. ___ sword-devel mailing list: sword-devel@crosswire.org mailto:sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
I could help with user interface design and testing but would need someone who could code. On Tue, Jun 8, 2010 at 6:38 PM, Kermit Kiser b...@kermitkiser.com wrote: A couple weeks ago Troy posted this message: - Dear Vitaliy, The SWORD library has been ported to Android with Java wrapper classes via the NDK. Instructions for building can be found in the trunk of our svn repository under bindings/java-jni/README. http://crosswire.org/svn/sword/trunk/bindings/java-jni/README When developing the bindings, I had a test program I used to test the calls to the engine. I called it Bishop, but have not continued to develop it into a fully usable application. I could post the source, but I'd rather see what a real Android UI developer can do with the bindings instead. The port is very preliminary so please let me know if things seem not to work as you'd expect. - If I understand that correctly, Bishop was never intended to be the actual Android SWORD frontend but only a feasibility demonstration. When I get some time free from my other Android projects I hope to take a whack at this one but I don't use Java or C so there may be a learning curve. -- Kermit Kiser (BSV module developer) AndRexx Applications SonWon wrote: Any more progress on the Android Bible Reader? On Mon, Oct 12, 2009 at 1:46 PM, Troy A. Griffitts scr...@crosswire.orgwrote: There is now a preliminary Android NDK / Java binding available in SVN. This is very very early and should just be considered a proof of concept. There is a package available to show things working, but doesn't really do much: http://crosswire.org/~scribe/bishop.apkhttp://crosswire.org/%7Escribe/bishop.apk the JNI libsword.so should be placed in your project/libs directory, e.g., ~/workspace/bishop/libs/armeabi/libsword.so and can be obtained from the above package-- believe me, you don't want to try to compile it yourself as the NDK does not have STL support out of the box. The Java classes can be obtained from the sword/bindings/java-jni/src directory, e.g. http://crosswire.org/svn/sword/trunk/bindings/java-jni/src/org/crosswire/android/sword/ Module library must exist on your SD card under a 'sword' directory to be found, e.g., unzip KJV.zip to /sdcard/sword/ Have fun, let me know if anyone else is interested in developing an Android frontend. -Troy. ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page -- ___ sword-devel mailing list: sword-de...@crosswire.orghttp://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
[sword-devel] Android SWORD
Hello all, I hope I am at the right place to enquire if anyone is working on this project and if there is any progress made on it since last October? As many new phone came out recently running Android 2 it would be great to have it available on there too. Thanks, joey d. Re: [sword-devel] Android SWORD Troy A. Griffitts Wed, 21 Oct 2009 01:09:21 -0700 A quick update on Android progress. o Basic Bible navigation and display are working, albeit not pretty. o Text-to-Speech functionality is added. o All methods from the engine are now completely wrapped to the same swordorb.idl interface we use for SWORDWeb's Java-CORBA-C++ bridge, so a full-featured Android client should now be possible with the current engine exposure. Everything is still at the same location (below). -Troy. Troy A. Griffitts wrote: There is now a preliminary Android NDK / Java binding available in SVN. This is very very early and should just be considered a proof of concept. There is a package available to show things working, but doesn't really do much: http://crosswire.org/~scribe/bishop.apk http://crosswire.org/%7Escribe/bishop.apk the JNI libsword.so should be placed in your project/libs directory, e.g., ~/workspace/bishop/libs/armeabi/libsword.so and can be obtained from the above package-- believe me, you don't want to try to compile it yourself as the NDK does not have STL support out of the box. The Java classes can be obtained from the sword/bindings/java-jni/src directory, e.g. http://crosswire.org/svn/sword/trunk/bindings/java-jni/src/org/crosswire/android/sword/ Module library must exist on your SD card under a 'sword' directory to be found, e.g., unzip KJV.zip to /sdcard/sword/ Have fun, let me know if anyone else is interested in developing an Android frontend. -Troy. ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
Hey Joey, Yeah, It's still slowly making progress. All work for the JNI wrapper of the SWORD lib for Android is checked into SVN under the bindings folder of the lib source if you'd like to play. There are a few emails on sword-devel about how to compile it, which I'm sure you could file with a quick search. The actual end user application isn't checked in anywhere, as it is just a bunch of very basic calls to the engine to grab a chapter of text, search, install a module, etc., as a test of the bindings. A nicely designed user interface is needed. Hope to have more time to spend on it after I finish some not-so-fun-but-necessary tasks on other projects. Troy On 05/17/2010 09:04 AM, Joe Dobrik wrote: Hello all, I hope I am at the right place to enquire if anyone is working on this project and if there is any progress made on it since last October? As many new phone came out recently running Android 2 it would be great to have it available on there too. Thanks, joey d. Re: [sword-devel] Android SWORD Troy A. Griffitts Wed, 21 Oct 2009 01:09:21 -0700 A quick update on Android progress. o Basic Bible navigation and display are working, albeit not pretty. o Text-to-Speech functionality is added. o All methods from the engine are now completely wrapped to the same swordorb.idl interface we use for SWORDWeb's Java-CORBA-C++ bridge, so a full-featured Android client should now be possible with the current engine exposure. Everything is still at the same location (below). -Troy. Troy A. Griffitts wrote: There is now a preliminary Android NDK / Java binding available in SVN. This is very very early and should just be considered a proof of concept. There is a package available to show things working, but doesn't really do much: http://crosswire.org/~scribe/bishop.apk http://crosswire.org/%7Escribe/bishop.apk the JNI libsword.so should be placed in your project/libs directory, e.g., ~/workspace/bishop/libs/armeabi/libsword.so and can be obtained from the above package-- believe me, you don't want to try to compile it yourself as the NDK does not have STL support out of the box. The Java classes can be obtained from the sword/bindings/java-jni/src directory, e.g. http://crosswire.org/svn/sword/trunk/bindings/java-jni/src/org/crosswire/android/sword/ Module library must exist on your SD card under a 'sword' directory to be found, e.g., unzip KJV.zip to /sdcard/sword/ Have fun, let me know if anyone else is interested in developing an Android frontend. -Troy. ___ sword-devel mailing list: sword-devel@crosswire.org mailto:sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org mailto:sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
Troy, Is there any chance we could start up a seperate project/repo for an Android front-end? Now that I'm done with my project (flashcard clone for Android) I would love to help out with an Android Bible app. Especially since I've begun to notice the abrupt shortcomings of the other Android Bible apps. -Wes On Mon, May 17, 2010 at 12:43 PM, Troy A. Griffitts scr...@crosswire.orgwrote: Hey Joey, Yeah, It's still slowly making progress. All work for the JNI wrapper of the SWORD lib for Android is checked into SVN under the bindings folder of the lib source if you'd like to play. There are a few emails on sword-devel about how to compile it, which I'm sure you could file with a quick search. The actual end user application isn't checked in anywhere, as it is just a bunch of very basic calls to the engine to grab a chapter of text, search, install a module, etc., as a test of the bindings. A nicely designed user interface is needed. Hope to have more time to spend on it after I finish some not-so-fun-but-necessary tasks on other projects. Troy On 05/17/2010 09:04 AM, Joe Dobrik wrote: Hello all, I hope I am at the right place to enquire if anyone is working on this project and if there is any progress made on it since last October? As many new phone came out recently running Android 2 it would be great to have it available on there too. Thanks, joey d. Re: [sword-devel] Android SWORD Troy A. Griffitts Wed, 21 Oct 2009 01:09:21 -0700 A quick update on Android progress. o Basic Bible navigation and display are working, albeit not pretty. o Text-to-Speech functionality is added. o All methods from the engine are now completely wrapped to the same swordorb.idl interface we use for SWORDWeb's Java-CORBA-C++ bridge, so a full-featured Android client should now be possible with the current engine exposure. Everything is still at the same location (below). -Troy. Troy A. Griffitts wrote: There is now a preliminary Android NDK / Java binding available in SVN. This is very very early and should just be considered a proof of concept. There is a package available to show things working, but doesn't really do much: http://crosswire.org/~scribe/bishop.apk http://crosswire.org/%7Escribe/bishop.apk the JNI libsword.so should be placed in your project/libs directory, e.g., ~/workspace/bishop/libs/armeabi/libsword.so and can be obtained from the above package-- believe me, you don't want to try to compile it yourself as the NDK does not have STL support out of the box. The Java classes can be obtained from the sword/bindings/java-jni/src directory, e.g. http://crosswire.org/svn/sword/trunk/bindings/java-jni/src/org/crosswire/android/sword/ Module library must exist on your SD card under a 'sword' directory to be found, e.g., unzip KJV.zip to /sdcard/sword/ Have fun, let me know if anyone else is interested in developing an Android frontend. -Troy. ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-de...@crosswire.orghttp://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-de...@crosswire.orghttp://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
Just found this via Google. How to install fonts in Android http://code.google.com/p/softkeyboard/wiki/InstallHebrewFonts http://code.google.com/p/softkeyboard/wiki/InstallHebrewFonts Rooting an unrooted device will revoke your warranty! - btw. I haven't tried Hebrew or Greek yet, though we know that Cyrillic has extended coverage. We also know Android does not support the Burmese script by default, unless one can install a suitable font. David Haslam -- View this message in context: http://www.nabble.com/Android-SWORD-tp25860243p26022790.html Sent from the SWORD Dev mailing list archive at Nabble.com. ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
A quick update on Android progress. o Basic Bible navigation and display are working, albeit not pretty. o Text-to-Speech functionality is added. o All methods from the engine are now completely wrapped to the same swordorb.idl interface we use for SWORDWeb's Java-CORBA-C++ bridge, so a full-featured Android client should now be possible with the current engine exposure. Everything is still at the same location (below). -Troy. Troy A. Griffitts wrote: There is now a preliminary Android NDK / Java binding available in SVN. This is very very early and should just be considered a proof of concept. There is a package available to show things working, but doesn't really do much: http://crosswire.org/~scribe/bishop.apk the JNI libsword.so should be placed in your project/libs directory, e.g., ~/workspace/bishop/libs/armeabi/libsword.so and can be obtained from the above package-- believe me, you don't want to try to compile it yourself as the NDK does not have STL support out of the box. The Java classes can be obtained from the sword/bindings/java-jni/src directory, e.g. http://crosswire.org/svn/sword/trunk/bindings/java-jni/src/org/crosswire/android/sword/ Module library must exist on your SD card under a 'sword' directory to be found, e.g., unzip KJV.zip to /sdcard/sword/ Have fun, let me know if anyone else is interested in developing an Android frontend. -Troy. ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
On Wed, Oct 21, 2009 at 01:05:22AM -0700, Troy A. Griffitts wrote: A quick update on Android progress. I read this morning that Nook, an ebook running Android is in pre-order state: http://www.barnesandnoble.com/nook/features/ US only and probably not really open :( -- Sébastien Koechlin ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
[sword-devel] Android SWORD
There is now a preliminary Android NDK / Java binding available in SVN. This is very very early and should just be considered a proof of concept. There is a package available to show things working, but doesn't really do much: http://crosswire.org/~scribe/bishop.apk the JNI libsword.so should be placed in your project/libs directory, e.g., ~/workspace/bishop/libs/armeabi/libsword.so and can be obtained from the above package-- believe me, you don't want to try to compile it yourself as the NDK does not have STL support out of the box. The Java classes can be obtained from the sword/bindings/java-jni/src directory, e.g. http://crosswire.org/svn/sword/trunk/bindings/java-jni/src/org/crosswire/android/sword/ Module library must exist on your SD card under a 'sword' directory to be found, e.g., unzip KJV.zip to /sdcard/sword/ Have fun, let me know if anyone else is interested in developing an Android frontend. -Troy. ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Android SWORD
Great news! I'll be getting an android phone within the month and would love to help out! Thanks for your work Troy! Cheers, David On Mon, Oct 12, 2009 at 11:46 AM, Troy A. Griffitts scr...@crosswire.orgwrote: There is now a preliminary Android NDK / Java binding available in SVN. This is very very early and should just be considered a proof of concept. There is a package available to show things working, but doesn't really do much: http://crosswire.org/~scribe/bishop.apkhttp://crosswire.org/%7Escribe/bishop.apk the JNI libsword.so should be placed in your project/libs directory, e.g., ~/workspace/bishop/libs/armeabi/libsword.so and can be obtained from the above package-- believe me, you don't want to try to compile it yourself as the NDK does not have STL support out of the box. The Java classes can be obtained from the sword/bindings/java-jni/src directory, e.g. http://crosswire.org/svn/sword/trunk/bindings/java-jni/src/org/crosswire/android/sword/ Module library must exist on your SD card under a 'sword' directory to be found, e.g., unzip KJV.zip to /sdcard/sword/ Have fun, let me know if anyone else is interested in developing an Android frontend. -Troy. ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
