Ok, értem
"Tigris, tigris, csóvafény éjszakáknak erdején, mily kéz adta teneked szörnyü és szép termeted?" -William Blake-
Ok, értem
"Tigris, tigris, csóvafény éjszakáknak erdején, mily kéz adta teneked szörnyü és szép termeted?" -William Blake-
Üdv!
Azt szeretném valahogy megoldani, hogy egy ListFragment-em View-ja egy saját xml fájlból legyen elkészítve.
Úgy értelmezem, hogy a ListFragment-nek alapból van egy ListView-ja. Na én ezt szeretném felülírni a saját ListView-mmal, pontosabban az egész ListFragment view-ját, mivel az én xml-emben a ListView-n kívül még van pár egyéb elem, amint szintén szeretnék megjeleníteni!
Próbálkoztam felülírni a ListFragment onCreateView metódusát és ott inflatelni az én xml fájlomat, de az alábbi hibaüzenetet kaptam futtatáskor:
java.lang.RuntimeException: Your content must have a ListView whose id attribute is 'android.R.id.list'
Előre is köszi a segítséget!
Rip and cut and mutilate the innocent, his friends, and again and again and on and on.
(#1303) lordjancso válasza lordjancso (#1302) üzenetére
Na még jó, hogy a hibaüzenetben ott van a válasz, csak nem gondoltam, hogy ilyen triviális lesz...
A megoldás annyi volt, hogy az xml-ben lévő ListView-nak fixen az alábbi id-t kell adni:
android:id="@android:id/list"
Rip and cut and mutilate the innocent, his friends, and again and again and on and on.
Viszont lenne még egy valamilyen szinten ehhez kapcsolódó kérdésem.
Azt meg lehet oldani, hogy a ListView-m első eleme egy kép legyen? Pontosabban egy LinearLayout. Valahogy így nézne ki:
<LinearLayout
android:layout_width="match_parent"
android:layout_height="130dp"
android:background="@drawable/fragment_header"
android:gravity="bottom"
android:orientation="vertical" >
</LinearLayout>
A ListView többi elemét az adapterén keresztül töltöm fel (azok ugye normális listaelemek, kattinthatóak, stb).
Rip and cut and mutilate the innocent, his friends, and again and again and on and on.
A ListView addHeaderView metódusa nem jó erre? Az adapter beállítása előtt hívd meg.
“All nothings are not equal.”
"Megoldható-e úgy a levélküldés a saját programomból, hogy a beállított Exchange fiókon keresztül felhasználói interakció nélkül küldöm a levelet?"
Keresgéltem az ügyben, a válasz egyértelműnek tűnik: nem.
“All nothings are not equal.”
Igen, ez a megoldás már közelít, de még így sem tökéletes:
Az adaptert eddig az onCreate-ben állítottam be. Mivel muszáj az adapter beállítás előtt meghívni az addHeaderView-t, így az onCreate-ből ki kellett vennem az adaptert.
Az onCreate után meghívja az onCreateView-t. Itt elkérek egy referenciát a headerbe beállítandó layoutra, majd inflatelem a view-t, amiben a ListView-m van és ezt beállítom visszatérési értéknek.
Ezután az onActivityCreated-ben tudom beállítani az előzőleg elkért header referencia alapján a headert, majd beállítani az adaptert.
Elindítom az alkalmazást és minden szép és jó, egészen addig amíg el nem kezdek navigálni.
Az alkalmazásomban három darab fragment van egymás mellett egy ViewPager-ben.
Az első fragment a szóban forgó ListFragment, a másik kettő egyelőre sima Fragment.
Ha elnavigálok a második fragmentre, majd vissza, akkor még minden oké.
Viszont ha elnavigálok a harmadik fragmentre, majd vissza az elsőre, akkor újra meghívja az onCreateView és onActivityCreated metódusokat és ekkor elszáll hibával.
Plusz ugyan ez van forgatásnál is.
Találtam is erről egy StackOverflow bejegyzést.
Rip and cut and mutilate the innocent, his friends, and again and again and on and on.
(#1308) lordjancso válasza lordjancso (#1307) üzenetére
Egyelőre a legjobbnak tűnő megoldás:
@Override
public void onDestroyView() {
super.onDestroyView();
setListAdapter(null);
}
Rip and cut and mutilate the innocent, his friends, and again and again and on and on.
Valaki jártas benne, hogyan lehet ráoptimalizálni egy android rendszert egy másik telefonra, amire még nem adták ki?
Meg tudná valaki mondani:
Ha kaszkádszerűen indítom ugyanazt (ugyanazokat) az Activity-ket, (automatikusan eltárolva az előző instance-ot a BackStack-ben,) akkor mi lesz az Activity-hez tartozó FragmentManager-rel? Az új Activity példány új FragmentManagert is kap, vagy abból csak egy van az egész rendszerben, és figyelnem kell a benne lévő Frgamentekre? Köszi!
Lenne még egy kérdésem.
Ezt a Pager Sliding TabStrip-et használom az alkalmazásomban.
Az első activity-mben jelenítek meg három fragmentet és aközött lehet lapozni vele.
A main activity-m xml-je így néz ki:
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="@color/app_background"
android:orientation="vertical" >
<hu.lordjancso.myapp.ui.PagerSlidingTabStrip
android:id="@+id/tabs"
android:layout_width="match_parent"
android:layout_height="38dp"
android:alpha="0.5"
android:background="#000000" />
<android.support.v4.view.ViewPager
android:id="@+id/vp_mainmenu"
android:layout_width="match_parent"
android:layout_height="wrap_content" >
</android.support.v4.view.ViewPager>
</LinearLayout>
Jól látszik, hogy a Tabok alatt jelenik meg a ViewPager, amiben lehet görgetni a fragmenteket.
Azt meg tudnám valahogy oldani, hogy nem egymás alatt helyezkedjenek el, hanem a ViewPager legyen fullscreen és a Tabok rálógjanak a ViewPagerre?
Valami olyan elképzelésem lenne, hogy a Tabok kb a kijelző közepén jelennek meg, az "alatta" lévő ViewPagerben lévő fragmentek ListFragmentek, és amikor az éppen aktuális ListFragment elemeit lefelé görgetem (tehát a tartalom ÉS a Tabok is haladnak felfelé), majd a tabok teteje eléri a kijelző tetejét, akkor azok "odaragadjanak", de a ListView elemeit tovább lehessen görgetni lefelé (ha még van benne tartalom persze).
És természetesen a balra-jobbra görgetés is működjön, amivel a ViewPagerben lévő fragmentek között tudok váltogatni.
Valakinek van rá ötlete?
Karma, benned bízom!
Rip and cut and mutilate the innocent, his friends, and again and again and on and on.
Karma! Köszönöm a.választ. Én is nézegettem a neten, de nem találtam megoldást sehol.
"Nem gond ha nem vágod a párologtatók bináris nyelvét..."
Sziasztok! Az alsó gombsor világítása nagyon halvány. Lehet valamit állitani a build.prop-ban? Valaki tudna ebben segíteni?
Teljesen készüléktípus-függő a történet – amit nem írtál –, és ebben a topikban nem is vág témába. Keresd meg a készülékednek megfelelő topikot, és próbáld meg ott.
“All nothings are not equal.”
Köszönöm szépen! A linkelt oldalt sem ismertem, az is igen hasznos .
Ott nem nagyon foglalkoznak vele,mivel elég régi készülékről van szó. A build.propban nem mindegyiknél ugyan azokat kell átállítani? Hiába keresem neten,nem találom sehol.
[ Szerkesztve ]
Egyrészt még mindig nem mondtad, milyen telefonról van szó; másrészt bár tényleg lehet az Androiddal kapcsolatos közös dolgot ott állítani, azért gyártófüggő is a fájl tartalma; harmadrészt a kérdésedhez a build.propnak vajmi kevés köze van, inkább a a LED-ek előtét ellenállását kéne kiforrasztani és kisebbre cserélni...
[ Szerkesztve ]
“All nothings are not equal.”
Ha jól emlékszem akkor 2011-es xperiád van. Build.propban ilyesmit nem lehet állítani, max a használt kernel forrásában.
[ Szerkesztve ]
Xperia Active-om van. A használt kernelen belül hol?
ajaj... szerintem ezt a témát hagyd inkább
"Nem gond ha nem vágod a párologtatók bináris nyelvét..."
miért?
Jé, most hogy kiderült hogy milyen telefonról van szó, egész gyorsan meg lehet találni Google-lel a megoldást. Még csak kernelt se kell forgatni hozzá, csak root jogok kellenek. De ez már tényleg az Active topikba tartozik.
[ Szerkesztve ]
“All nothings are not equal.”
Köszi szépen!!! Ha tudnák angolul,lehet megtaláltam volna,de kösz!
Sziasztok!
Most ismerkedem az Androiddal és egyből van egy kis gondom nem tudom ezt a csomagot feltelepíteni:
adt-bundle-windows-x86_64-20131030
Kicsomagolom van benn 2db könyvtár és egy exe fájl ami az SDK Manager erre rákattintok előugrik egy fekete ablak és onnan tol semmi se történik.
Kerestem megoldást de sehol se írják le hogy ilyen gond lenne vagy én nem találtam meg jól.
A rendszer az WIN 7 64 bit
köszönöm előre is segítséget
Ha már 64-bites Android SDK bundle-t szedtél le, a gépeden fenn van hozzá a 64-bites JDK? Mert ez számít, nem csak a Windowsod típusa.
[ Szerkesztve ]
“All nothings are not equal.”
Igen azt szedtem le legelőször és azt telepítettem fel ez van fent :
jdk-7u45-windows-x64
Én ezt találtam korábban. Nem működött a 64 bites java-val, és nem tudok róla, hogy ez változott volna. Próbáld ki a 32 bites Java-t feltenni!
Igen ez volt a probléma.
Köszönöm szerintem lesz még majd kérdésem
Akkor folytatnám a gondjaimat.
Most ez jött elő ami a képen is van
Java fent van
Menj be a környezeti változók közé, és vegyél fel két értéket:
1) JAVA_HOME, ami a feltelepített JDK mappájára mutat
2) PATH, ami a JDK-n belüli bin mappára. (Ha már van PATH definiálva, akkor pontosvesszővel elválasztva csapd a végére a JDK bint.)
Ezt pl. a Rapid Environment Editorral sitty-sutty meg tudod tenni.
“All nothings are not equal.”
Erre meg ezt adja ki:
Azt hittem egyszerűbb telepíteni
Meg lehet adni valahogy egy alkalmazás készítésekor, hogy amikor telepítjük alapból az SD kártyára települjön?
:D Semmi :D
Manifest fájlban rögtön a manifest szekció alá android:installLocation="preferExternal".
Nem célszerű egyébként. Inkább hagyd autón és add meg a lehetőséget a usernek, hogy áthelyezhesse.
[ Szerkesztve ]
Köszi, minden király!
:D Semmi :D
Az előbb még azt mondtad, hogy 64 bites JDK-t tettél fel, most meg az x86-os Program Files van a képen
“All nothings are not equal.”
Igen mivel 64 bitessel nem indult el az Android SDK és itt pár hozászolással feljebb ajánlották ezt
[ Szerkesztve ]
Igen, én ajánlottam, mivel kísértetiesen azonos problémával szembesültem Win7/64bit alatt. De a 32 bites Java JDK feltelepítésével (64 bites mellett!!) minden pikk-pakk ment. Kétségtelen, ez egy korábbi verzió volt, azóta áttértem Ubuntura.
A Java telepítése után telepítetted a Bundle-t? Vagy a Bundle telepítése után cserélted a Java-t? ((Vagy már sikerült beüzemelni?))
Nézd meg, hogy létezik-e egyáltalán a dll. Bár akkor lehet azt írná, hogy nem találja.
Rendesen feltelepült a JDK?
[ Szerkesztve ]
BROTIP: A bundle-t nem kell telepíteni, csak kitömöríteni.
dmc: Ilyen JNI hibák platformütközéskor szoktak előfordulni leginkább. A biztonság kedvéért vegyük át: 32-bites JDK mellé 32-bites ADT kell, 64-es JDK-hoz meg 64-es ADT. Keverve nem megy.
Egyébként nem szokott általában ez ilyen bonyolult lenni, csak valahol elsiklott valami... Pl. húsz perce raktam az egyik gépemre én is ADT-t, elsőre ment. Az SVN-t több szopás belőni
[ Szerkesztve ]
“All nothings are not equal.”
De mint írtam letöltöttem a 64 bites javat fel is telepítettem majd ezek után az Android SDK Managert próbáltam felrakni aminél felugrott egy fekete ablak és kész onnantól se kép se hang nem volt majd feltettem itt a kérdést és érkezett rá választ majd azt kipróbálva újra elindítva az SDK Managert elindult és fel is települt szépen.
Akkor mit csináljak?
MI a megoldás?
Megoldás szerintem nincs. Karma véleményével messzemenőkig egyetértek, csak éppen a 64 bites Android SDK hibás. Nem működik - legalábbis ezt tapasztaltam - a 32 bites Java nélkül, a netes vélemények alapján egyszerűen nem találja meg. Személy szerint furcsának találom, hogy ezt nem javították (legalábbis addig, ameddig win-en követtem.)
A feleségem laptopján (amit utazáskor használunk néha), hiba nélkül együttműködik a 64 bites Android és a 32 bites Java. Megjegyzem, az is érdekes, hogy az Android Developers oldal mind a mai napig JDK 6!-ot javasol. (Egyébként én is 7-tel használom, gond nélkül, de ez nem jelenti azt, hogy nem is léteznek vele problémák.)
B verzió 32 bites megoldás mindkét oldalon, de akkor még mindig kérdéses a Win downgrade
((Egyébként az android alatt elég sok ilyen félkész/hibás/kerülőutas megoldással fogsz találkozni, ne akadj fenn rajta rögtön az elején...))
"hogy az Android Developers oldal mind a mai napig JDK 6!-ot javasol"
Ennek az az egyszerű oka van, hogy az android java 6-ot használ. Ettől függetlenül simán megy 7-es JDK-val, én is avval használom.
Amúgy 32 bit eclipse + 32bit jdk, 64-es winen is hibátlan.
"Egyébként az android alatt elég sok ilyen félkész/hibás/kerülőutas megoldással fogsz találkozni, ne akadj fenn rajta rögtön az elején..."
A hibák nagyrésze a java kókányolása, pl. windows alatt eleve cseszi megcsinálni a PATH változót, azt is kézzel kell, Linuxon ez pl. automatikus.
Az SDK-ban meg sok félkész dolog nincs.
[ Szerkesztve ]
Ezen nem fogunk vitatkozni...
De nehogy a Google alaptalan vádaskodásért pereljen , meg amúgy is elolvasásra érdemesnek tartom:
Overcoming Android's Problems with JDK 7
Másrészt az SDK hibáiról:
Egy egyszerű (lévén az android beépített adatbáziskezelőt tartalmaz) adatbáziskezelő felületet készítgettem, fragmentekkel, sqlite-tal, egyebekkel - de semmi extrával.
- query hiba, egyetlen aposztrof miatt
- foreign key engedélyezése
- DialogFragment setRetainInstance(true) nem működik együtt
- Fragment-ből DialogFragment hívása - elvileg működik, de elfordításnál (egyetlen 0 miatt) az ablakok fordított sorrendben jelennek meg (és elfedik egymást), ((sajnos a linket a kóddal együtt töröltem))
...ezek csak azok, ahol a bug-report-ot feljegyeztem, de sorolhatnám azokat a helyeket, ahol már automatikusan a megkerülő lehetőséget alkalmaztam.
És ez szerintem azért gond, mert én hobby-programozó vagyok: nem munkaidőben, nem pénzért, nem munkacsoportban írok egyszerű kódokat - részben szükségből, részben szórakozásból. Ha én ennyi hibával találkozom, akkor mennyi lehet a "nagy" programoknál? No, de ez már filozófiai probléma, és nem is ide tartozik.
Ami azonban az Android (és elsősorban a fórumok) javára írandó: egyetlen olyan probléma sem volt, amit némi kutakodással, vagy kérdezéssel nem lehetett volna áthidalni.
Bocs, ha valakit megbántottam
Az android sdk-nak kevés köze van az sqlitehoz, azt nem a google fejleszti.
Félkész != néhol bugos.
Nézd meg mennyi bug van egy sima appban, aztán hasonlítsd össze a méretét egy SDK-val. Az összes fejlesztői környezetben találni bugot, a .netben is van szép számmal.
De sokszor előfordul, hogy egy bugnak titulált helyzet nem bug, hanem másképp kell megoldani, mert nem úgy működik, mint, ahogy a fejlesztő gondolja.
A foreign key pl. ezer éves, olvasd el az utolsó commentet.
[ Szerkesztve ]
Az SQLite nem, de a hozzá való interfész amit a Google ad az SDK-ban mégiscsak az ő saruk .
És elég gyakori az is, hogy van egy bug az Androidban, amit sose javítanak. Most az, hogy lezárták a bugot automatikusan, nem jelenti azt hogy megjavult volna.
“All nothings are not equal.”
De attól, hogy vannak bugok még nem lesz félkész valami, nem mondtam, hogy hibátlan az sdk.
Ennyi erővel semmilyen program/fejlesztőkörnyezet/devkit nincs kész, az összesben lehet találni bugot.