AsyncTask von Android - Design Muster und Werte Zurückgeben
Bin ich eine Anwendung schreiben, die bestätigt, dass Zugangsdaten auf einem externen webserver - also ich habe das grundsätzliche Problem der Schaffung einer login-Bildschirm, wenn Sie eingereicht werden, senden Sie eine HTTP-Anforderung an einen server in den hintergrund und nicht die Ursache der UI zu hängen - gleichzeitig ein ProgressDialog an den Benutzer.
Mein problem liegt darin, ich möchte schreiben eine generische HTTP-Request-Klasse, die Sie erweitert AsyncTask, also wenn ich anrufen .execute()
ich werde mich dann übergeben Sie String-Parameter enthalten kann, so etwas wie 'post', und wenn doInBackground
nennt dies das "post" - string und dann vorwärts die Parameter auf den jeweiligen Anruf in meiner Klasse. Pseudo-code wäre so etwas wie
public class HTTPOperations extends AsyncTask<String, Void, String>
{
doInBackground(String... string1,additionalParams)
{
if string1.equals "post"
response = httpPost(additionalParams)
return response;
}
httpPost(params)
{
//do http post request
}
}
Dies ist alles, was ich denken konnte, anders als das erstellen einer Klasse für jede HTTP-Post/GET etc Anfrage möchte ich machen und Ausweitung der ASyncTask...
Führt mich zu meinem nächsten problem, wenn der HTTP-POST ist erfolgreich, und es gibt ein Authentifizierungs-token, wie greife ich auf diese token?
Weil neue httpOperations.execute(), nicht den string von doInBackground, aber einen Wert vom Typ
Sorry, wenn dies nicht sinnvoll ist, kann ich nicht verstehen überhaupt. Bitte Fragen Sie für die Ausarbeitung, wenn Sie es brauchen. AsyncTask design patterns und Ideen sind sehr willkommen.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Wenn Sie entwerfen wiederverwendbare Aufgabe für so etwas, die Sie benötigen, zu identifizieren, die eine wiederverwendbare zurück geben. Seine eine design-Entscheidung, auf Ihrem Teil. Fragen Sie sich, "Sind meine HTTP-Operationen ähnlich wie in den beiden die Mechanismen, mit denen Sie aufgerufen werden und in der Ihre Daten verarbeitet?" Wenn ja, können Sie eine einzelne Klasse, beides zu tun. Wenn nicht, müssen Sie wahrscheinlich verschiedene Klassen für unterschiedliche remote-Operationen.
In meinen persönlichen Gebrauch, ich habe ein Objekt, ich lege Schlüssel-Wert-Paare und die gemeinsame Rückgabetyp der HttpEntity. Dies ist der Rückgabetyp für HTTP Get und Post, und das scheint zu funktionieren ok in meinen Szenarien, weil ich das werfen von Ausnahmen in außergewöhnlichen HTTP-Ergebnis-Situationen, wie 404. Ein weiterer netter Aspekt dieser Einrichtung ist, dass der code zum Anhängen von Parametern an eine get-oder post-sind ziemlich ähnlich, also diese Logik ist ziemlich einfach zu bauen.
Ein Beispiel wäre so etwas wie dieses (Pseudo):
Dann in Ihrem code, wo Sie gehen, tun Sie den download:
Dann im Konstruktor von DownloadAsyncTask, speichern Sie die DownloadCallback und, wenn der download abgeschlossen ist oder fehlschlägt, rufen Sie die Methode auf der download-Rückruf, entspricht der Veranstaltung. So...
Werde ich wiederholen, dass ich denke, für das wohl der Sie sich, sollten Sie pass zurück HttpEntities. String kann wie eine gute Idee scheint jetzt aber wirklich zu Problemen führen später, wenn Sie wollen, mehr zu tun, ausgeklügelte Logik hinter Ihrer http-Aufrufe. Natürlich, das ist bis zu Ihnen. Hoffentlich hilft.
onPostExecute(<Z> result)
Methode. AsyncTask automatisch startet onPostExecute wenn die doInBackground abgeschlossen und übergibt den Rückgabewert von doInBackground. Zu "get it out" von der AsyncTask, würde ich empfehlen, eine callback-Schnittstelle. Diese Schnittstelle Typ übergeben werden würde, in deine asynctask-Konstruktor. Dann, in onPostExecute, würde man die Schnittstellen-Methode. Dieses würde Ihnen erlauben, zu bauen bedingten Logik in der Handhabung der Ergebnisse des http-downloads.nehme an, dass die Daten-format mit web api, json, mein design-Muster :
gemeinsame Klassen
1.MyAsyncTask : extends AsyncTask
2.BackgroundBase : Parameter server
3.API_Base : Parameter server
4.MyTaskCompleted : callback-Schnittstelle
Beispiel, nennen wir zwei api in einer Aktivität
annehmen :
API 1.http://www.google.com/action/a
input params : ActionA
output-params : RtnCode, ResultA
API 2.http://www.google.com/action/b
input params : ActionB
output-params : RtnCode, ResultB
Klassen mit Beispiel :
1.MyActivity : erweitert-Aktivität und implementiert MyTaskCompleted
2.MyConfig : utility-Klasse, ich requestCode hier
3.BackgroundActionA, BackgroundActionB : Modell-Klassen für den api-input params
4.API_ActionA, API_ActionB : Modell-Klassen für den api-output-params
Vorteil bei diesem design pattern :
1.ein Vorteil für den multi-api
2.fügen Sie einfach die Modell-Klassen für die neue api, ex: BackgroundActionA und API_ActionA
3.bestimmen Sie die API von verschiedenen requestCode in der callback-Funktion : onMyTaskCompleted