Daten aus Web. Wie geht ihr vor?

  • Hallo miteinander,


    ich möchte von euch gern in Erfahrung bringen wie ihr eure Anwendungen aufbaut, wenn diese Daten aus dem Internet lädt. Aktuell ist es in vielen Anwendungen bei mir so, dass ich die Daten innerhalb eines AsyncTask herunterlade (Nur Text). Bislang habe ich in meinen Anwendungen nur Exeptions und eine bestehende Verbindung berücksichtigt, aber bisher kein Timeout etc pp.


    Wie läuft das Ganze bei euch so? Ein Typisches Beispiel von mir (downloadFromUrl wird innerhalb des AsyncTasks aufgerufen!):


    Verbesserungsvorschläge? GGf. Intent Services ? Wie am besten Timeouts verarbeiten (Beispiel)?


    Des Weiteren wäre es mal interessant zu Wissen wie ihr vorgeht, wenn ihr "berechnungen oder anderes" im Hintergrund ausführt die NICHT unterbrochen bzw. aufgeschoben werden dürfen durch andere AsycTasks. Sprich es wurden gleichzeitig mehrere AsyncTasks ausgelöst.

  • Bei mir ist es im Allgemeinen so, dass ich mich um Timeouts, fehlerhafte Statuscodes etc.pp. nicht sonderlich kümmere.
    Ich meine, der Task ist asynchron, wen kümmert da ein Timeout? Entweder ich bekomme Daten, oder ich bekomme keine Daten.
    Warum ich keine Daten bekomme, ist mir relativ Lachs.


    Im Großen und Ganzen gefällt mir der Code. :)


    Das Problem mit den 'mehreren Async Tasks' bin ich umgangen, indem ich keine mehreren Async Tasks mehr habe.
    In meinen Fällen musste ich feststellen, dass alle anderen Async Tasks vom Erfolg eines bestimmten Async Task abhingen.


    Da offenbar ein 'first come, first serve' bei den AsyncTasks gilt, wird eben dieser zwingend notwendige Task zuerst gestartet und erst nach dessen Ende die abhängigen Tasks. Ich priorisiere die Tasks also quasi manuell, da sie im Allgemeinen eh seriell abgearbeitet werden.
    (Vgl. http://developer.android.com/r…android/os/AsyncTask.html Abschnitt "Order of Execution")
    Allerdings habe ich auch keine Tasks, deren Berechnungen langwierig sind und unbedingt bevorzugt behandelt werden müssen.
    Die Berechnungen werden ebenfalls in ihren jeweiligen Threads einfach sequentiell abgearbeitet.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Lukas das hat mich bislang auch nicht wirklich interessant, aber wie das nun mal so ist kommt immer was dazwischen ;) Das Problem mit den mehreren tasks kann ich leider nicht so einfach umgehen, da die selbe Methode die die asynctasks erstellt mehrfach innerhalb von 5sek aufgerufen wird (mindestens 5 max. 10 mal). Ohne hab ich das Problem, dass der die benötigten Berechnungen nicht durch bekommt ;)

    Volley hab ich mir bislang gar nicht angesehen. Hab zwar die Session damals verfolgt, das war es dann aber auch. Wie sind deine Erfahrungen bislang? Bereits ausprobiert ob es ggf. weitere Tasks blocken würde?

  • Seit dem es Volley von Google gibt kümmere ich mich gar nicht mehr um diesen Mist.


    Und seit wann ist das?


    Ich hatte mir auch vorgenommen, seitdem es Objective-C gibt mich nicht mehr um diesen Java/C#/C++ Mist kümmern zu müssen.
    Erstens kommt es anders und Zweitens als man denkt. ;)

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Zitat

    Und seit wann ist das?


    Na das wurde ja zur GoogleIO vorgestellt, ich hab mir mal die Screencasts angeschaut und dann bei GIT das Projekt geclont.
    Da sind gleich schöne Beispiele dabei.


    Der Vorteil (also ich sehe das als Vorteil)


    Volley baut eine eigene Requestqueue, das heisst er arbeitet all deine Netzwerksachen ab so wie er Resourcen hat.
    Du kannst dir schöne Response Listener bauen welche, dann deine Datenquellen bestücken bzw. dein GUI Updaten. Das ist wesentlich eleganter als 1000 Asynctasks mit noch mehr try catch konstrukten.


    JSOn und XML Helper sind gleich mit an Bord.


    Ein Vorteil von Volley, wenn man HTTP Requests von Hand fährt, dann gibt es Unterschiede zu Pre-Gingerbred und danach. Bei dem einen klappt die eingebaute HTTP Sache besser bei anderen sollte man besser die Apache Implementation nutzen. Da hier sowieso keiner wirklich durchblickt, kümmert sich Volley um das optimale Zugriffserlebnis.


    Na ja am besten mal selber etwas drüberlesen, es macht auf jeden Fall den eigenen Code schlanker und lesbarer.



    Zitat


    Volley hab ich mir bislang gar nicht angesehen. Hab zwar die Session damals verfolgt, das war es dann aber auch. Wie sind deine Erfahrungen bislang? Bereits ausprobiert ob es ggf. weitere Tasks blocken würde?


    Bislang nur gute Erfahrungen, wie gesagt - Code wird wieder lesbarer.
    blockierende Tasks habe ich nicht bemerkt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!