Den viktiga aspekten är inte tabellen eller tabellerna utan själva frågan eftersom det bestämmer kolumnordningen.
Till exempel om frågan var baserad på SELECT * FROM your_table (och kolumnerna i tabellen definierades som id, låtnamn, låtår, låtsökväg) då kolumnen är att markören skulle vara enligt definitionen.
Men om du gjorde SELECT songname, songpath, songid, songyear FROM your_table;
Ordningen skulle vara enligt SELECT uttalande, dvs låtnamn (0), låtsökväg (1), låtid (2), låtår (3).
Det är dock ett av problemen med att använda offset som du är bunden till beställningen enligt SELECT.
Om du nu använde markörens getColumnIndex metod då som returnerar kolumnoffset enligt dess namn.
Så cursor.getString(cursor.getColumnIndex("songpath")); skulle få songpath-kolumnen oavsett dess förskjutning/position i markören (OM MARKÖREN INNEHÅLLER DEN KOLUMNEN).
När du minns din tidigare fråga hade du i princip SELECT songpath FROM your_table , Som sådan finns det bara en enda kolumn i den resulterande markören så du kan bara använda get antingen :-
cursor.getString(0);
eller :-
cursor.getString(cursor.getColumnIndex("songpath"));
Den senare är den rekommenderade metoden (MEN helst ha kolumnnamnen definierade som konstanter)
Saker kan dock bli mer komplicerade, till exempel överväg
SELECT songpath||songname AS myconfusingcolumn FROM yourtable;
Detta skulle returnera en enda kolumn med namnet myconfusingcolumn som består av låtsökvägen sammanlänkad med låtnamnet. Det vill säga AS-nyckelordet följs av ett alias för kolumnen (utan AS skulle kolumnnamnet vara ännu mer förvirrande/svårt eftersom det skulle vara songpath||låtnamn) (det här exemplet är relativt enkelt).
En annan sak att vara försiktig med är att de är tvetydiga kolumner (duplicerade kolumnnamn) till exempel, om du hade två tabeller låt och artist och låt den extra kolumnen artist_id så att du har:-
låten tabell med kolumner id , låtnamn , låtår , låtväg , artist_id
konstnärerna tabell med kolumner id och artist_name
och du använde sedan
SELECT * FROM song JOIN artist ON song.artist_id = artist.id;
- Observera att som id kolumn för artist tabell, om den används i satsen, måste den ha prefixet med respektive tabellnamn, annars skulle ett MBIGUOUT kolumnfel uppstå, dvs. SQL-tolkaren skulle inte veta vilket id kolumn du menar.
Dessutom skulle du få en markör med kolumner :-
id , låtnamn, låtår, låtsökväg, artist_id, id , artist_name
csr.getLong(csr.getColumnIndex("id")); could get confused (I believe it actually gets the last AMBIGUOUS column)
long songid = csr.getLong(0); would get the id column from the song table.
long artistid = csr.getLong(5); would get the id column from the artist table.
long artistid = csr.getLong(4); would also get the artist_id same as (5).
För att sammanfatta/sammanfatta :-
Kolumnerna, ordningen och namnet i en markör är helt beroende av SELECT-frågan. De kommer att ha en offset och ett namn enligt frågan. När du kommer åt markören är de underliggande tabellnamnen inte användbara bara kolumnnamnen eller förskjutningarna.
Det är mer flexibelt att komma åt kolumner efter deras namn snarare än efter deras offste . Det är att använda markörens getColumnIndex metod eftersom den förnekar behovet av att beräkna offset och i synnerhet saknad omberäkning om en fråga skulle ändras.
Att använda CONSTANTS för kolumnnamn kommer sannolikt att resultera i minskade problem som skrivfel.
Ytterligare
Använder Toast.makeText(this, mListSongs+"", Toast.LENGTH_SHORT).show();
Kommer att få det ovanliga resultatet [{}] eftersom mListSongs är hela behållaren för låtarna. Du måste gå igenom varje element och sedan hämta egenskaperna/värdena för varje medlem/variabel från elementet (Sångobjekt).