Libanki 2.0
nobnago
A week ago, Damien has released a first preview of the new libanki2.0.
It contains some great new features like a learning mode and better
study groups. But the best thing is maybe that it will boost all db
operations due to a skinnier db schema. Up to now, answering cards on
bigger decks did always take a bit to long (even on my SGS i9000)
which makes learning a lot more ardious.
An overview of the changes can be found here: http://ankisrs.net/docs/changes.html
Because the db schema has been changed almost completely, AnkiDroid's
libanki code has to be rewritten for very large parts which I've
started with the last days. As of now the core parts (e.g. the
scheduler) are nearly done, but there is still a lot to do. I'll push
the new code as soon as the core parts work, so we can reimplement all
extras like tags, media, latex support, adding/changing facts,
syncing, groups, stats...
Cheers!
Norbert
vanosten
Could you elaborate a bit more, because I have some interest of moving the libanki part out in its separate packages in AnkiDroid:
- Do you actually have access to the new libanki2.0 code (Python)? I might not be able to see the obvious - but I simply cannot find the right branch on Github :-(
- Are you already working on separating libanki code from the rest of AnkiDroid? Or are you preparing for this as of Anki2.0, which probably first will be out in a few months? Depending on the answer it makes or does not make sense to start separating the libanki part in AnkiDroid already now or not.
- If someone is looking into separating libanki: will it be a Java-Android libanki library or will it actually be an abstract Java-libanki library with a concrete implementation for Android (i.e. hooks for Android specific code, but re-usable in non-Android contexts)?
Jan Berkel
> AnkiDroid? Or are you preparing for this as of Anki2.0, which probably first
> will be out in a few months? Depending on the answer it makes or does not
> make sense to start separating the libanki part in AnkiDroid already now or
> not.
this just got discussed here:
https://groups.google.com/d/msg/anki-android/kTK5kLJ-U0o/Xk0Aa3h-dHEJ
would be great to have them separated - will have a look at it to see
how much work it is.
jan
nobnago
you find the actual ankidroid-code with libanki 2.0 here:
https://github.com/nobnago/Anki-Android/tree/libanki2.0
> - Do you actually have access to the new libanki2.0 code (Python)? I
> branch on Github :-(
> - Are you already working on separating libanki code from the rest of
> will be out in a few months? Depending on the answer it makes or does not
> make sense to start separating the libanki part in AnkiDroid already now or
> not.
code is now in the subdirectory "libanki" and follows as far as
possible the anki desktop file names.
> - If someone is looking into separating libanki: will it be a
> library with a concrete implementation for Android (i.e. hooks for Android
> specific code, but re-usable in non-Android contexts)?
necessarily ensued a more abstract java-libanki. So probably a re-use
should be easily possible.
__
I've finished porting libanki for the better part of code and adapted
the most important parts of the ui code as well. So, reviewing,
browsing, editing and adding cards should work by now as well as
statistics and some some preferences. But since the libanki-code is
still subject to change there will be more to do later. Of course, it
has to be heavily tested before used on actual decks. But testing
should be done not before python-libanki is more or less stable.
If you want to have a look into it now, open a copy of a deck in anki
desktop 2.0 alpha, convert your deck and open with ankidroid-
libanki2.0 (you can just copy it in your default ankidroid folder, it
won't harm your other decks. Because deck upgrade is not yet
implemented your old decks will not even be shown).
What's not done yet:
- syncing
- cramming (not yet in python-libanki)
- group support (probably not that easy to find an elegant way for the
ui)
- deck upgrade
- testing, testing, testing
So, that is how matters stand so far...
Cheers!
Norbert
Nicolas Raoul
Glad to know you even split the SRS and UI code at the same time!
In the rest of my email I will be hair-splitting about separation...
In the libanki package of the libanki2.0 branch, I can still see some
Android-specific imports:
import android.content.ContentValues;
import android.database.Cursor;
import android.util.Log;
This will be a problem when running java-libanki based programs on
other platforms like Blackberry.
I can see three solutions, feel free to propose other:
Solution 1:
Design a system abstraction layer that provides services such as
logging and database and use it. Then implement that abstraction layer
for every platform.
UI → java-libanki → system abstraction → actual system's db+log+...
(a → b means that package a imports package b)
Solution 2:
Don't care for now, and just create an "Android emulation layer" for
future platforms, for instance a library implementing android.database
using Blackberry's database (which is also SQLite by the way)
UI → java-libanki → "Android"'s db+log+... → actual system's db+log+...
Solution 3:
Fork android-java-libanki to java-libanki (which would use
uncustomized latest stable versions of SQLite,etc) and
blackberry-java-libanki. Thanks to Git, maintenance of the forks
should not be hard for their respective maintainers.
Solution 1 is cleaner, but it is more initial work, more maintenance,
and it introduces a layer that will affect performance a little bit.
Solution 2 makes the code look awkward on other platforms.
Pragmatically, I would be voting for solution 3.
What do you think?
Cheers!
Nicolas Raoul
Robert Siemer
> In the libanki package of the libanki2.0 branch, I can still see some
> Android-specific imports:
> import android.content.ContentValues;
> import android.database.Cursor;
> import android.util.Log;
>
> This will be a problem when running java-libanki based programs on
> other platforms like Blackberry.
> I can see three solutions, feel free to propose other:
>
> Solution 1:
> Design a system abstraction layer that provides services such as
> logging and database and use it. Then implement that abstraction layer
> for every platform.
> UI → java-libanki → system abstraction → actual system's db+log+...
> (a → b means that package a imports package b)
More than half of the system abstraction would be database handling. –
There are a bunch of ORMs for Java, a bunch for Android, some both. Even
a not so portable ORM solution would be easy to replace with an adequate
ORM on the target system.
The resulting java-libanki would be easier to maintain or improve as well.
Anyone in?
Robert
vanosten
I wondered whether it would make sense to clearly mark classes,
methods and even fields with regards to port from Python vs. native
AnkiDroid. E.g. for each class and method ported from libanki I would
suggest that the JavaDoc clearly specifies, what it relates to. E.g.
/**
* PORT_INFO: libanki -> anki -> fo.py -> foo_method
* ...
*/
One could even have a standard for telling whether it is ported or
just derived (in those cases, where a Python method might be
implemented in several Java methods).
And on the other side methods and fields only used for Java/AnkiDroid
could be identified e.g. with a naming convention (e.g. method
doSomethingJS, field myPropertyJS; where JS stands for "Java
Specific".
Rick
Nicolas Raoul
I totally agree for the Javadoc.
"JS" is easily confused with JavaScript, which is also a language used
by Anki decks, so how about a more explicit "xxxJava", or even
"xxxJavaSpecific" if they are a minority?
Cheers!
Nicolas Raoul
> --
> You received this message because you are subscribed to the Google Groups "AnkiDroid" group.
> To post to this group, send an email to anki-a...@googlegroups.com.
> To unsubscribe from this group, send email to anki-android...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/anki-android?hl=en-GB.
>
>
Robert Siemer
> Hi
>
> I wondered whether it would make sense to clearly mark classes,
> methods and even fields with regards to port from Python vs. native
> AnkiDroid. E.g. for each class and method ported from libanki I would
> suggest that the JavaDoc clearly specifies, what it relates to. E.g.
>
> /**
> * PORT_INFO: libanki -> anki -> fo.py -> foo_method
> * ...
> */
What would that be useful for?
I saw a lot of Python (lib)anki and am now hacking in Ankidroid and I
never missed that information... The opposite: it adds more
to-be-manually-maintained noise to the source. – I’m not going to
introduce variables named xyzJavaSpecific, nor will I encourage anyone
else to do so.
Maybe it is not even Java specific, but a new feature...
Robert
Nicolas Raoul
> What would that be useful for?
It makes it easier to port python-libanki enhancements to java-libanki.
The people who would be the best able to judge the usefulness of this
are Daniel, Edu, Norbert, since are of them has done a lot of
python-libanki→java-libanki porting.
Daniel, Edu, Norbert, do you have an opinion on this?
> Maybe it is not even Java specific, but a new feature...
AnkiDroid's new features are developed outside of the java-libanki
package, so they are not concerned with this discussion.
Your Panki branch is special because you are modifying libanki's
functionalities. So indeed you will probably establish a different
convention for methods that are specific to your branch.
Cheers!
Nicolas Raoul
nobnago
I think it's a good idea, to make clear where every part of the code
comes from. For the sake of simplicity, it should be easier to mark
these functions and variables which are *not* derived from python
libanki but only ankidroid-specific. The libanki code is already
separated from the ui code; so, generally, all functions in the
libanki-folder are ported python functions (in order to make
maintenance easier, I kept all names exactly as they were in python)
and only some parts were different, which we could mark these.
As for the principal seperating policy: I would vote for Nicolas'
solution no. 3 as well. We don't even know whether someone will make
sometime use of a java libanki and even if it's shouldn't be to hard
to change the few android-related code parts...
Cheers!
Norbert