Как организовать общение между клиентом (Android) и сервером (Java)?

Question

[Andrey Kovalchuk]

Доброго времени суток.

Есть задача: сообразить клиент-серверное приложение с серверной частью на PC, написанной на Java, и клиентской частью на Android устройстве.

Клиент посылает запрос на данные, сервер получает запрос и высылает запрашиваемые данные.
Исходя из задачи, требуется исполнение в виде частых опросов.

Как правильнее организовать общение между клиентом и сервером? И литературу, если можно.

Answer 1

[Илья]

Самое простое - написать REST API на сервере, отдавать клиенту данные в JSON'е по HTTP.

Быстро накидать серверное приложение можно с помощью вот этого, например. Запрашивать что-либо по HTTP в Android-приложении можно с помощью Volley.

Comments

[Alexx_Sh]

Пожалуй это единственный адекватный ответ, который объясняет все что необходимо сделать для того, чтобы выстроить клиент серверную архитектуру в двух предложениях. За два дня поисков о том, что к чему постоянно встречались неполные ответы и из-за этого я путался еще больше. Спасибо, автор, доходчиво :)

[Andrey Kovalchuk]

Alexx_Sh: Как показала практика, это действительно правильный подход. Только на стороне клиента (Android) использовался Spring for Android framework.

=)

[Alexx_Sh]

Andrey Kovalchuk: Пожалуй я тоже попробую подобный подход, только мне кажется, что вместо Volley, лучше использовать Retrofit 2

[Андрей Мывреник]

Alexx_Sh Andrey Kovalchuk: Да, Retrofit упрощает работу с RESTful API и избавляет от бойлерплейта, рекомендую использовать его.

Answer 2

[uvelichitel]

Исходя из задачи, требуется исполнение в виде частых опросов.

В таких случаях обычно используют протокол websockets, который дает возможность многократного использования соединения и позволяет сделать server push. Для server push еще google предоставляет сервис https://developers.google.com/cloud-messaging/ с возможностью подписки и бродкаст.
Если хотите писать не на WebView а ближе к железу, то unix sockets никто на android не отменял

import java.net.InetAddress;
import java.net.Socket;

Comments

[Andrey Kovalchuk]

Это не совсем то, насколько я понимаю. Вы предлагаете модель long-pulling? с push уведомлениями от google (push-notification). Верно? А мне бы чистый pulling по образу второго подхода из этой статьи https://habrahabr.ru/company/mailru/blog/185696/

[uvelichitel]

mrkovalchuk Недостатки подхода указаны в статье. Установка нового соединения для каждого запроса дорогая процедура, когда запросы частые, вы должны по крайней мере поддерживать соединение keepalive для повторного использования. Не рассмотренный в статье websockets кроме server push(которым все же обычно пользуются) имеет следующие преимущества 1) умеет проходить через proxy(keepalive не умеет) 2)заголовки гораздо легче чем у http request(заметно снижается траффик).

[Andrey Kovalchuk]

uvelichitel Т.е. без JS-а не обойтись в данном методе? Вместо браузера мы будем использовать приложение с встроенным браузером, верно понимаю?

[uvelichitel]

mrkovalchuk В android java api насколько я знаю websocket нет. Есть библиотеки https://github.com/koush/AndroidAsync например. Если вы не собираетесь использовать приложение с встроенным браузером зачем вам http, пишите на java.net.Socket. Писать побольше, зато скорость и нативный Java object serialization вместо JSON.

[Andrey Kovalchuk]

uvelichitel, т.е. если использовать сокеты, то получим схему типа "подход первый" из той статьи с хабра, что я скидывал? Клиент соединяется с сервером и работает (принимает запросы и отвечает на них) до превышения установленного дилея, я верно понимаю?

[uvelichitel]

mrkovalchuk Да. На мой взгляд самый достойный, хоть и самый хлопотный метод. Ближе к железу, выше производительность, больше возможностей, но больше труда. Если сервер на java, я бы наверное так и делал - изоморфное приложение, нативная сериализация java объектов, remote_procedure_call если понадобится, потоки данных в любую сторону.

[Andrey Kovalchuk]

uvelichitel, спасибо за консультацию.