Gravierende Verständnisprobleme Async Tasks

Moin,

ich muss mal wieder nerven.

Also ich verstehe das Konzept der Asynchronen Tasks wie folgt:
- Es gibt Dinge, die auf dem UI Thread durchgeführt werden. Namentlich onPreExecute, onPostExecute und onProgressUpdate.
- Es gibt Dinge, die in einem anderen Thread durchgeführt werden. Namentlich doInBackground.

Das ist zumindest das, was mir die Dokumentation erzählen möchte.

Jetzt stelle ich fest, dass dem eben nicht so ist. onPreExecute, onPostExecute und onProgressUpdate werden auf dem Thread ausgeführt, auf dem die Java-Klasse läuft. Dies muss nicht zwangsläufig der UI Thread sein und ist es in meinem Fall auch überhaupt nicht - irgendwie.

Also Folgendes: ich habe eine Klasse, die im Hintergrund ein paar Daten herunterladen soll.
Der Hintergrunddatenherunterladevorgang wird in einem asynchronen Task dieser Klasse durchgeführt.
Die onPreExecute, onPostExecute und onProgressUpdate haben keinen korrekten Zugriff auf den UI Thread.

Zitat

Caused by: java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()

Nun wollte ich erstmal ein paar Arbeiten vorverlegen. Ich habe mir eine Art Notification Center erstellt (wenn es dafür etwas Fertiges gibt, immer her mit der Info).
Nicht das Ding im OS, welches irgendwelche Informationen ausspuckt. Eher eine Art Beobachter/eigener Listener für alles Mögliche.

Nun stelle ich leicht genervt fest:

NotificationCenter.AddReceiver(new NotificationCallback() {
            @Override
            public void postNotification(Notification notification)
            {
                Log.w(TAG, "Guess I got a new 'New Data Available' notification!");


                AlertDialog.Builder adb = new AlertDialog.Builder(uiContext);
                adb.setTitle("Should I stay or should I download?");
                adb.setPositiveButton("Go for it!", new DialogInterface.OnClickListener() {
                    @Override
                    public void onClick(DialogInterface dialogInterface, int i) {
                        Log.e(TAG, "We will go for it on " + i);
                        List<CMSType> types = new ArrayList<CMSType>();
                        for(String key: theMap.keySet())
                        {
                            types.add(theMap.get(key));
                        }
                        daConnector.loadDataUpdatesForTypes(types);
                    }
                });
                adb.setNegativeButton("Leave me alone.", new DialogInterface.OnClickListener() {
                    @Override
                    public void onClick(DialogInterface dialogInterface, int i) {
                        Log.e(TAG, "Don't do anything for "+i);
                    }
                });


                adb.setMessage("There is new download data available. It should be listed here.");
                adb.create().show();
            }
        }, Connector.NewDataAvailable, null);

Tja, was soll ich sagen...

Zitat

Caused by: java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()

Meine 'anonymous inner class' von NotificationCallback() ist also auch irgendwo, nur nicht auf dem UI Thread.

Weiter unten in der Dokumentation finde ich noch den Hinweis, dass AsyncTask doch bitte nur über den UI Thread aufzurufen sei. Also sämtliche Überlegungen umsonst.

Wie bekomme ich denn jetzt den Download in einem anderen Thread durchgeführt und die Daten wie 'Aktuell heruntergeladen' und 'Gesamt' an den UI Thread überführt, wenn der Download etc.pp. von einer eigenen Klasse aus durchgeführt werden soll?

Hi Uwe,

freut mich zu lesen, dass ich nicht der Einzige mit Verständnisproblemen bin.

In der postExecute() mache ich aktuell:

@Override
// Also executed on the UI Thread, they said.
protected void onPostExecute(Long result)
{
    Log.e(TAG, "Download completed with result "+result);
}

Gezeigter Codeschnippsel ist der Bereich, der mir die erste Exception wirft: ich habe also in meiner anonymen Inner-Class keinen Zugriff mehr auf meinen UI Thread, was das Ganze extrem erschwert.
Der ganze Threading Kram wird erst bei daConnector.loadDataUpdatesForTypes(types); angeschmissen, und zwar in der Connector Klasse.

Das Ganze ist noch Testcode, weshalb es kein ordentliches Exceptionhandling gibt.

// Asynchron!
    public void loadDataUpdatesForTypes(List<CMSType> types)
    {
        if(types.size() > 0)
        {


            List<URL> urlArray = new ArrayList<URL>();


            for(CMSType type: types)
            {
                Map<String, String> typeMap = getAvailableUpdates().get(type.getTypeKey());
                String urlString = typeMap.get("url");
                URL theURL = null;
                try
                {
                    theURL = new URL(urlString);
                }
                catch (MalformedURLException e)
                {
                    Log.e(TAG, "URL "+urlString+" is malformed.");
                }
                if(theURL != null)
                {
                    urlArray.add(theURL);
                }
            }
            new ZipDownloader().execute(urlArray);
        }


    class ZipDownloader extends AsyncTask<List<URL>, Long, Long>
    {
        // Preparations
        @Override
        // Executed on the UI thread, they said.
        protected void onPreExecute()
        {
            // I should initialize the progress bar indicator right here!
        }


        // Doin'
        @Override
        // Guess I should prepare the downloading stuff
        protected Long doInBackground(List<URL>... params)
        {
            long result = 0;


            for(List<URL> urlList: params)
            {
                for(URL downloadURL: urlList)
                {
                    Log.e(TAG, downloadURL.toString());
                }
            }


            return result;
        }


        @Override
        // This seems to give me the results or anything like that on the UI Thread
        // Needs to be invoked via publishProgress(Long... progress);
        protected void onProgressUpdate(Long... progress)
        {


        }


        // Done
        @Override
        // Also executed on the UI Thread, they said.
        protected void onPostExecute(Long result)
        {
            Log.e(TAG, "Download completed with result "+result);
        }
    }

Meine Idee war ein eigener Download-Manager, der einfach unabhängig von wo auch immer aufgerufen ein paar entsprechende Dialoge darstellt.
Die Trennung der Logik (also Download über mehrere Threads) von der Darstellung (Download-Dialog beispielsweise mit Fortschrittsanzeige) und anschließendes Zusammengeleime fällt mir hier arg schwer.

Nur nützt es rein gar nichts, irgendwelchen im Android SDK nicht existenten Lösungen herzutrauern. Es muss sich irgendwie umsetzen lassen. Meine Frage ist nur: wie.

Den UI Handler möchte ich halt ungern immer mitschleppen und alles darauf auslagern. Aber offenbar muss ich das tun.

Ach ja, der interne Download-Manager wäre vielleicht eine Option, wenn man ihm erklären könnte, dass er
entweder) die Download Notifications sein lässt
oder) alle 1 bis 5 Dateien als eine einzige Notification anzeigt

Aber eigentlich finde ich das ungeil.

+hm+
Also ist mein Vorhaben nicht trivial?

Gut, dann gebe ich einfach den Handler des UI Thread mit und gut ist.
Der bekommt dann die Erstellung der Dialoge aufgedrückt.

Wegen der Vermeidung schaue ich mal. Da ich es irgendwie eh nicht schaffe, aus einem Array eine Parameterliste zu basteln, werden es trotz mehrere Downloads offenbar dennoch nicht mehrere postExecutes werden.

Eigenartig, dass dieses Thema so komplex anmutet.

Zitat von UweApps

Ich habs zwar nicht probiert, aber wenn du AsyncTask<Url, Long, Long> definierst, sollte ein execute(urlArray) dir auch die Parameter als Array liefern, so wie du sie auch schon verarbeitest, aber eben nicht Listen, sondern nur Url... als Paramter.

Ahaa.

URL[] urls = new URL[urlArray.size()];
new Downloader().execute(urlArray.toArray(urls));

So läuft es auch ohne seltsame Warnungen.
Ich muss nur mal schauen, ob ich jetzt nicht doch zufällig zu viele OnPostExecutes bekomme...
Nö, bekomme ich nicht. Na, damit kann man doch arbeiten.

Danke!

Zitat von UweApps

Ich würde vielleicht noch die Liste urlArray umbenennen in urlListe - dann liest es sich besser. *klugscheiß*

Ist aber ne ArrayList. Also müsste es höchstens urlArrayList heißen.

Bald nutze ich nur noch Collection. Diese Möglichkeiten der Unterteilung sind ja echt bekloppt.

Wie dem auch sei, es ist eine ArrayList.
Ich kann sie ja prima als solche casten und der Name verrät mir schon, dass ich keine ClassCastException dabei bekommen werde.
(Dinge, die man beim NDK und Objective-C lernt: Ein Objekt ist immer das Objekt, das man erstellt hat. Egal wie man es zu Anfang deklariert und egal wohin man es zu casten versucht.)

Object id = new Date();

Was ist id denn jetzt, ein Object oder ein Date?
Die Runtime lässt mich nur die Object-Methoden auf id ausführen, ich muss also erst einmal casten.
Doch ich kann id auf Date casten, weil es ein Date ist.
Will ich id auf String casten, bekomme ich eine ClassCastException. id ist ja schließlich kein String.

Im NDK ist das übrigens komplett anders.
Da kann ich lustig jLongArray in jString in jDate in jDouble casten. Alle Objekte im ndk sind als 'void *' definiert, wie auch alle Objekte in Objective-C.
Folgendes funktioniert da tatsächlich und wirft keine Exceptions, Fehler oder Warnungen:

jdouble einspunktdrei = env->newDate();
(jLongArray)einspunktdrei;
(jString)einspunktdrei;
jdate today = env->newString("Heute");
(jArrayList)today;

Dennoch ist einspunktdrei ein Datum und today ein String.

Zitat von drumliner

Lucas du hast den Bedankenbutton vergessen

Nachgereicht.

Zitat von drumliner

Hab schon auf die Antwort gewartet

+puh+ Da bin ich beruhigt. Hab schon gedacht, dass ich mich als Typ mit mal gerade 1 Jahr so richtig auf Android hier als Klugscheißer gleich unbeliebt mache. +g+

Zitat von ChampS

durch einen check mit instanceof fiel mir auf das trotz des types list das objekt trotzdem eine instanz von arraylist ist

Ansonsten wird das mit dem Casten auch ziemlich schwierig.