AsynTask или Thread?

Question

[varstring]

Скажите пожалуйста, что лучше для работы с сетью AsynTask или Thread? Пробую делать клиент работающий по TCP. В javaFX клиенте у меня класс имеет внутренние классы, один устанавливает соединение , а другой читает . Хочу проделать тоже самое в android. Имею класс расширяющий Service, внутри которого два класса, схема описанная выше. Так вот, что лучше AsynTask или родной Thread или вообще это делается по другому. Нужно непрерывное соединение.

Answer 1

[Сергей Горностаев]

Когда не знаешь что выбрать, всегда выбирай абстракцию более высокого уровня. Поэтому AsyncTask.

Comments

[Денис Загаевский]

Нет, асинктаски не предназначены для сети.

[Сергей Горностаев]

Денис Загаевский, да?! Почему? В этом и этом учебнике AsyncTask для этих целей используют.

[Денис Загаевский]

Сергей Горностаев, ну печально это, что они там используются. Потому что без дополнительных усилий асинктаски ставятся в очередь (да, они выполняются параллельно, каждая на своем потоке из тредпула, но SERIAL_EXECUTOR выполняет их по одной). Далее, нельзя без втыкания адовых костылей остановить таску. Ещё минус. Отсюда вытекает невозможность нормального управления ЖЦ. Одна из самых распространённых проблем - утекание контекста активити через ссылку в анонимной асинктаске.
И тд и тп.

[Сергей Горностаев]

Денис Загаевский, однако! И чего, на потоках свой AsyncTask городить? А Handler так же плохо себя ведёт?

[Денис Загаевский]

Сергей Горностаев, Handler это вообще отдельная сущность. ТС я посоветовал HandlerThread или, как ты выразился, абстракцию более высокого уровня - IntentService, потому что у него специфичная задача.
AsyncTask можно использовать(через боль и унижение) для коротких задач - создал, выполнил, выкинул. Для обычных http запросов есть тот же okhttp, который умеет сам рулить асинхронщиной, или, если это REST - Retrofit.
Для обычной асинхронщины в конце 2017 года используют RxJava и всю мощь, которую она даёт.

[Сергей Горностаев]

Денис Загаевский, про RxJava очень согласен.

[varstring]

Я влезу в ваш диалог, мне нужно что бы данные гонялись чисто по TCP, слышал что retrofit предлагает обмен чисто используя http. За бугром советуют библиотеку Kryonet, что скажите по поводу нее, есть ли у вас опыт с ней ?

[Сергей Горностаев]

Денис Загаевский

[Денис Загаевский]

varstring, нет, у меня нет. А если бы даже был - какая вам от этого польза? Так выглядит неплохо, попробовать можно.

Answer 2

[Atlllantis]

Вот тут неплохой ответ/совет.

Answer 3

[Денис Загаевский]

Для такой задачи лучше HandlerThread. Для примера можешь посмотреть реализацию IntentService. Или даже расширить прямо его.

Answer 4

[Сергей]

В отличии от FX тебя ждут неожиданности в виде пересоздания Активити при поворотах экрана (например). А соединение вероятно ты хочешь держать открытым. Поэтому изначально желательно разбить приложении на части.
часть пересоздаваемая при поворотах - это активити
часть независимая (неубиваемая) это всякого рода синглтоны. Для твоего случая что-то что будет предоставлять данные. Назовем его провайдером. Время должно не зависеть от активити.
Далее дабы оформить нотариально разделение отображения данных и выкачку из нет - делаем интерфейс - контракт, договоренность по которому активити будет получать данные, а провайдер предоставлять. Данные уже готовые к отображению в активити . Контракт назовем репозиторием. Реализация репозитория - то что предоставляет готовые данные - repositoryImpl.
На этом этапе можно подправить и FX проект. В идеале получиться все что до репозитория (сеть и прочее) - будет общее для двух проектов, после (UI) разное.
Итого получается слои
net/provider - repository - activity.
далее ввиду сюрпризов (выше сказанных ) активити и нехорошей тенденции разрастания логики в активити ее желательно разделить используя такие шаблоны как MVP или MVVM. Для этого есть готовые библиотеки например Moxy или Android Architecture Components (ViewModel). Они позволяют разделить логику (разгрузить активити) и сохранить данные от уничтожения при пересоздании активити.
Итого получается (например с MVP):
net-provider-data-repositoryImpl
----------------------
repository
----------------------
presenter
View (активити)
презентер при создании запрашивает данные из репозитория и асинхронно получает их. после получения отображает их в UI
Все что выше репозитория живет дольше активити/фрагментов. Поэтому держит соединение столько сколько нужно. Все это можно написать как отдельную часть независимую от android ил FX. Работать оно должно не в главных потоках (UI android или UI-FX). Как это реализовать - неважно. Можно вызывать из презентера AsyncTask. Благо презентер не будет убиваться. Также можно добавить в этот слой кеширование. (что бы запросы лишние не слать)
примерно так)
если логика приложений схожа, то можно к репозиторию добавить классы бизнес логики. тогда эта часть также будет независима от устройств.
написано много и сумбурно, но на деле это просто разбиение на слои.

Comments

[varstring]

Спасибо,интересно.