Mag in deinem Fall ja das richtige Mittel der Wahl sein, war hier aber leider nicht gefragt.
Ansichtssache. 
[...]sondern erst mal bei den Grundlagen helfen und die heissen in diesem Falle SQLite und sind mit reinen Bordmitteln zu erledigen.
Die Sache sehe ich ganz genau so.
Allerdings gab ich ihm hier den Tipp, sich doch mal durch das androideigene Grundlagentraining zum Thema SQLite Datenbanken zu arbeiten.
Statt dessen wird eines der unzähligen und mutmaßlich qualitativ nicht besonders hochwertigen Online-Tutorials genutzt, die alles tun – außer Grundlagen zu vermitteln.
So wie ich die Sachlage sehe steht Henry gerade am Anfang seiner Androidprogrammiererlaufbahn (siehe erstes Posting mit Verweis -> Tutorial) und daher denke ich sollte man Ihn jetzt nicht mit irgendwelchen Hilfskonzepten und Librarys überrollen [...]
Wenn er das verstanden hat, kann er sich ja gerne ORM Lite, greendao und wie Sie alle heissen anschauen.
Diese Sichtweise überrascht mich. Wann immer nach irgend einer Lösung für sein spezifisches Problem gefragt wird, bekommt man irgend eine Library empfohlen. Der ganze Programmierkrams läuft nur mit Libraries. Man hat es eigentlich immer mit Libraries zu tun. Warum dann für den Anfang nicht erst mal eine Library nutzen, die einem unnötige Arbeit abnimmt?
Mein persönliches Problem mit diesen 'SQLite Grundlagen' ist einfach das Folgende: man will eine objektorientierte Programmiersprache lernen und bekommt dann Hilfskonstrukte an die Hand gegeben, mit denen man prozedural logisch gespeicherte Datenstrukturen mit einem Objekt abgreift.
Hier wird das Objekt (der Cursor) eigentlich nur um eine Datenstruktur gekapselt, die Bearbeitung läuft dennoch stur nach Schema F der struktularen Programmierung ab: Position 1, Position 2, Position 3, Position 4...
Auch wenn Dinge wie .hasNext() helfen Exceptions vorzubeugen, ist doch das gesamte Konzept irgendwie skurril. Hat was von Binärdaten als HEX-String zu übergeben. Kann man machen, machen viele, ist aber nicht das Sinnvollste.
Wesentlich logischer wäre es doch, wenn man die ganze Zeit durch mit Objekten arbeitet.
In dem Fall hätte man eine ArrayList<BMI> an den ListAdapter gehängt, würde via item.getIndex() den BMI, via item.getMass() das Gewicht in Kilogramm und via item.getHeight() die Größe zurückbekommen und müsste sich einen Dreck um die Art der Speicherung kümmern.
Abstraktion und Kapselung ‚at it's best‘.
Wenn man dann Bock bekommen hat, richtig schöne Dinge direkt in der Datenbank zu machen, kann man sich damit immer noch beschäftigen. Das Verständnis für die Konzepte hinter den Cursorn und Adaptern dürfte dann auch weit genug fortgeschritten sein, um das alles bis ins Kleinste auszureizen.
Für ‚Ich möchte einen Schwung von Ziffern persistieren.‘ halte ich persönlich
„Beschäftige dich ausführlich mit insgesamt drei unterschiedlichen Konzepten, die du für einen anderen Anwendungsfall eigentlich gar nicht brauchst, und pack es in eine SQLite Datenbank.“
für weit weniger hilfreich als
„Dann kümmere dich mal um das Einbinden einer fremden Library, baue etwas Setup-Code nach und benutze es anschließend wie ein gewöhnliches Objekt."
Gerade in der Welt von Android, in der es für wirklich jeden Pups mindestens drei Libraries gibt, halte ich das Vereinfachen von derartigen Vorgängen für überaus sinnvoll. Gerade am Anfang!
