Jestem w trakcie pisania aplikacji i doszedłem do momentu, w którym muszę wykonać długą operacją może trwać nawet kilka minut, albo i dłużej, w czasie której będę łączył się z internetem.
Wydaje mi się, że przede wszystkim od razu powinieneś napisać, czy podczas wykonywanie tej długiej operacji użytkownik będzie miał cały czas otwartą Twoją aplikację, czy też aplikacja służy do tego, żeby operację włączyć, a potem operacja będzie się wykonywać nie blokując ekranu telefonu. Bo bez tego rozróżnienia nasze rozważania są dosyć jałowe 🙂.
Otóż, w pierwszym przypadku, jeżeli użytkownik przez cały czas wykonywania aplikacji ma ją mieć widoczną, to wykorzystanie usługi jest niepotrzebne. Masz gwarancję, że dopóki użytkownik patrzy na Twoją aplikację to nie zostanie ona zamknięta (tzn. nie masz takiej gwarancji, ale to się nie zdarza żeby użytkownikowi się zamknęła otwarta aplikacja ;P) - i wtedy czasochłonne obliczenia trzeba wrzucić do osobnego wątku (albo czegokolwiek co nie blokuje wątku UI) Twojego Activity.
Skoro jednak chodzi o drugi przypadek - użytkownik używa Activity tylko do odpalenia Twoich długotrwałych obliczeń. I tutaj powinieneś wykorzystać Service. Dlaczego? Zauważ subtelną różnicę między wątkiem a usługą (z tego jak piszesz, wydaje się, że umyka Ci ona) - wątek odpalony z Activity (czyli w obrębie tego samego procesu) zostanie zabity wraz z nią - a Activity służy przede wszystkim do interakcji z użytkownikiem, więc kiedy tylko użytkownik przestanie go używać, idzie na pierwszy ogień kiedy trzeba zwolnić trochę zasobów w systemie. Usługa zaś stanowi osobny proces, ze swej natury przeznaczony do wykonywania operacji w tle. System zabija usługę dopiero, kiedy musi (a musi wtedy, kiedy użytkownik np. odpala pamięciożerne Activity i zaczyna brakować na nie miejsca w pamięci, i niestety czego byś nie użył w takiej sytuacji zawsze to czego w danej chwili używa user ma dla systemu największy priorytet. Ale to niekoniecznie jest bardzo groźne).
Cytując jeszcze kawałek Application Fundamentals:
[qquote]A service doesn't have a visual user interface, but rather runs in the background for an indefinite period of time. For example, a service might play background music as the user attends to other matters, or it might fetch data over the network or calculate something and provide the result to activities that need it. Each service extends the Service base class.
To chyba nawet Twój przypadek! 😃
Nie ma chyba 100% zabezpieczenie przed usunięciem wątku, czy service przez androida?
Tak jak pisałem wcześniej... jedynym pewnym sposobem było by wyłączenie użytkownika na czas wykonywania długotrwałych obliczeń 😃.
---------- Post dołączono o 12:20 ---------- Poprzedni post napisano o 12:17 ----------
Cytat:
tak nadal tak uważam kilkudziesięcioma minutowe działanie owszem ale operacja sporadyczna to już gruba przesada to jest niepotrzebna rozbudowywanie programu podobnie jak IntentService
W mniejszej ilosci linii zakodujesz IntentService'a niz AsyncTask'a.
Przede wszystkim to kodowanie długotrwałych obliczeń w Activity (nieważne, czy będą w AsyncTask'u, czy w czym innym) to właśnie jest najgłupszy sposób na implementowanie długotrwałych obliczeń, bo nie ważne, czy to jest prostrze, czy trudniejsze - przede wszystkim w takim przypadku to w zasadzie mamy pewność, że system nam te obliczenia zabije zanim się zakończą 😛.