[Ankidroid] Strategy with AnkiDroid code vs. Anki

[Rick Gruber-Riemer]

Hi

I am browsing through AnkiDroid's code to learn more about the code base, before making changes. I have one question, which might be obvious to the rest of you, but please bear with me:

Does the code try to mimik Anki's code as much as possible? Or do we "copy" code in a similar JAva way?

The reason why I am asking is that I find some dead code in the Java classes. One example is the Card(...) constructor in Card.java, which is never used. I personally prefer code that is clean from unused stuff and would prefer to delete it. This reduces confusion for someone like me. Also it makes it clearer where the implementation is heading (which I believe should be learning only plus evt. possibility to make new entries or change existing ones - everything related to defining card, field and deck properties should be left to Anki).

A related question: has somebody tried to look at performance by loading all card models and field models into memory on opening a new Deck? E.g. by having a Map<id, cardModel> and a Map<id, fieldModel> in Deck.java or as static fields in CardModel.java and FieldModel.java? This breaks maybe the programming model with respect to the Python code in Anki - but why bother?

--
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.

[Rick Gruber-Riemer]

To be a bit more specific taking CardModel as an example:

• Remove method copy
• Remove both constructors
  
• Replace method fromDB with a static HashMap, which either gets initialized by a method or initialized when it is first accessed (preferred). Initialized = fetch all models from database.

Then I also think that class Model could be removed for the time being if the fieldModel is available statically like cardModel would be.

My point is:

• Did I miss something, so AnkiDroid with the current functionality (and possibly future functionality) actually needs all this code?
• If I am right: would you allow some refactoring to reduce code? It would mean that the code is less like Anki's Python code base, but it would be cleaner code (and potentially better testable code). After all there is a history in Git ;-)
  

Rick

[Nicolas Raoul]

Hi Rick,

I understand all of this dead code can be disturbing.
I think we must distinguish between two kinds of classes:
- SRS code (Spaced Repetition)
- UI (User Interface)

Basically, the SRS code part is an line-by-line translation of libanki
from Python to Java, and it is not finished yet.
The code that is dead by now will probably get useful when all of
libanki is translated.
We could probably modify things to make them more Java-style, but it
would make it more difficult to maintain.
From time to time, libanki gets fixes or improvements, and we must
port these changes. It is much easier if the code has exactly the same
structure.

For the rest of the code, on the other side, you are free to do
whatever you see fit :-)

It would probably be a good thing to cleanly separate the libanki code
and the UI code, at least in different Java packages.
By the way, if the libanki code is made independent from the UI code,
that would probably allow a MIDP/Java ME version of Anki :-) That
would be quite useful because I think the number of JavaME cellphones
is hugely greater than the number of smartphones.

Cheers!
Nicolas Raoul

[Damien Elmes]

As Nicolas said, significantly diverging from the libanki code base
may make maintenance more difficult in the future.

> A related question: has somebody tried to look at performance by loading all
> card models and field models into memory on opening a new Deck? E.g. by
> having a Map<id, cardModel> and a Map<id, fieldModel> in Deck.java or as
> static fields in CardModel.java and FieldModel.java?

Early version of Anki did something like that. It means initial deck
load takes a long time, and it takes up a lot of memory. It is
especially bad on big decks of 20,000+ cards.

[Rick Gruber-Riemer]

Hi Nicolas

 

Ok. although I tend to not agree, I will respect the decision to keep the code struture close to Anki for everything related to libanki.

 

I would still like to ask an answer to a more strategic question (which has an influence on dead code etc):

• is the intention for AnkiDroid to go for a clone of Anki
• or is the intention to keep it at a level, where the purpose is to learn on-the-go plus evt. make new entries/edit existing entries without changing models and overall properties?

(I opt for the second if somebody is in doubt ;-)

 

PS: does this mean that someone is regularly parsing the diff of changes in Anki to see, whether it should be ported to AnkiDroid?

[Damien Elmes]

> I would still like to ask an answer to a more strategic question (which has
> an influence on dead code etc):

Sorry, I don't understand why you're so concerned about this. When you
account for adding cards, syncing, and being able to change active
tags, there really isn't much left.

[Nicolas Raoul]

Present situation:
- The SRS code uses the first strategy you described (clone of libanki)
- The UI uses the second strategy you described (do whatever is the
best for Android)

The current code is a proof that the two strategies are not mutually exclusive.
The two parts indeed use very different coding styles.
Maybe we should completely separate "libanki-java" and AnkiDroid?
AnkiDroid would just use libanki.jar

> someone is regularly parsing the diff of changes in Anki

Daniel sometimes does this for libanki. And I guess Damien would give
us a hint if a really important change happens? libanki does not
change that often, actually.

I think AnkiDroid's value is more about its user interface and
Android-oriented features. We probably can't beat the libanki code at
SRS, and personally I would actually be glad to just use the Python
libanki code directly, if there were a viable way to do so.

What do you think?

Cheers! :-)
Nicolas

[Edu Zamora]

Hi Rick,

I like that you have entered the group with so motivation and started questioning how things are done, because that forces us to think which is the best way to do it.

Said that, I agree both with Nicolas and Damien in regard that developing the libanki part as close as possible to the Python one (in fact, the code is not a line by line translation, but it tries to be close to it) will make the code easier to maintain and easier to test. I am curious, why did you think it would be easier to test if we break with the style of development of Anki Desktop? Maybe we missed something.

So to summarize, my opinion is that it is ok to clean the code but I would like the libanki part not to be unrelated to its Python counterpart.

This reduces confusion for someone like me. Also it makes it clearer where the implementation is heading (which I believe should be learning only plus evt. possibility to make new entries or change existing ones - everything related to defining card, field and deck properties should be left to Anki).

You are right on these but I think the code could be clearer if it was well documented and organized. It's something we should improve in the future. Also, state in the main page what is the final goal or mission statement of the group would be helpful for having a global idea where we all are heading.

I would still like to ask an answer to a more strategic question (which has an influence on dead code etc):

• is the intention for AnkiDroid to go for a clone of Anki
• or is the intention to keep it at a level, where the purpose is to learn on-the-go plus evt. make new entries/edit existing entries without changing models and overall properties?

Do you have any reason to not provide the users with the ability to modify the overall properties?
I don't see any right now... Anyway, I think your second option is the goal we have to aim for now so I think we should focus on this. But that does not mean it has to be our final destination: once that works fine we can provide the users with more options. If they want or not want to use them is up to them.

does this mean that someone is regularly parsing the diff of changes in Anki to see, whether it should be ported to AnkiDroid?

We just started porting the last version of libanki, 0.9.9.8.6, so not yet :P But in the future, when new versions of libanki are released, we should do that.

 

It would probably be a good thing to cleanly separate the libanki code
and the UI code

I think it is a really great idea Nicolas, separate the code independent to Android (like the libanki code) to the Activities used for the UI. I also would try to separate in another package the DB layer, although it is quite disperse.

Thank you a lot for your participation and your interest.

Cheers!

   Edu

[Rick Gruber-Riemer]

Hi

 

I would like to introduce unit testing into AnkiDroid code base. I would go after JUnit4 in version 4.5, which is already part of Eclipse. I would propose to have a test directory besides the existing src directory to contain the JUnit tests.

 

Any objections?

[Nicolas Raoul]

Great!!!
That is much needed.
I think that this "test" directory is the most natural. It will not be
packaged into the APK.
Thanks a lot!
Nicolas

[Rick Gruber-Riemer]

See http://www.vogella.de/articles/JUnit/article.html for an introduction of how to unit test in Eclipse with JUnit4.

[Edu Zamora]

Awesome, Rick, awesome!

I have been thinking about introducing some kind of automatic testing to AnkiDroid but I did not have a lot of time and I was not sure how to go about it. How do you think the strategy to test AnkiDroid would be?

I never used JUnit before so I will have to learn from scratch, but it is used in Android like in Java or is there something specific to it?

And what do you think about using Calculon for the UI too?
http://github.com/kaeppler/calculon
http://brainflush.wordpress.com/2010/01/10/introducing-calculon-a-java-dsl-for-android-activity-testing/

I have been looking forward to try this library for a long time.

Nothing to object! ;D