- Motorola Moto G54 5G Power Edition - nem merül le
- Szimpatikusnak tűnik a T Phone új generációja
- Poco X6 Pro - ötös alá
- Telekom T Phone és T Phone Pro - híg a leve
- Egyre közelebb a Poco F6 startja
- Apple iPhone 13 mini - miért nem veszik elegen?
- Samsung Galaxy S21 Ultra - vákuumcsomagolás
- Google Pixel 6/7/8 topik
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Milyen okostelefont vegyek?
Hirdetés
-
Ilyen lehet a Samsung Galaxy Watch7 Ultra
ma Renderképek mutatják meg a Samsung júliusban megjelenő új felső kategóriás okosóráját.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Két újabb előzetesen a MultiVersus
gp A fejlesztők az egyik új pálya mellett Jasonhöz is készítettek egy trailert.
Új hozzászólás Aktív témák
-
thon73
tag
Amíg a válaszokra vártam, tovább nyomoztam:
Úgy tűnik, ha egyszer egy Fragment példányt létrehoztunk, akkor az örökkön-örökké létezni fog a FragmentManager-ben - pontosabban addíg, amíg a program VÉGLEG be nem fejeződik (tehát nem konfig vált. miatt.) Ez meglehetősen furcsa működés, mert akkor mire szolgál a setRetainInstance?
Érdekes, jobban elolvasva a doksi is ezt mondja: a detach hasonló ahhoz, mintha a BackStack-en lenne a fragment, csak ilyenkor a FragmentManager tárolja.
Support package-ot használok API8 minimum mellett API17-tel fordítva.
Meg tudná ezt valaki erősíteni v. cáfolni? Lehet, h. ez egy hiba? Vagy a supporttal van valami gond? -
thon73
tag
Bocs, csak úgy értettem, hogy volt-e már valakinek ehhez hasonló tapasztalata. Neki is láttam egy egyszerűsített tesztkódot írni (az enyém meglehetősen hosszú).
Ez a teszt fragment, egyetlen metódus:public class TestFragment extends Fragment
{
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
{
TextView tv = new TextView(getActivity());
tv.setText("Hello világ!");
return tv;
}
}És a lényeg: az activity:
public class MainActivity extends FragmentActivity
{
@Override
protected void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
FrameLayout fl = new FrameLayout(this );
fl.setId(1234);
setContentView(fl);
}
@Override
public void onResumeFragments()
{
super.onResumeFragments();
FragmentManager fragmentManager = getSupportFragmentManager();
TestFragment test = (TestFragment)fragmentManager.findFragmentByTag("TEST");
if (test == null)
{
test = new TestFragment();
}
FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();
fragmentTransaction.add(1234, test, "TEST");
fragmentTransaction.commit();
}
@Override
public void onPause()
{
super.onPause();
FragmentManager fragmentManager = getSupportFragmentManager();
TestFragment test = (TestFragment)fragmentManager.findFragmentByTag("TEST");
if (test!=null)
{
FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();
// fragmentTransaction.detach(test);
fragmentTransaction.remove(test);
fragmentTransaction.commit();
}
}
}((Igazából ezeken a kódokon kívül az eclipse saját indítókódján semmit sem kell változtatni, mert a View-k dinamikusan jönnek létre. A rengeteg Log-ot kitöröltem, de akár minden metódus figyelhető a LogCat-ben.))
A LÉNYEG:
Sztem. az indítás során az onResumeFragments-ben hozzáadjuk a "TEST" fragmentet,
leállításnál az onPause-ben eldobjuk. (Ha akarjuk, akkor detach is lehet.)A REMOVE UTÁN SZERINTEM A FRAGMENTNEK EL KELLENE PUSZTULNIA A DESTROY FOLYAMÁN!
Ehhez képest újraindítás után hibaüzenet:
java.lang.RuntimeException: Unable to resume activity {.fragmenttest.MainActivity}: java.lang.IllegalStateException: Fragment already added: TestFragment{40525cf0 #0 id=0x4d2 TEST}Vagyis az eldobott Fragmentünk "visszajött".
Ugyanez történik ID és Tag alapú keresésnél is: az eldobott Fragment megjelenik
Ha két (landscape és portrait) layout között váltogatok, akkor még hibaüzenet sem jön, csak a Fragmentek sokasodnak.
((Világos, ha a remove átkerül a legelejére, akkor nem lesz hiba, de a Fragment megmarad))SZERINTEM:
A Fragment-ek NEM objektumként működnek, hanem sokkal jobban hasonlítanak az Activity-ra. Vagyis: létrehozás után (ez történik objektumok módjára), mindvégig megmaradnak, csak ide-oda kapcsolgathatjuk őket.
Az onRetain...-nál annyi különbség lehet, hogy ott érinetetlenül maradnak meg, itt meg a View újra készül.Ez azért gond, mert ha egyszer egy Fragmentet valamelyik View-ba bekapcsoltunk, akkor ragaszkodik a saját View-jához, más View ID esetén hibát dob.
Képzeljünk el egy szituációt: bal oldalon a lista, jobbra az egyes elemek, külön fragmentben. Ha ezt EGY activityvel oldjuk meg, akkor NÉGY fragmentet kell kezelnünk (2 landscape, 2 külön portrait módban) VAGY ha ugyanazt az Id-t adjuk meg a két külön layout-ban lévő fragmentet fogadó View-nak, akkor csak KÉT fragmentet kell kezelnünk.
Tudom, hogy a KÉT ACTIVITY-vel való kezelést preferálják, de 1. ettől nem tudom meg, miért nem tűnnek el a fragmentek. ((2. Az activity-k közötti kommunikáció miatt ez a megoldás most nem az igazi nekem (de ez a teszt szempontjából lényegtelen))Bocs, ha nem teljesen érthető ez, igyekeztem nagyon rövidíteni a kódot. De már csak azért is hajt a kíváncsiság, hogy ez miként műxik.
-
thon73
tag
válasz shinodas #643 üzenetére
Két fontos dologra érdemes figyelni:
1. az onDraw minden invalidate után üres lappal indul. Ha meg akarod tartani az alakzatokat, akkor tárolni kell a koordinátáikat, és mindenannyiszor újrarajzolni őket. A gond az alakzatok "újra megfogásakor" jelentkezik: uis. honnét tudod, hogy egy már letett alakzatot kell mozgatnod, vagy egy újat? Legjobb lenne talán ellenőrizni, hogy az érintés vmelyik alakzat közelében van-e, és akkor azt hozzárendelni. De mindenképpen tárolni kell az adatokat.
2. nem az index számít, hanem az ID. Ez utóbbi ugyanis nem változik egy multitouch érintés során. Csak éppen nem sorban van, hanem végig kell nézni az indexeket és úgy kikeresni.
((És akkor még ott van a "historical" pontok sokasága, amivel nem foglalkoztunk.)) -
thon73
tag
válasz shinodas #649 üzenetére
Ez csak egy bemutató-példa. Mi lenne a cél? Ha két fix alakzatot akarsz mozgatni, akkor azok koordinátáit kell külön tárolni, és egy-egy érintésnél legfeljebb a megfelelő ID-jű érintéshez rendelni.
Egy touchEvent az tényleg egyetlen érintés(sorozatot) ír le. Az ID arra szolgál, hogy EZEN BELÜL egy-egy ujjat kövessen akkor is, ha a többit felemeled (az index uis. csak felsorolja az aktuálisan hozzáérő pontokat, de a sorszám itt változhat.) Az már a Te programod feladata, hogy az alakzatok (és mozgásuk) valamint az érintések közötti logikát megalkossa. A bemutató csak minden mozdulatnál új alakzatokat rajzol az érintési pontokra, nem "gondoskodik" az alakzatokról, ezért is tűnnek el. -
thon73
tag
Nem tudok elszakadni a felszaporodó fragmentek problémájától...
Sehol nem írják ezt a megoldást, pedig nekem minden bajomat megoldotta. Sőt! Portrait-ból Landscape-be való visszafordításnál a másodlagos Fragmentben lévő adatok is megmaradtak! (Lévén ugyanaz a Fragment jelent meg máshol)layout/main.xml
<FrameLayout
android:id="@+id/portrait"
... >
<FrameLayout
android:id="@+id/list_frame"
... />
<FrameLayout
android:id="@+id/edit_frame"
... />
</FrameLayout>layout-land/main.xml
<LinearLayout
android:id="@+id/landscape"
... >
<FrameLayout
android:id="@+id/list_frame"
... />
<FrameLayout
android:id="@+id/edit_frame"
... />
</LinearLayout>Vagyis: ugyanazok az id-k mind landscape,mind portrait módban. Természetesen portrait módban a két frame "átfedi" egymást, tehát a program logikájának kell megoldani, hogy hol az EDIT, hol a LIST fragment legyen felcsatolva a saját (átfedő) Frame-jébe.
Az egész program (ill. ez a része) csak KÉT Fragment Példányt tartalmaz. És egy Activity van (ez volt a cél)Szól ez ellen a megvalósítás ellen vmilyen. érv? Nekem működőképesnek tűnik. Mivel a két layout egyszerre nem valósul meg, az id-k sem akadnak össze. Mindkét frame mindig a "saját" frame-jébe lesz bekapcsolva, mindig a saját tag-jével jelölve. Nincs változás, nincs hibaüzenet. Mivel nem a frame-ek kapcsolnak ki/be, az animációk ugyanúgy látszanak.
Mégsem olvastam ilyen megoldást sehol. Van ezzel vmi baj szerintetek?
Tényleg senkinek nem volt még nehézsége a fragmentek megvalósításával? Tényleg senkinél nem szaporodtak még fel az elforgatások során?[ Szerkesztve ]
-
thon73
tag
válasz shinodas #653 üzenetére
?? Ez azt jelenti, hogy a körök nem mozdíthatóak teljesen szabadon? Vagyis pl. nem keresztezhetik egymást? Mindkettőnek van egy saját területe? Mert akkor jobb lenne egy külön View-t alkotni egy körrel a közepén, amiben a kör - mint egy thumbstick mozgatható. Ha hozzáérsz valahol, akkor arra elmozdul a kör. Ha elengeded, akkor visszaúszik középre. Ez lenne a terv?
-
thon73
tag
válasz shinodas #655 üzenetére
Én lényegesen leegyszerűsíteném ezt a problémát. Készítenék egy speciális View-t, mely egy ilyen joystick-et mutat be. Ebből aztán kettő is elhelyezhető egy layoutban.
A joystick mindig középen áll. Ha megérintem valahol máshol a View-t (vagy a View belül egy kört is kijelölhetek erre), akkor a joystick/kör oda ugrik (és persze ezt az értéket kérdezhetem le). Ha elengedem, akkor visszaugrik középre.
Ez persze nem túl szép, mert a joysticknem ugrál, hanem szépen mozog. Ennek a szimulálására viszont el kell indítani a háttérszálon egy "ütem-adót", ami időnként jelzi a View-nak, hogy mozdítania kell egy kicsit a joystickon. Így úszhat a kör az érintés felé, vagy elengedésnél vissza középre. Az ütemadó nélkül nincs olyan esemény, ami a kör mozgását kiváltaná.
A másik lehetőség, hogy a kör csak akkor mozdul, ha az érintés a középpontjához megfelelően közel következett be. Ilyenkor nem kell ütem-adó, hiszen az "ugrás" megfelelően kicsi. Ez azt is szimulálja, hogy a joystick nem ugrik magától a kezembe, ha nem a tetejét fogom meg. Persze a "visszaúthoz" elengedés után még mindig szükséges az előző módszer.
((Nem dolgoztam még két külön View-val az érintéssel kapcsolatban, de nagy a gyanúm, hogy nem kell törődni, csak az elsődleges érintéssel, mert mindkettő azt kapja meg. Ezt ki kellene próbálnom.))
Ez persze csak az én ötletem, lehet, hogy más tud ennél jobbat is. Külön-külön már minden részét elkészítettem a folyamatnak, csak nem ilyen összefüggésben - ennek alapján szerintem azért el lehet vele játszani, mire összeáll, de megvalósítható. ((Ha nem sürgős, a konkrét megvalósításban is szívesen segítek, a grafika és az időzítés most nálam is pont napirenden van.)) -
thon73
tag
válasz shinodas #657 üzenetére
Pedig az nem nehéz, nekem inkább az időzítéssel gyűlt meg a bajom.
1. KÉT View esetén csak az egy érintéssel kell foglalkozni sztem.
2. KÖZÖS View-ban végig kell menni az összes érintés tömbjén, mint a fenti példában.
Én ellenőrizném a koordináták alapján, melyik ID koordinátája van a joystick körének területén.
A. lehetőség: Továbbra is végigmegyek az indexen, de ennek az ID-nek az alapján mozgatom a kört. Ha az ID eltűnt, akkor ez az érintés befejeződött. Kell keresnem egy újat, v. visszavinni középre a joysticket, és utána keresni.
B. lehetőség: ugyanúgy végigmegyek a tömbön, de nem foglalkozom az ID-vel, hanem ami megfelelően közel van a középpontjához, oda mozdítom a kört. Ha nincs ilyen, mehet vissza középre.Az egész kulcsa az, hogy amíg egy ponton is érinted a képet, az ID megmarad. Ha elengedted a képet, akkor teljesen új érintés kezdődik, új Idkkel. Ezért kell az elején a megf. érintést mindenképp a koord. alapján kiválasztani.
-
thon73
tag
válasz shinodas #661 üzenetére
Itt egy lehetséges megoldás. API10 és AIDE alatt készült, de elvileg bármiben működik. 800x480 pixeles képernyőm van, de persze a méretek a képnek megfelelően változtathatóak. Az egyszerűség kedvéért beágyazott View-t használtam, ill. nem ellenőrzi a View beállításait, ez végleges megoldásnál ildomos!
A kód sok helyen nincs optimalizálva, inkább jól érthetőt akartam írni. ((Pl. én nem is tennék két joysticket egy view-ba, vagy ha igen, akkor két külön objektumként stb.))public class JoystickActivity extends Activity
{
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(new Felulet(this));
}
public class Felulet extends View
{
private float[] origox = {200f, 600f};
private float[] origoy = {180f, 220f};
private float joyx[] = {origox[0], origox[1]};
private float joyy[] = {origoy[0], origoy[1]};
private float joyarea = 150f;
private float joyrad = 40f;
private int joyid[] = {-1, -1};
private Paint area;
private Paint rad;
public Felulet(Context context)
{
this(context, null, 0);
}
public Felulet(Context context, AttributeSet attrs)
{
this(context, attrs, 0);
}
public Felulet(Context context, AttributeSet attrs, int defStyle)
{
super(context, attrs, defStyle);
area=new Paint();
area.setStyle(Paint.Style.STROKE);
area.setColor(Color.RED);
area.setStrokeWidth(5f);
rad=new Paint();
rad.setStyle(Paint.Style.FILL_AND_STROKE);
rad.setColor(Color.GREEN);
rad.setStrokeWidth(5f);
}
@Override
public boolean onTouchEvent(MotionEvent event)
{
switch (event.getActionMasked())
{
case MotionEvent.ACTION_DOWN:
case MotionEvent.ACTION_MOVE:
int pointerCount = event.getPointerCount();
for (int n=0; n<2; n++)
{
if (joyid[n] == -1)
{
for (int cnt = 0; cnt < pointerCount; cnt++)
{
if (distance(joyx[n], joyy[n], event.getX(cnt), event.getY(cnt)) < joyrad)
{
joyid[n] = event.getPointerId(cnt);
break;
}
}
}
else
{
boolean id_flag = false;
for (int cnt = 0; cnt < pointerCount; cnt++)
{
if (joyid[n] == event.getPointerId(cnt))
{
if (distance(origox[n], origoy[n], event.getX(cnt), event.getY(cnt)) < joyarea - joyrad)
{
joyx[n] = event.getX(cnt);
joyy[n] = event.getY(cnt);
this.invalidate();
}
else
{
// aránypárral v. szögfüggvénnyel mozgatható a kerületen
}
id_flag=true;
break;
}
}
if (!id_flag)
reset_joy(n);
}
}
break;
case MotionEvent.ACTION_UP:
reset_joy(0);
reset_joy(1);
break;
}
return true;
}
protected void reset_joy(int n)
{
joyid[n] = -1;
joyx[n] = origox[n];
joyy[n] = origoy[n];
this.invalidate();
}
protected float distance(float x1, float y1, float x2, float y2)
{
float x = x1 - x2;
float y = y1 - y2;
return FloatMath.sqrt(x * x + y * y);
}
@Override
protected void onDraw(Canvas canvas)
{
for (int n=0; n<2; n++)
{
canvas.drawCircle (origox[n], origoy[n], joyarea, area);
canvas.drawCircle (joyx[n], joyy[n], joyrad, rad);
}
}
}
}Az elv: a két index a két külön joysticket jelenti. Origox/y a közepe a két joysticknek, Joyx/y pedig az aktuális helyzete. Joyrad (kiskör) karikán belül lehet csak "megfogni" a joysticket, Joyarea (nagykör) sugaron kívül nem tud mozogni. A távolságot Pithagorasz tétellel számolja, ez nem a legjobb helyen van az osztályon belül.
A JoyId a legfontosabb: ha -1, akkor nincs érintés hozzárendelve (középen van a joystick). Ha egy érintés belelép a kiskörbe, akkor annak id-je lesz a JoyId és azt követi. A nagykör szélén megáll, de az érintéshez továbbra is ragaszkodik. Nem akartam bonyolítani, de az igazi az lenne, ha a köríven menne az ujjad után. (a megjegyzés helyén kezelhető ez)
Ha az Id eltűnik (ezt ellenőrzi a flag), vagyis azt az ujjad felemelted, akkor középre áll. Szintúgy akkor is, ha ACTION_UP lesz, vagyis minden ujj elhagyta a képet. Ilyenkor lehetne ütemadóval visszaúsztatni, de kis méretben az ugrás sem zavaró.
Ilyenre gondoltál? Remélem segít továbblépni, a lényeg úgyis az ID kezelés volt. Ha valami nem tiszta, szívesen segítek. -
thon73
tag
Módosítok: az elv jó, csak megfogni nehéz így. Ha viszont az "else"-t kivesszük (vagy opt. miatt lehet "if (joyid[n]!=-1)"), akkor értelmet kap a DOWN ág is. Uis. már érintésre arrébb tud ugrani.
API17-ben van egy hypot() függvény, ami a distance számítást leegyszerűsíti (nekem API10-ben még nem működik.)
MATEMATIKUSOK!
Mi a legegyszerűbb számítás ahhoz, hogy a kör - az érintéstől függően - a periméteren keringjen? Csak szögfüggvénnyel megoldható?
-
thon73
tag
Kötözködés nélkül, és csak a teljesség kedvéért: single-tap esetén csak A_DOWN generálódik először, és csak mozdítás után A_MOVE. A konkrét példában ez nem látható (tehát igazad van), de ha az else-t kivesszük, akkor megfigyelhető, mert közeli érintésre (és nem mozgásra) is mozdul a joy.
A megelőző példában viszont először én sem tettem be az A_DOWN-t, és érintésre nem jelentek meg a karikák, csak mozgatásra. -
thon73
tag
Fragmentek körében - tud nekem segíteni valaki?
A kód hosszú, de ha kell elküldöm. A kérdések egyszerűbbek.
Ha egy Fragment objektumot létrehozok, az - már bizonyos - örökre megmarad.
Ráadásul, hiába adom ki a remove transactiont (és commit-ot is, persze), utána eltűnik, de az activity újraindulásakor visszalópódzik az elvileg üres View-ba.
A Tag és Id csak akkor él, amikor a Fragment be van rakva a View-ba.- Hogyan lehet ezt a létező Fragment-et (remove, commit után) fellelni? ((Az Activity felleli, mert indításkor visszapakolja! De én csak akkor tudom megtalálni, ha egy globális "változóban" tárolom.))
- vagy hogyan lehetne "destroy"-ra kényszeríteni?
- Tapasztalta-e már valaki a fentieket, ill. okozott-e ez problémát?
- Ti ezt hogyan csináljátok?A hiba akkor bukott ki, amikor egy amúgy jól működő(?) kód, minden fordításkor szaporítani kezdte a menu elemeket. További vizsgálódáskor találtam ezt, amit a doksi nemigen emleget. A neten a fentiekkel csak kérdés formájában találkoztam, választ nem találtam.
Előre is köszönöm, ha valaki fáradozik ezzel! -
thon73
tag
Hm. Úgy látom, a fragmentek kérdéskörével egyedül maradtam. Én végül is változókban (is) tároltam el a visszakapott Fragmenteket. Így sikerült a számukat darabonként egyetlenre korlátozni. Ez az egy példány aztán hol bekerül egy View-be, hol kiveszem onnan. A kód működik, de hogy ez helyes megoldás-e, nem tudom. Gondoltam, azért esetleges későbbi olvasókkal ezt megosztom.
Egy másik problémával kapcsolatban kérnék viszont jó tanácsot: Látszólag jól működik a program, tehát elfordításra is szabványosan leáll és újraindul. De ha az elfordítást kikapcsolt állapotban végzem el, akkor a program - hibaüzenet nélkül - leáll; pontosabban a Log-on jelentkezik egy le nem kezelt exception, amiről fogalmam sincs, hol ered. Az utolsó log-bejegyzés szerint az onPause lefutott. (minden visszahívást log-oltam) A hiba bekapcsoláskor jelenik meg, és ekkor már nem kapok debug üzeneteket.
A programot még tesztelem. A kérdés az, hol találhatok leírtást arról, mi (más) történik a programmal miközben a készülék stand-by-ba (és vissza) kapcsol? Azt gondolom, hogy egy onPause-onResume hívásnak kellene következnie, de erről nem találtam infot. Tud valaki esetleg ilyen jellegű forrást?
[ Szerkesztve ]
-
thon73
tag
válasz SektorFlop #684 üzenetére
Köszi!
-
thon73
tag
A kérdésem második felével kapcsolatban - vagyis, hogy mi történik, amikor a telefon elalszik - is érdekes viselkedést találtam:
Elalváskor dob egy onPause-onResume-onPause hármast, ébredéskor uez. visszafelé: -onResume-onPause-onResume.
A tesztet az Eclipse által létrehozott alapprogrammal (sehol egy fragment!) is megcsináltam, eredmény uez.
Tudja valaki, hogy ennek mi az értelme és magyarázata?(((Természetesen elfogadom, hogy minek kell izgasson ez az egész - ha egyszer működik. Csak a személyes gondom az volt, hogy elalváskor a rendszer a második onPause után valamiért belenyúl egy, az onPause-ban már lezárt adatbázisba. Ezt csak úgy tudtam kikerülni, hogy átpakoltam az egészet az onResume-onPause cikluson kívülre, így működik. Ami érdekes, hogy a hiba kizárólag elalváskor, és a második onPause után jelenik meg.)))
-
thon73
tag
Íme egy újabb feladvány:
Egy ListFragment-et tölt fel egy CursorLoader, éppen úgy, ahogyan az API Guides/Loaders-ben meg van írva.
A program tökéletesen működik, hol a ListFragment, hol a másik ugrik fel. De csak akkor, amikor a másik fragmentben történik vmi. adatbázis változtatás. Ha változtatás nélkül térek vissza (pl. Back), akkor valamiért az EmptyView-t kapom meg.
Pedig az onLoadFinished mindig meghívásra kerül (változó, hogy hol, de mindig az onResume előtt). Sőt, az itt lévő Cursor tartalmazza az elemeket!! Hiába próbálom rávenni az Adaptert, hogy megváltoztak az elemek, marad az EmptyView.
Ha az Activity újraindul, akkor persze (először) működik. Ami fontos, a ListFragment-et tárolom, így mindig ugyanaz a Fragment "jön vissza".
Röviden: A ListFragment saját list View-ja nem érzékeli az Adapterben lévő Cursor-t.
Kérdéseim:
Találkozott már valaki ilyennel, és tudja, hogy mit rontottam el?
Ha nem, akkor tudja-e valaki, hogy miként tudnám kényszeríteni az adaptert v. a listView-t, hogy frissítse magát? Pontosabban HOL tudnám ezt megtenni, mert az egész lekérdezés az onResume UTÁN történik, minden ELŐTTE kiadott invalidate, notify stb. parancs hatástalan.
Vagy tudja-e valaki fejből merre kell keresnem a forráskódban azt a részt, ahol eldől, hogy Empty v. List view lesz a megjelenített?
Ami érdekes: hasonló tapasztalat van fenn a SO-n, de választ nem találtak rá. Ötletem még annyi van, hogy csinálok saját adaptert, aztán csak kiderül, hol a bibi. De ha valaki tudná a választ, az valószínűleg sok-sok órát megtakarítana.
Kódot szívesen küldök, de hosszú. Ha van érdeklődő, akkor megpróbálom a hibáig leegyszerűsíteni. Előre is köszönöm! -
thon73
tag
Tovább tudom finomítani a kérdést:
- A ListFragment MINDIG EmptyView-val indul, csak később készíti el a listát; gondolom, amikor a CursorLoader betölti az elemeket.
- Ez a második lépés kizárólag abban az esetben történik meg, ha a ListFragment először indul, vagy kiadom a ...getContentResolver().notifyChange(uri, null); parancsot. Az uri praktikusan bármi lehet, egyetlen elem, vagy az egész tábla, ez mindegy.
Enélkül elakad az EmptyView-nál.
- Ha debug-ban megyek végig a Fragment részein, akkor NEM jelenik meg az EmptyView, az onLoadFinished már korábban lefut, és az eredmény (Cursor) már fel van töltve.Megoldásként azt tudtam megtenni, hogy a fenti notifyChange parancsot minden - módosítás nélküli - visszatérés esetén kiadom. Ez azonban szerintem nem helyes technika. Másrészt szeretném tudni, hogy mi történik, hol a hiba. Minden ötletet szívesen várok!
-
thon73
tag
válasz pittbaba #711 üzenetére
Én magam nem tudtam, de sztem. itt a megoldás: how-to-access-device-settings-programmatically
naandesh hozzászólása, első sor, ha gond az angol.
Írd meg, légyszi., hogy sikerült-e!Ja, és ne felejtsd az engedélyeket!! Köv. hozzászólásban ott van az is
[ Szerkesztve ]
-
thon73
tag
válasz shinodas #725 üzenetére
Az én tapasztalataim itt vannak: [link]
Gondolom, neked a Miként használjuk Linux alatt... rész lesz a jó. Nem az a gond, hogy nem jó a vendor kód a géphez? De ezt gép és udev file nélkül nem lehet megmondani.Apropó, az én fenti kérdéseimre senkinek nincs ötlete? Ez a Fragmentes dolog egyáltalán nem úgy működik nekem, ahogy a nagykönyvben meg van írva. (Igaz, legalább működik )
-
thon73
tag
válasz shinodas #727 üzenetére
Akár hiszitek, akár nem, tegnap este ugyanebbe a problémába futottam bele. Mivel egy barátom Wayteq xTab-700dc készüléke nem óhajtott drivert telepíteni a munkahelyi WinXP alatt, hazavittem reggel, ahol viszont Ubuntu 12.04 van. Nem találta ez sem...
lsusb parancs alapján a Vendor-kód 2207, ezt beírtam a /etc/udev/rules.d/51-android.rules file-ba, közvetlenül a Samsung alá (ami viszont működik).
SUBSYSTEM=="usb", ATTR{idVendor}=="2207", MODE="0666"
Az adb device parancs azonban csak a Samsungot látta.Az ~/.android/adb_usb.ini file az én gépemen egyáltalán nem létezett (pedig sgsII prímán működik), mindenesetre létrehoztam ezt
0x2207
tartalommal. Kétségtelen, újra kellett indítanom a rendszert, de innentől az adb látja az xTab-ot is.
((Elég vicces a sorszáma:
0123456789ABCDEF
Gondolom, az összes többié is ugyanez lesz ))Csak azt nem tudom, az SO hozzászólásban lévő fejléc alapján nem kellene ezt
android update adb paranccsal készíteni. Mindenesetre az (még) nem ment, a fenti viszont igen.Neked sikerült beüzemelni?
-
thon73
tag
válasz shinodas #733 üzenetére
ITT leírtam, amit csináltam. Menj be a megfelelő (sdk/platform-tools) mappába, ott az adb. És ne felejtsd előle a ./-t! (mint régi win-es, én is mindig lefelejtem, de a Linux NEM keres az aktuális mappában sem!)
Azóta tovább olvastam, a Google is azt írja, hogy így kell csinálni (kézzel). Két dolgot nem értek: miért kell ezt kézzel csinálni, ill. a Samsungnál pl. miért nem kellett csinálni? Annak az ID-jét talán tudta a cég, a kinaiékat meg nem?? -
thon73
tag
Sztem., aki most kezd ismerkedni a java-val, az nem a közeljövőben fog a natív programozással foglalkozni, ne riogassátok őket! ((Mellesleg én ugyan fordítva, vagyis C után tanultam a java-t; de aki már ott tart, annak a natív rész nem sok gondot fog okozni...))
Megkérdezhetem, hogy pontosan melyik ez a könyv? Én szívesen belekukkantanék.
-
thon73
tag
válasz pittbaba #751 üzenetére
A problémával csak felhasználóként találkoztam. [link] Ez a program olyat tud, hogy az előtérbe került hívást (még a hallgató felvétele előtt!!) háttérbe nyomhatod, ahonnét később (amíg a hívás tart) előtérbe lehet venni, és felvenni. Tehát elvileg megoldható.
((Mielőtt valaki megkérdezné, hogy ez mire jó: hosszú úton SVOX-szal szoktam könyvet felolvastatni. De ha hívás érkezik, akkor a felolvasás megszakad, majd a telefon felvétele után beleolvassa a könyvet a telefonba. Na ezt szoktam befejezni egy mozdulattal, mielőtt fogadom a hívást.)) -
thon73
tag
Sziasztok! A következő kódrészlet az android-17 source-ból van:
public abstract class Reader implements Readable, Closeable {
protected Object lock;
...
public int read() throws IOException {
synchronized (lock) {
...
return charArray[0];
}
return -1;
}
}
1. Miért kell egy olvasást szinkronizálni?
2. Ha jól értem a synchronized(lock) csak a "lock" objektum alapján figyeli a hozzáférést.
Mi akadályoz meg más példányokat abban, hogy ugyanahoz a hátterben álló adathoz hozzányúljanak, és különösen mi akadályozza meg a Writer osztályt, hogy időközben ne írjon bele ugyanebbe az adatstruktúrába?Készítettem uis. egy Reader osztályt, de nem értem, hogy miként véd meg a fenti elrendezés a Writer-től. Meg tudná ezt valaki világítani nekem? Köszi!
-
thon73
tag
válasz WonderCSabo #823 üzenetére
Hát pont ez az! Miért szükséges, ha csak a Reader-t (tehát csak olvasást) szinkronizál, és közben a Writer-t (írás, de nem csak másik példány, hanem osztály) nem szinkronizálja? Nem hagyhatnám ki egy az egyben?
-
thon73
tag
Meg tudnátok mondani, hogy miért nem tudom használni a clone()-t egy komolyabb (pl. egy RandomAccessFile) objektumra? A doksi szerint - mint objektum - rendelkezik ezzel a metódussal, az Eclipse mégsem engedi használni. Más osztályokkal is próbáltam, de az Eclipse-ben fel sem merül, hogy elfogadja... Bizonyára apróság, de nem jutok át rajta.
-
thon73
tag
válasz WonderCSabo #852 üzenetére
Köszi! Jogos. Az Inherited Methods from java.lang.Object alatt szerepel, és a doksi egy szóval nem említi, hogy ez az osztály ezt nem valósítaná meg. Miután most a címét is tüzetesen elolvastam, valóban ott áll, hogy protected. Pedig olyan egyszerűnek tűnt...
A választ nagyon köszönöm, nem töröm rajta tovább a fejemet -
thon73
tag
válasz WonderCSabo #852 üzenetére
Egy RandomAccessFile objektumra lenne szükségem, több példányban. Vagyis: ugyanazt a file-t szeretném elérni, de különböző pontokon. A RandomAccessFile konstruktora vagy egy File vagy egy filenév paramétert kér. Eddig úgy oldottam meg, hogy ugyanahhoz a File-hoz több RAF-ot gyártottam le. Most viszont ezek az értékek nem állnak rendelkezésemre (vagyis külön kellene tárolnom őket), ezért örültem meg a clone-nak.
Semmi más módszert nem találtam arra, hogy a RAF objektumot megduplázzam - a belső adataihoz (értelemszerűen) nem férek hozzá. Függetlenül az én konkrét példámtól, ez más objektumokra is igaz.
Nincs véletlenül ötleted arra, milyen uton lehet/illik ezt megoldani? Vagy tároljam el mindig a file nevét, és akkor már tudok olyan osztályt bővíteni, ami implementálhatja a Clonable interface-t. De ez nem tűnik túl szép megoldásnak. Köszi! -
thon73
tag
A következőt szeretném egyszerűsíteni:
raf1 = new RandomAccessFile( "filename", "r");
raf2 = new RandomAccessFile( "filename", "r");
raf3 = new RandomAccessFile( "filename", "r");
raf4 = new RandomAccessFile( "filename", "r");Azért van szükség több "raf"-ra, mert össze szeretném hasonlítani a file két (vagy több) pontján lévő szövegeket egymással.
A fenti módon persze ez megoldható, a gond csak az, hogy a "filename" - hacsak nem tárolom - később már nem hozzáférhető. (Uis. a "raf utazik paraméterként az osztályban) Azt gondoltam, van egy egyszerűbb módszer pl.:raf = new RandomAccessFile( "filename", "r");
...
raf1 = raf.clone();
raf2 = raf.clone();
raf3 = raf.clone();De sajnos nincs, mert ez valóban nem clonable.
A singleton szerintem erre nem megoldás, pont az ellenkezője kellene. (Singletonban mindenki biztosan ugyanazt a raf-ot kapja meg, nekem pedig az kell, hogy biztosan senki ne kaphassa meg ugyanazt a raf-ot)
[ Szerkesztve ]
-
thon73
tag
válasz WonderCSabo #862 üzenetére
A jelenlegi 2x7 mega. Nincsenek benne a formázások, részletek stb.
Sokat gondolkodtam a tároláson, de mivel az adatok nem változnak, ezért tűnt ez a legcélszerűbbnek. Ha adatkezelés is cél lenne, sql-ben csinálnám.
A fenti módszer egyébként így működik, csak az osztály konstruktorába szerettem volna belebűvölni. Ja, és fontos előny, hogy egy keresésnél max. kb. 100 byte beolvasás kell! -
thon73
tag
Sziasztok!
4.1.2-es készülékem lett, és ezen már nem láthatom a LogCat kimenetét "biztonsági" okokból. Mármint magán a készüléken. Van valakinek bevált ötlete arra, hogy ilyenkor mit lehet/érdemes csinálni?
Amennyit erről olvastam, a Google nem is nagyon akarja, hogy a fejlesztők a system log-ot használják. Márpedig nekem eddig nagyon hasznos volt...
-
thon73
tag
Sziasztok!
Tudja valaki:
1. hogyan lehet arról tudomást szerezni, hogy a rendszer (pl. memóriaigény miatt) kilőtte a hátterben álló programot/activity-t?
2. hogyan lehet ezt kikényszeríteni; vagyis, h. a rendszer lője ki a programot, mintha csak további erőforrásra lenne igénye? (A TaskKiller ugyanúgy csinálja?)
Mindkettő kizárólag teszteléshez kellene, tehát root, eclipse-es pc kapcsolat, stb. nem probléma. Köszönöm! -
thon73
tag
válasz WonderCSabo #1024 üzenetére
Köszi, ez jó ötlet. De kicsit félreérthető voltam, én nem az Activity-n BELÜL szeretném megtudni, hogy eltűnt, hanem KÍVÜLRŐL szeretném látni, hogy most már eltűnt/újraindult. Csak olyan ötleteim vannak, hogy megnézem a futó task-ok között stb., de nincs erre valami fejlettebb fejlesztői megoldás?
Pl. az onActivityResult más módon (az on...-ok között más sorrendben) kerül meghívásra a két esetben; és szerettem volna kicsit körüljárni, hogy mi történik. De csak nagyon körülményes megoldásokat találtam. -
thon73
tag
Sziasztok!
Az onPause metódusban van egy fontos mentésem. Próbálgatás közben az derült ki, hogy amikor kikapcsolom (úgy értem teljesen, android logo meg minden) a gépet, akkor NEM fut le az onPause, és következményesen NEM történik meg a mentés.
Az onPausenek nem kellene mindig lefutnia?? Hová lehet még tenni a mentést, hogy biztosan megtörténjen?? (Jó, mondjuk akksi kivétel ellen nincs orvosság, de ez egy "tervezett" leállítás!)
Találkoztatok már ezzel a problémával? Minden segítséget hálásan köszönök!
-
thon73
tag
válasz WonderCSabo #1116 üzenetére
Mindkettőtöknek nagyon köszönöm a segítséget; továbblökött a mélypontról. Ennyire nehéz hibakeresést még soha nem csináltam, ugyanis minden próbálkozás között újra kellett indítani a telót (ami kb. fél perc).
Bocsánat, az onPause irány véletlen volt (de egy fél nap keresés után már nem találtam más okot) ,valóban úgy tűnt, hogy az marad ki: a hiba CSAK leállításkor jelentkezett; az eclipse debugger nem követte ilyenkor az onPause-t (mint utóbb rájöttem: hiszen leállt), a Log-ot meg én bénáztam el. De a hozzászólásotok után végig belogoltam, és akkor kiderült, hogy onPause van, csak ami benne lenne - no az nincs.A tanulság kedvéért a hiba (egyébként utólag pofon egyszerű, de csapdás):
A program egy gigantikus RandomAccessFile-t ír/olvas az sd-n. (Ennyiben a felhasználói adatok azonnal kikerülnek.)
Az onPause részben (többek között) azt kell elmenteni, hogy valaki nem piszkál-e bele a RAF file-ba, amíg távol vagyunk. Ehhez mentem (név mellett) a méretét (File.length()) és az utolsó módosítás időpontját (File.lastModified()). Újraindításkor ezt ellenőrzi.
Ez a módszer prímán működik, amíg ki nem kapcsoljuk a telót.A gondot az jelentette, hogy a RandomAccessFile NEM szinkron írást csinál, sőt a close() után sem írja ki az adatokat! (Ezt bizonyára mindenki tudja, valószínűleg én is, csak nem gondoltam rá.) Véletlenül "rw" módot adtam meg az "rws" helyett.
Az érdekesség, hogy több hetes próbálgatás alatt is a nem-szinkron kiírás MINDIG bekövetkezett az onPause előtt, ha szabványosan léptem ki. Ha a telefont kikapcsoltam akkor SOHA nem következett be az aszinkron írás az onPause előtt (ezt két napja tudom).
((Megjegyzem, sehol nem találtam részletes dokumentációt arról, hogy pontosan mi és milyen sorrendben történik a kikapcsoláskor.))Van még egy probléma, ami komoly fejtörésre adhat okot: RandomAccessFile "rws" írásakor SEM stimmel a lastModified() érték a visszaolvasáskor!! Az esetek 90%-ban pontosan EGY másodperc (1000 ms) különbség van a két külön alkalommal visszaolvasott érték között!! Mivel a lastModified() érték MINDIG három 0-val végződik (vagyis nem ms, hanem másodperc pontos) valószínűleg a kerekítésnél lehet gond; de ezt nem tudom, csak gondolom. Hivatkozást nem találtam SGS2 és Note gépeken próbáltam.
Köszönöm, hogy kipróbáltátok, teljesen fals útról térítettek vissza; így jópár további óra alatt meglett a hiba!
-
thon73
tag
SQLite adatbázist szeretnék exportálni/importálni pl. csv-be. Az adatbázis elég nagy. Mit javasoltok, milyen keretben érdemes ezt megtenni? AsyncTask, Servive, Loader (import oldal), egyéb? Szerintetek mi a legelőnyesebb? Köszi!
-
thon73
tag
Köszi a gyors válaszokat! De a probléma valóban ez: programból szeretném sd-re tenni, lehetőleg emberi fogyasztásra is alkalmas formában. Ez a fele nem is jelent gondot.
Abban nem vagyok biztos, hogy a programszervezés szempontjából melyik a legjobb módszer. Pl. mentés történhet nyugodtan a háttérben (pl. service), de töltésnél ilyenkor mi lesz? Folyamatosan változik a lista, ahogy töltöm? Vagy jobb mindkét esetben leállítani a programot és egy asynctaskkal dolgozni? Szóval kiváncsi lennék a véleményetekre.
Új hozzászólás Aktív témák
- Motorola Moto G54 5G Power Edition - nem merül le
- Ukrajnai háború
- Autós topik
- Szimpatikusnak tűnik a T Phone új generációja
- Poco X6 Pro - ötös alá
- Telekom T Phone és T Phone Pro - híg a leve
- Gaming notebook topik
- Azonnali informatikai kérdések órája
- Kerékpárosok, bringások ide!
- Konzolokról KULTURÁLT módon
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs