gnucash-android implementation (Three projects for Gnucash)

[John Ralls]

On Feb 6, 2011, at 11:44 AM, Christian Stimming wrote:

> Am Sonntag, 6. Februar 2011 schrieb John Ralls:
>> On Feb 6, 2011, at 7:56 AM, John Gray wrote:
>>> There are a few of us who are working on android version right now.
>>> 
>>> Right now its reading in from the sqlite db.   It reads in everything
>>> and displays the accounts with balances, and let you add transactions.
>>> 
>>> Look here for its status:
>>> http://gnc4a.rednus.co.uk/
>> 
>> That "adding transactions" bit is unwise. It's unlikely that you'll be able
>> to do that correctly without using (at least) libgncmodule-engine and
>> libgnc-qof.
> 
> Technically, I agree with John. (Heh, I mean gnucash's John Ralls here.) 
> However, because I also happen to know a bit about android, I agree with the 
> gnc4a team that this is the only (!) viable approach for the first steps of 
> gnucash on android. 
> 
> The point is that it is *impossible* to use the existing C code on android. 
> (Either porting libgncmodule-engine to java, or trying to compile the C code 
> natively for each target device + architecture so you loose all the java-
> advantages and even that won't work because I'm rather sure glib won't compile 
> natively on the target architectures.) I repeat: Impossible.
> 
> Hence, the user request of "having something like gnucash on android" 
> automatically leads to the technical solution of directly accessing the SQL 
> storage from the completely independent gnc4a implementation. I agree this is 
> not what we, the gnucash team, have been preaching all along, but we always 
> talked about a PC-based architecture and couldn't ever imagine a user request 
> for such a different device as android devices are.
> 
>> If you can't pull in the necessary gnucash libraries, write out an
>> interchange file in one of the formats Gnucash or AQBanking understands 
>> with your new transactions and have the user import that file into
>> Gnucash.
> 
> There is no such interchange file format available as well at the moment. 
> Again: Even though in gnucash we always insisted you have to use the existing 
> C code, the situation now has changed and there is a significant user request 
> which can technically be solved only by re-implementing everything in a 
> different language that will access the SQL directly.
> 
> So we, the gnucash team, have to reconsider our original point of view and 
> should better get to live with the new changed situation...

It's not a viable approach. The KVP will be wrong, the data corrupt, and the users very unhappy.

Isn't it possible to use C libraries on Android through the NDK?

Failing that, there's a Sourceforge project in Java called Eurobudget that's GPL and is supposed to be able to read and write QIF. Take their code. Or translate libofx into Java. Or translate libqof and the engine into Java. 

That said, yes, we need to get Gnucash into a state where it uses a good schema that can use pure SQL to query and update the backend. We've talked before about what it's going to take to get there, and it's going to take a while.

Regards,
John Ralls