REDGUY: Ja tam přímo ty thready nevytvářím. To dělá třetí strana formou classy Continuation, což je handler, co mi má volat po dokoneční jejich asynchronní operace. Já tedy přímo v tomhle případě ty thready nevytvářím. Všiml jsem si, že když to zahltím požadavky, dokáže se dostat do stavu, kdy přibývají nové thready cca 50 nových vláken za sekundu, dokonce aniž by přibývaly další požadavky (na další stahování). Zdálo se mi, že to souvisí s nějakým deadlockem na přistup k vnějším proměnným. To se mi, zdá se, podařilo skoro vyřešit, i když mi není přímo jasné, čím přesně mi to podařilo.

situace se má konkrétně nějak takto:



rssFeedController.requestAllItems(new Continuation<List<RSSItem>>() {



@Override

public void withValue(List<RSSItem> arg0, Exception arg1) {

// tady je zpracování dat získaných v arg0

// jejich vynášení ven mimo tuto funkci delalo ty problémy



}


DATEL: Zkoušel jsi breaknout kdy ti to umře? Asi se ti volá saveFragmentViewState až po tom co kurzor zavřeš. Jenže pokud ho neodstraníš z toho adaptéru, tak ten se ještě snaží uložit pozici v listu atd ..

GORG: Na tohle určitě používat ThreadPool a ThreadPoolExecutor s nastaveným jedním threadem, nebo prostě minimum, aby se brzy objevili takovéhle problémy tím, že se ti začne ucpávat ta fronta. Docházející paměť se špatně hledá ..

GORG: Chapu spravne ze delas extra thread pro kazdej request, kterejch potencialne muze bejt moc? Nebylo by lepsi mit par pevnejch worker threadu, ktery by brali praci z nejaky fronty? Pokud je pouzivas ke stahovani dat po siti, tak stejne hadam ze bottleneck je ta sit a hodne threadu soucasne bud nepomuze, nebo dokonce uskodi...

Nakonec jsem totiž zjistil, že rychlost (FPS) občas zadrhávalo (jak jsem tu před časem psal) právě tohle leakování threadů.

Nevím, jestli je to dotaz vhodnější na Javu nebo Android, ale narazil jsem na problém při asynchronních požadavcích, kdy se mi hromadí (leakuje) work pool Thready - replikovatelné zejména, pokud z daného threadu chci získat (přeposlat ven) nějakou hodnotu do hlavního threadu. Jde o stahování souborů z internetu na pozadí. Když se to při testování snažím zahltit požadavky, tak se pak thready začnou hromadit po desítkách za sekundu než dojde nakonec paměť.
Nejsem moc zatím zběhlý ve vícethreadových aplikacích, takže si ani nejsem jistý, jestli záležitosti synchronizace threadů řeším správně.
Jinak stručně mi jde o to stáhnout na pozadí nějaký soubor, aby se tím aplikace nezadrhávala. Nejde mi vůbec o čas, jen aby to nedělalo problémy.

A ještě bych měl dotaz k fragmentům a aktivitám co se týče reakce na události.

Mám situaci, kdy hlavní aktivita obsahuje tlačítko pro přidání záznam a pak fragment se seznamem položek. Obsluha přidání nového záznamu je jasně v oné hlavní aktivitě, kde se zavolá intent a startActivityForResult pro otevření druhé aktivity, která pak obsahuje fragment s formulářem.

Ve fragmentu se seznamem položek se pak dá nad položkou vyvolat kontextové menu, kde je možnost položku smazat nebo upravit. A teď, tento fragment přímo obsluhuje událost kliknutí na menu položku pro smazání, tj. smaže položku a obnoví seznam. Jak bych měl ale správně implementovat vyvolání úpravy položky? Formulár pro přidání je vyvolán z aktivity. Měl bych tedy z fragmentu pouze vyvolat nějakou událost, na kterou bude mít ta aktivity navěšený listener a tedy dialog pro úpravu opět otevře aktivita? Nebo by ten formulář pro úpravu měla vyvolat přímo ta aktivita seznamu?

Hm, tak mi zase vyběhla výjimka s kurzorem, já se na to už fakt vytento :( Tentokrát když jsem dal tlačítko Back nebo submit v aktivitě s fragmentem s formulářem pro přidání položky. Tak nevím, máte někdo zkušenosti s tím novým LoadManagerem? Ten by tu správu kurzorů atd. měl řešit sám, ale co jsem zatím tak koukal, tak z toho moc moudrý nejsem.

DATEL: potom sa ti este moze stat, ze sa cela aktivita zrusi (nedostatok pamati, etc.) a bude treba robit fragment znova. mal som nedavno podobny problem s nyxdroidom.
ale zas, ja som tam robil "prasarny" s tymi fragmentami...

DATEL: pred onStop je vzdycky onPause.

Tak jsem si do toho fragmentu přidal všechny onXxx metody týkající se životního cyklu a zjistil jsem, že když přeruším aplikaci stisknutím Home tlačítka, tak se zavolá onPause, kde se Cursor i databáze zavře, pak onStop. Když vzápětí aplikaci vyvolám z launcheru, tak se volá až onStart a onResume. Tj. vůbec se nezavolá onActivityCreated, kde mám vytvoření modelu a zavolání updateList() metody, která vytváří Cursor, dává ho CursorAdapteru a ten předá FragmentListu.

Takže ve výsledku to opravdu shodilo celou aplikaci, protože žádný Cursor neexistoval. Přesunul jsem tedy to co bylo v onActivityCreated do onStart a zatím to jede bez problému.

Akorát teď nevím, jestli bych neměl přesunout i to co je v onPause (tj. uzavření kurzoru a db) do onStop?

No, to je tak, když se začátečník spoléhá na tutoriály :(

REDGUY: ten kurzor je jediný, který se používá a na jednom místě.
Tu onPause() ve FragmentList jsem tedy naimplementoval takto:

    public void onPause() {
        if (!this.c.isClosed()) {
            this.c.close();
        }
        
        this.model.close();
        
        super.onPause();
    }

Při překlápění obrazovky mi to zatím tu výjimku nevyhodilo, ale bohužel to teď náhodně shazuje aplikaci, ať už při zastavení tlačítkem Home nebo naopak znovu vyvolání. Ale taky ne pokaždé, prostě náhodně. Ta výjimka je:

06-04 18:10:32.493: E/AndroidRuntime(2284): FATAL EXCEPTION: main
06-04 18:10:32.493: E/AndroidRuntime(2284): java.lang.RuntimeException: Unable to pause activity {cz.test/cz.test.activity.MainActivity}: android.database.StaleDataException: Access closed cursor
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.app.ActivityThread.performPauseActivity(ActivityThread.java:3348)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.app.ActivityThread.performPauseActivity(ActivityThread.java:3305)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.app.ActivityThread.handlePauseActivity(ActivityThread.java:3288)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.app.ActivityThread.access$2500(ActivityThread.java:125)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2040)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.os.Handler.dispatchMessage(Handler.java:99)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.os.Looper.loop(Looper.java:123)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.app.ActivityThread.main(ActivityThread.java:4627)
06-04 18:10:32.493: E/AndroidRuntime(2284): at java.lang.reflect.Method.invokeNative(Native Method)
06-04 18:10:32.493: E/AndroidRuntime(2284): at java.lang.reflect.Method.invoke(Method.java:521)
06-04 18:10:32.493: E/AndroidRuntime(2284): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868)
06-04 18:10:32.493: E/AndroidRuntime(2284): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
06-04 18:10:32.493: E/AndroidRuntime(2284): at dalvik.system.NativeStart.main(Native Method)
06-04 18:10:32.493: E/AndroidRuntime(2284): Caused by: android.database.StaleDataException: Access closed cursor
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.database.AbstractWindowedCursor.checkPosition(AbstractWindowedCursor.java:217)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.database.AbstractWindowedCursor.getLong(AbstractWindowedCursor.java:99)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.support.v4.widget.CursorAdapter.getItemId(CursorAdapter.java:226)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.widget.AbsListView.onSaveInstanceState(AbsListView.java:885)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.widget.ListView.onSaveInstanceState(ListView.java:3625)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.view.View.dispatchSaveInstanceState(View.java:6068)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.view.ViewGroup.dispatchFreezeSelfOnly(ViewGroup.java:1197)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.widget.AdapterView.dispatchSaveInstanceState(AdapterView.java:759)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.view.ViewGroup.dispatchSaveInstanceState(ViewGroup.java:1184)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.view.View.saveHierarchyState(View.java:6051)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.support.v4.app.FragmentManagerImpl.saveFragmentViewState(FragmentManager.java:1574)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.support.v4.app.FragmentManagerImpl.saveFragmentBasicState(FragmentManager.java:1594)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.support.v4.app.FragmentManagerImpl.saveAllState(FragmentManager.java:1655)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.support.v4.app.FragmentActivity.onSaveInstanceState(FragmentActivity.java:527)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.app.Activity.performSaveInstanceState(Activity.java:1036)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.app.Instrumentation.callActivityOnSaveInstanceState(Instrumentation.java:1180)
06-04 18:10:32.493: E/AndroidRuntime(2284): at android.app.ActivityThread.performPauseActivity(ActivityThread.java:3330)
06-04 18:10:32.493: E/AndroidRuntime(2284): ... 12 more

DATEL: Kdyz si do toho onPause das nejakou debugovaci hlasku, opravdu se vola pred tim, nez ti ho hodi tu vyjimku? A vis jiste ze se ta vyjimka netyka nejakeho jineho kurzoru nez co zaviras?

Ahoj, mám začátečnický dotaz k SQLite Cursorům, když jsou použité ve vlastním Adapteru v ListFragmentu. Vycházel jsem původně ze seriálu na Zdrojáku, prohledal jsem kupu příspěvků na stackoverflow.com i jinde, ale výsledek se nedostavil.
Problém je, že ať dělám co dělám, tak mi při testování v emulátoru při otáčení obrazovky vyhazuje do logu výjimku, že nemám uzavřený cursor. Aplikace je rozložená zhruba takto:

Třída s modelem, kde je vnitřní třída SQLiteOpenHelper a dále metody pro zpracování, mimo jiné getRecords, která vrací Cursor. Dále mám třídu s ListFragmentem, která je posléze vložena do hlavní activity. V této třídě mám metodu updateList:

public void updateList() {
        Context ctx = getActivity();
        this.c = this.model.getRecords();
        TachoListAdapter adapter = new TachoListAdapter(ctx, this.c, 0);
        setListAdapter(adapter);
        //this.model.close();
}

model.close() zavírá databázi. No a právě když otáčím obrazovku (nebo i v jiných případech, kdy dojde ke "zničení") mi to vyhazuje výjimku do logu (ale aplikaci to neshodí), že není uzavřen Cursor.

Zkoušel jsem dát tedy this.c.close() před model.close(), ale to nepomohlo. Pak jsem to zkusil dát do onPause() fragmentu. To bohužel taky nepomohlo. Taky mi občas vyhodil výjimku, že zavírám Cursor, který je již zavřený, tak jsem to upravil takto:

public void onPause() {
        super.onPause();
        if (!this.c.isClosed()) {
            this.c.close();
        }
        
        //this.model.close();
}

Jenže i přesto mi tu výjimku se zavřeným Cursorem vyhazoval. Zkoušel jsem dát volání super.onPause() u za to volání uzavření cursoru, zkoušel jsem různě přesunovat zavírání modelu, ale nic.

Už tu nad tím laboruju 2 dny, ale nepodařilo se mi to vyřešit :( Můžete mi prosím někdo poradit, jak tedy správně používat databázi a kurzory ve Fragmentech (konkrétně v tom FragmentList). Já měl za to, že uzavření toho kurzoru v onPause() by mělo fungovat, ostatně tohle jsem našel i v mnoha příspěvcích na netu, ale tam to bylo vždycky v Aktivitě.

Díky za pomoc.

Potřebuju aby kdy na jednom view začnu šmrdlat prstem a přejedu na druhý, který je napozicovaný nekde nad ním v layoutu, tak aby si mi i na tom druhém projevovaly TouchEventy .. projevujou se mi ale pořád jen na tom zadním. Jak to donutit ke polupráci?

SPIRAL_FORCE: lubi sa mi ten napad s monitoredactivity :)

udelal sem malou knihovnicku pro interaktivni orezavani obrazku, vice zde: https://github.com/biokys/cropimage
mozna se nekomu bude hodit ;-)

Hledám programátora android, případně iOS aplikací.

Mám v hlavě myšlenku na jednu aplikaci, bohužel o programování nevím absolutně nic, takže bych to potřeboval zrealizovat a případně probrat, jestli to má vůbec cenu.

Pro více info SZ :)
Díky

pocujte, nie je develeoperska konzola, cez ktoru sa publikuju aplikacie volajaka rozmrdana? nastavil som totiz v manifeste ze akcelerometer je required a ono mi to tam hodilo ze 0 supported devices. ked som z manifestu vyhodil tuto vec tak v pohode to tomu priradilo divajsis potom

DEEJAYY: Ahoj, super díky. Byl bych pak moc rád, kdybys mi mohl napsat, v čem jsou České Noviny lepší. Já podle toho zdokonalím, díky.

KAPITAN_JACK: Také děkuji za vyzkoušení a za hodnocení! :)