Új hozzászólás Aktív témák
-
#1613
WonderCSabo
félisten
negyedes
#1612
WonderCSabo
félisten
válasz
negyedes
#1612
üzenetére
Ez nem segít?
Bozek: a kétirányú láncolt lista nem kezdő szint, de azért vannak nála enyhén szólva bonyolultabb adatszerkezetek is. Ne bánkódj miatta, egy milliárd kód van fent hozzá a neten, ha biztosra akarsz menni akkor nézd ki a Cormen könyvből, aztán portolhatod olyan nyelvre amire akarod.
Én is egy tanulónyelven kezdtem programozni negyedévig, aztán több mint egy év csak C++, és aztán csak a Java. De megértem, ha valaki nem a Pascallal akarja kezdeni. -
#1066
WonderCSabo
félisten
negyedes
#1055
WonderCSabo
félisten
válasz
negyedes
#1055
üzenetére
Attol, hogy egy parameter null, egyaltalan nem kovetkezik az, hogy a meghivott fv nullpointert is fog dobni miatta. Nezd meg a javadocot es/vagy forrast, es meglatod mi tortenik a fv-ben.
Az Adapteres temara: nem rossz a SimpleCursorAdapter, en is arra szavazok. Egyebkent azert nem a kedvencem. Ha nem nagyon sok vagy nagyon nagy objektumaiad vannak, sztem nyugodtan huzd be memoriaba, es egy ArrayAdaptert csinalj. mivel ugyis listat kezelsz.
-
Karma
félisten
válasz
negyedes
#1064
üzenetére
Hát, ennyi kód ismeretében csak általánosan megy...
Amikor az adaptert létrehoztad, egy listát adtál neki data gyanánt. Ezt a listát tedd el tagváltozóba, és használd a remove metódusainak egyikét a törlendő elemmel vagy annak indexével.
Mivel ilyen naivan sikerült az adaptert megcsinálni, először meg kell keresned egy ciklussal a helyes indexet...
Erősen javaslom, hogy nézd meg a SimpleCursorAdaptert a kézzel varázslás helyett. Csak több munkát keversz magadnak...
-
-
#1052
WonderCSabo
félisten
negyedes
#1051
WonderCSabo
félisten
válasz
negyedes
#1051
üzenetére
Hmm, lehet, hogy fáradt vagyok, de nekem ez most korrektnek tűnik. Ellenőrizd le, hogy jó táblából jó kulcsal akarsz-e törölni, és helyes értéket adsz-e át. A fv. visszatérési értékét nézted? Visszaadja, hogy hány sort törölt ki.
Az is megkönnyítené, ha egy SQLite manager progival megnyitod a db-det, és úgy ellenőrized le, hogy biztos az van-e benne, amit Te gondolsz. Ha internal storageban van a db, akkor ehhez persze először ki kell másolni externalra. -
Karma
félisten
válasz
negyedes
#1043
üzenetére
Ó. Megnéztem a doksit, persze hogy nem jó ez se, hiszen a parent az a ListView.
Amit te inbox_listnek neveztél, az a megnyomott elem... Onnan próbáld meg a findViewById-t.De igazából sokkal jobb lenne, ha az egészet kidobnád a francba, s a parent.getItemAtPosition(position) hívással megszereznéd az adatobjektumodat, és onnan vennéd ki a három mezőt. Tudod, MVC meg ilyenek...
-
negyedes
addikt
válasz
negyedes
#1043
üzenetére
Azt hiszem rajottem mi a baja, az id-k a tablamban mind 0-k de nem ertem miert.
private static final String DATABASE_CREATE_IN =
"CREATE TABLE " + SQLITE_TABLE_INBOX + " (" +
KEY_ID + " INTEGER PRIMARY KEY AUTOINCREMENT," +
KEY_SENDER + " TEXT," +
KEY_RECEIVER + " TEXT," +
KEY_SUBJECT + " TEXT," +
KEY_DATE + " TEXT," +
KEY_TEXT + " TEXT," +
KEY_ATTACH + " TEXT," +
KEY_IMPORT + " TEXT" + " )";ez a create stringje.
-
Karma
félisten
válasz
negyedes
#1041
üzenetére
Módosítsd a findViewById hívásokat, most valószínűleg az activity-d metódusát hívod. Ha tippelnem kéne, belső nem-static osztályt írtál az adapternek.
TextView send = (TextView) parent.findViewById(R.id.sender);
TextView date = (TextView) parent.findViewById(R.id.date);
TextView subject = (TextView) parent.findViewById(R.id.subject); -
Karma
félisten
válasz
negyedes
#1036
üzenetére
A DB-ben az oszlopodat gondolom Sendernek hívják, a KEY_SENDER csak a tagváltozó/konstans a Java segédosztályodon. Ha tényleg kézzel akarod összerakni a select hívást (amit nem értek miért tennél), a valódi oszlopneveket kell használnod.
Azaz pl.
String selectQuery = "SELECT " + DBConstants.KEY_SENDER + ", " + DBConstants.KEY_RECEIVER + ", " ...;
Cursor cursor = mDb.rawQuery(selectQuery, null); -
Karma
félisten
válasz
negyedes
#1004
üzenetére
Amikor rakod össze a WHERE feltételt, az egyenlőségjel jobb oldalát aposztrófok közé kell tenni. Ez okozza az egészet.
Pl. az idézett querynél: KEY_SENDER + "=" + sender helyett KEY_SENDER + "= '" + sender + "'".
Vagy az egyébként jóval bonyolultabb SQLiteProgram osztályokkal meg tudod oldani, amit hunfatal mond.
-
Karma
félisten
válasz
negyedes
#928
üzenetére
Szerintem adatbázis, mert elég jól definiálható az emailekhez tartozó séma, és eléggé rekord-alapú. Bár az se baj ha átgondolod pár soron, akarod-e újra feltalálni a kereket...
Széljegyzet és más téma: ha legközelebb adatbázisoznom kell, a persistence elnevezésű libet lehet felpróbálom. Valaki járt már el hasonlóan? Vagy valami mást használt ORM-hez?
-
válasz
negyedes
#923
üzenetére
Miért kellene egy statikus tagot statikus fv-en keresztül elérni?
Egy statikus tagot bárhonnan el lehet érni (ha publikus a tag), csak pédányt nem lehet statikusból elérni, csak akkor, ha van rá "hivatkozásod"... Lehet, hogy kicsit fel kellene frissítened az OOP tudásod (vagy én nem értettem meg, mit szeretnél csinálni). -
válasz
negyedes
#917
üzenetére
MIért kell neked statikus metódus? Miért kellene annak egy példányosított metódusra hivatkoznia? Mi értelme van ennek egyáltalán?
Amúgy elméletben ez viszonylag egyszerű - de hát az elmélet és a gyakorlat között csak elméletileg nincs különbség...
YourObject _self;
...
// init _self in a method
static Object someStaticFunction(Object varForInstance)
{
return _self.someInstanceFunction(varForInstance);
}
Object someInstanceFunction(Object varForInstance)
{
//do work
}A legnagyobb probléma az, hogy hogyan adsz értéket a _self változónak...
Inkább vázold fel nagyvonalakban, hogy mit szeretnél ezzel elérni és majd meglátjuk, hogy esetleg hol hibás a megközelítésed, ami miatt nem akar összejönni a dolog.
-
válasz
negyedes
#915
üzenetére
Attól még, hogy egy mező statikus, még nem tartja meg az értékét az életcikluson kívül - kicsit hasonlít a webfejlesztésre a dolog: minden oldalbetöltés külön egyed és az egyik egyedben elmentett statikus mező nem "öröklődik át" egy másik meghívásban létrejött egyedbe. Ezért van a Session - egy plusz réteg az oldalak alatt, hogy az egyedi meghívásokból egy nagyobb életciklust alakítson ki, azzal, hogy a logikailag összetartozó (Session ID alapján) lekérésekhez a közös információkat tárolja.
Ezt a célt szolgálja az androidnál a Context is:
It allows access to application-specific resources and classes, as well as up-calls for application-level operations such as launching activities, broadcasting and receiving intents, etc.úMondjuk azt nem értem, hogy miért nem tudod a Context-et átadni a függvénynek, hiszen eleve az Activity is a Context-ből öröklődik... Pont mint az Application vagy a Service...
-
Karma
félisten
válasz
negyedes
#906
üzenetére
Lassíts egy kicsit. Egy iPhone-nyi képernyőn nem akartam regényt írni, ezért utalgattam csak a követendő irányra, de akkor most konkrétabban.
Kezdjük ott, hogy gondold át, hogy az alkalmazásod mit csinál, milyen képernyői vannak (jó közelítéssel ezek az Activityjeid); és ezekből melyik fér hozzá a DB-hez, mit csinál vele és mennyi ideig. Ha ezt a topikba leírod, bár nem kötelező, még hasznos is lehet. Ez azért kell, mert ez alapján tudod eldönteni, hogy ki legyen az adatbázis gazdája. Mint pár héttel ezelőtt említettem, ez különösen fontos - ezért is vár Contextet első paraméterként.
Ideális esetben, mondhatni alapelvként, a DB-hez csak nagyon ritkán fordulj, és sose fuss több kört mint szükséges, mert egyszerűen lassú.
Két primitív stratégiát felvázolok addig is, amíg gondolkodsz rajta.
1) (a kettőből ajánlott) Amelyik Activity adatbázist használ, az kezeli magának. Az onCreate metódusban hozod létre a DatabaseHandlert, contextként pedig this formájában az Activity-t adod meg. OnDestroyban meg bezárod. A kód többi részében pedig feltételezed, hogy a DB objektum nyitva van, és használod békésen.
2) Az alkalmazásod ugyebár több Activityből áll össze, de az Application objektum közös. Az Application osztály is Context, bár korlátozottabb jogokkal rendelkezik (nem nyúlhat a UI-hoz vagy az aktív Activity-hez például). Az adatbázishoz viszont pont elég.
Ezáltal meg tudod oldani azt, hogy induláskor egyszer kinyitod a DB-t (Application onCreate metódusban, a context ismét this), és majd a végén bezárod. Közben meg az Application egy tagváltozójában tárolod a handlert.
Van sok gány megoldás arra, hogy hogyan teszed elérhetővé az Activity-k felé: castolhatod az getApplicationContext() eredményét, csinálhatsz static mezőket, követheted a singleton mintát... Vagy használhatsz IoC jellegű logikát is.A lényeg az, hogy legyen meg a teljes életciklus fejben.
-
Karma
félisten
válasz
negyedes
#899
üzenetére
Már megint, a PatientData ne legyen Context! Semmi köze hozzá.
Az előzményeket most kezdem olvasni...Mein Gott. A staticet ebben a környezetben vagy felejtsd el teljesen, vagy csinálj egy saját Application osztály, aminek az onCreate metódusában inicializálod a PatientData statikus mezőit. Ugyanis ez a leghamarabbi pillanat, amikor application contextet tudsz szerezni, ami az SQLite-nak kell.
(WonderCsabo valamiért ezzel a dependenciával nem számolt.)
-
#900
WonderCSabo
félisten
negyedes
#899
WonderCSabo
félisten
válasz
negyedes
#899
üzenetére
Mármint a Load() fv. meg sincs hívva sehol? Mivel ha jól látom ez egy statikus mezút inicializál, ezért sztem rakd be egy statikus inicializáló blokkba egyelőre. A Load() is legyen static mert csak statikus változókat babrál meg.
Tehát.
public class PatientData extends Context{
static String[] Names;
static String[] kep = { "Image 1", "Image 2" };
static {
Load()
}
public static void Load() {
...
}
}Így a Load() fv akkor hívódik meg amikor a PatientData class betöltődik, jellemzően az első hivatkozáskor rá.
-
negyedes
addikt
válasz
negyedes
#898
üzenetére
itt akad meg:
public class PatientData extends Context{
static String[] Names;
static String[] kep = { "Image 1", "Image 2" };
public void Load() {
DatabaseHandler db = new DatabaseHandler(this);
List<Patient> patient_names = db.getPatientAll();
for(Patient cn: patient_names) {
String temp_name = cn.getName();
for(int i=0;i<=patient_names.size();i++) {
Names[i] = temp_name;
}
}
}nem tudom hogy hogyan hivjam meg ezt a fugvenyt vagy ezt a kodreszt.
-
#897
WonderCSabo
félisten
negyedes
#896
WonderCSabo
félisten
válasz
negyedes
#896
üzenetére
Igen, az lesz a gond. Debugold be és nézd meg miért null a Names változó. Nyilván ott érdemes breakpointot berakni, ahol létre kéne jönnie a Names-nek. Egyébként csak így feltűnt, hogy tutira statikus változóban kéne ezt tárolni? Bár nem tudom pontosan milyen nevek ezek de van egy sanda gyanúm, hogy nem.
Illetve javás (és androids) névkonvenciókat tartsd be.
-
#867
WonderCSabo
félisten
negyedes
#866
WonderCSabo
félisten
válasz
negyedes
#866
üzenetére
Mármint egy java.util.List-ed? Ha az elemei String-ek, akkor úgy, hogy meghívod a toArray() metódusát. Ha elemei nem String-ek, akkor pedig pl.
String[] s = new String[list.size()];
int i = 0;
for (Object o : list)
s[i++] = o.toString();Ekkor nyilván csak a toString() metódusban meghatározott String reprezentációkat kapod meg.
Én is egy tanulónyelven kezdtem programozni negyedévig, aztán több mint egy év csak C++, és aztán csak a Java. De megértem, ha valaki nem a Pascallal akarja kezdeni.
Amit te inbox_listnek neveztél, az a megnyomott elem... 
Új hozzászólás Aktív témák
- ÚJ Lenovo LOQ 17IRX10 - 17.3"FHD 165Hz - i7-13650HX - 24GB - 1TB - RTX 5060 - Win11 - 3 év gari - HU
- Garmin Marq 2 Adventurer Garanciális (2026.04.), ÚJ gyári szíjakkal, Full Set
- SMAILIO HD 5" GPS autós navigáció
- HP ELITE 8000 SFF PC: passzív VGA HDMI, C2D E8400 + 4GB RAM
- DJI Air 3s drón akkumulátor és Fly More Akkumulátor Kit - 2 akku, töltőHUB
- HP EliteBook 840 G7 14" i5 10210u, 16GB RAM, SSD, jó akku, számla, 6 hó gar
- Samsung Galaxy Z Fold 6 12/512GB - Újszerű, Független, Ezüst - 1 év garanciával
- REFURBISHED és ÚJ - DELL Thunderbolt Dock WD22TB4 (210-BDTD)
- Lenovo Thunderbolt 3 kábel (4X90U90617)
- GYÖNYÖRŰ iPhone XR 128GB White-1 ÉV GARANCIA - Kártyafüggetlen, MS4294
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest