gnucash-android implementation (Three projects for Gnucash)
stimming at tuhh.de
Sun Feb 6 14:44:30 EST 2011
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
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
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...
More information about the gnucash-devel