VP
HttpUrlConnection не умеет в отмену??
java.net.http
А этот вообще блокирующий
А этот вообще блокирующий
Size: a a a
2020 May 27
VP
а что сейчас на сервер-сайде популярно? Апач? rest template?
Ну много чего, за всю индустрию не скажу 🤷♂
Но эти тоже, да
Но эти тоже, да
NY
java.net.http
А этот вообще блокирующий
А этот вообще блокирующий
Кажется, в Android SDK и нет такого пакета((
java.net всмысле есть, но пакета http в нём нет
java.net всмысле есть, но пакета http в нём нет
NY
Не докопировали;)
VP
Кажется, в Android SDK и нет такого пакета((
java.net всмысле есть, но пакета http в нём нет
java.net всмысле есть, но пакета http в нём нет
Ну да, он туда вероятно не скоро приедет, а уж использовать его можно будет ещё позже
NY
Ну да, он туда вероятно не скоро приедет, а уж использовать его можно будет ещё позже
Он в java 8 только появился? Или в какой версии?
QH
Он в java 8 только появился? Или в какой версии?
в 9 в инкубаторе, в 10 зарелизился
VP
В 12-14 перестал уходить в вечный цикл при работе с TLS 1.3 и HTTP 2 😂
NY
А насколько правильным будет в SDK добавить OkHttp? С одной стороны - сейчас он используется везде. Стандарт, можно сказать. С другой стороны - SDK вроде как не должно вообще никаких third-party зависимостей содержать. Но смотрю на HttpUrlConnection и… прям вот не хотя смотрю.
Никогда просто раньше не писал либы и интересно мнение со стороны.
Никогда просто раньше не писал либы и интересно мнение со стороны.
NY
Две основные дилеммы, в общем - kotlin и OkHttp
DP
Ну, общая идея -- знаний много, а работать с ними хоть сколько-нибудь эффективно человечество пока так и не научилось -- вполне себе здравая.
Вот кстати да, в 80х хайпили на базах знаний и экспердных системах, в итоге пшик и ничего в ближайшем окружении ПО не напоминает
U
А насколько правильным будет в SDK добавить OkHttp? С одной стороны - сейчас он используется везде. Стандарт, можно сказать. С другой стороны - SDK вроде как не должно вообще никаких third-party зависимостей содержать. Но смотрю на HttpUrlConnection и… прям вот не хотя смотрю.
Никогда просто раньше не писал либы и интересно мнение со стороны.
Никогда просто раньше не писал либы и интересно мнение со стороны.
Я бы добавил в первой версии гвоздями, а потом прикрутил бы модулями, как в ретрофите с парсерами
NY
Я бы добавил в первой версии гвоздями, а потом прикрутил бы модулями, как в ретрофите с парсерами
Типа позднее добавить возможность подключении других известных либ? Или добавить возможность работать через обычный HttpUrlConnection
U
Типа позднее добавить возможность подключении других известных либ? Или добавить возможность работать через обычный HttpUrlConnection
Добавить возможность использовать любую библиотеку для исполнения запросов
U
Интерфейсы, дженерики и всё такое
U
А дефолтную реализацию с окхттп выложить отдельно
DE
А насколько правильным будет в SDK добавить OkHttp? С одной стороны - сейчас он используется везде. Стандарт, можно сказать. С другой стороны - SDK вроде как не должно вообще никаких third-party зависимостей содержать. Но смотрю на HttpUrlConnection и… прям вот не хотя смотрю.
Никогда просто раньше не писал либы и интересно мнение со стороны.
Никогда просто раньше не писал либы и интересно мнение со стороны.
В идеале сделать возможность сконфигурировать свой http cilent. Но изначально я, скорее всего, делал бы через httpUrlConnection
NY
В идеале сделать возможность сконфигурировать свой http cilent. Но изначально я, скорее всего, делал бы через httpUrlConnection
Есть такое - моя совесть тоже считат этот вариант правильным.
DE
Но тут надо понимать, что за sdk. Если это что-то внутреннее, и вы используете okHttp, то можешь спокойно прибить говздями
NY
Не внутреннее. В этом и дело)