Client server android applications

Использование сокетов в Android

Создано большое количество приложений как для Android, так и для других ОС, которые взаимодействуют друг с другом с помощью установления соединенией по сети. К таким приложениям относятся, например, мессенджеры социальных сетей WhatsApp, Viber. Как правило, для установления соединения между такими приложениями используются сокеты.

Сокет (socket) — это интерфейс, позволяющий связывать между собой программы различных устройств, находящихся в одной сети. Сокеты бывают двух типов: клиентский (Socket) и серверный (ServerSocket). Главное различие между ними связано с тем, что сервер «открывает» определенный порт на устройстве, «слушает» его и обрабатывает поступающие запросы, а клиент должен подключиться к этому серверу, зная его IP-адрес и порт. В Android сокеты для передачи данных используют по умолчанию протокол TCP/IP, важной особенностью которого является гарантированная доставка пакетов с данными от одного устройства до другого.

Особенности использования сокетов

Что важно знать при использовании сокетов в Android ?

• соединения сокетов отключаются при переходе устройства в спящий режим;
• чтобы не «рвать» соединение при наступлении спящего режима в устройстве можно использовать сервис;
• для использования интернет-сети необходимо Android-приложению предоставить нужные права в манифесте.

Для определения прав в манифесте необходимо в файл AndroidManifest.xml добавить следующую строку :

Теперь android-приложения будет иметь доступ к сети.

Далее в статье рассмотрим пример клиент-серверного сокетного соединения с передачей сообщения. Функции клиента будет выполнять android-приложение. Серверное java-приложение выполним в IDE Eclipse с использованием пакета concurrent. В конце страницы можно скачать оба приложения.

Клиентский android-сокет

Интерфейс andriod-приложения представлен на следующем скриншоте. Форма приложения включает поле ввода текстового сообщения и кнопки установления соединения сервером, передачи сообщения и закрытия соединения.

Клиентское приложение создадим из двух классов : класс взаимодействия с серверным сокетом Connection и класс стандартной активности MainActivity.

Класс Connection

Класс взаимодействия с сервером Connection получает при создании (через конструктор) параметры подключения : host и port. Методы Connection вызываются из активности и выполняют следующие функции :

Метод	Описание
openConnection	Метод открытия сокета/соединения. Если сокет открыт, то он сначала закрывается.
closeConnection	Метод закрытия сокета
sendData	Метод отправки сообщения из активности.
finalize	Метод освобождения ресурсов

Листинг Connection

Класс активности MainActivity

В активности MainActivity определены параметры сервера : host, port. Помните, что IP-адрес сервера для Вашего android-примера не может быть localhost (127.0.0.1), иначе Вы будете пытаться связаться с сервером внутри Andriod-системы. Кнопки интерфейса связаны с методами обращения к классу Connection. Кнопки отправки сообщения mBtnSend и закрытия соединения mBtnClose с сервером блокируются при старте приложения. После установления соединения с сервером доступ к кнопкам открывается.

Листинг активности

Методы управления сокетным соединением

Ниже представлены методы обработки событий, связанных с нажатием кнопок интерфейса. Обратите внимание, что подключение к серверу выполняется в отдельном потоке, а открытие доступа к кнопкам в основном потоке, для чего вызывается метод runOnUiThread. Для отправки сообщения серверу также создается отдельный поток.

Серверное приложение

Серверное приложение включает 2 класса : Server и ConnectionWorker. Серверный класс Server будет выполнять обработку взаимодействия с клиентом с использованием ConnectionWorker в отдельном потоке. Конструктор ConnectionWorker в качестве параметра получает объект типа Socket для чтения сообщений клиента из потока сокета.

Листинг ConnectionWorker

ConnectionWorker получает входной поток inputStream из клиентского сокета и читает сообщение. Если сообщение отсутствует, т.е. количество прочитанных байт равно -1, то это значит, что соединение разорвано, то клиентский сокет закрывается. При закрытии клиентского соединения входной поток сокета также закрывается.

Серверный класс

Серверный класс Server создадим с использованием многопоточного пакета util.concurrent. На странице описания сетевого пакета java.net и серверного ServerSocket был приведен пример серверного модуля с использованием обычного потока Thread, при работе с которым необходимо решать задачу его остановки : cтарый метод Thread.stop объявлен Deprecated и предан строжайшей анафеме, а безопасная инструкция Thread.interrupt безопасна, к сожалению, потому, что ровным счетом ничего не делает (отправляет сообщение потоку : «Пожалуйста, остановись»). Услышит ли данный призыв поток остается под вопросом – все зависит от разаработчика.

Чтобы иметь возможность остановить сервер «снаружи» в серверный класс Server включим 2 внутренних реализующих интерфейс Callable класса : CallableDelay и CallableServer. Класс CallableDelay будет функционировать определенное время, по истечении которого завершит свою работу и остановит 2-ой серверный поток взаимодействия с клиентами. В данном примере CallableDelay используется только для демонстрации остановки потока, организуемого пакетом util.concurrent.

Листинг CallableDelay

CallableDelay организует цикл с задержками. После завершения последнего цикла cycle поток завершает цикл, останавливает вторую задачу futureTask[1] и закрывает сокет. В консоль выводится соответствующее сообщение.

Листинг CallableServer

Конструктор CallableServer в качестве параметров получает значение открываемого порта для подключения клиентов. При старте (метод call) создается серверный сокет ServerSocket и поток переходит в режим ожидания соединения с клиентом. Остановить поток можно вызовом метода stopTask, либо завершением «задачи» типа FutureTask с данным потоком.

При подключении клиента метод serverSoket.accept возвращает сокет, который используется для создания объекта ConnectionWorker и его запуска в отдельном потоке. А сервер (поток) переходит к ожиданию следующего подключения.

В случае закрытия сокета (завершение внешней задачи FutureTask с данным потоком) будет вызвано исключение Exception, где выполняется проверка закрытия сокета; при положительном ответе основной цикл прерывается и поток завершает свою работу.

Листинг серверного класса Server

Cерверный класс Server создает два потоковых объекта (callable1, callable2), формирует из них две задачи futureTask и запускает задачи на выполнение методом execute исполнителя executor. После этого контролируется завершение выполнение обоих задач методом isTasksDone. При завершении выполнения обеих задач завершается также и цикл работы executor’а.

Два внутренних описанных выше класса (CallableDelay, CallableServer) не включены в листинг.

Источник

Видео. Пишем полноценное клиент-сервер приложение под Android

Приветствую вас, уважаемый Developer!

Хочу поделиться с вами серией уроков, которые мы пишем на нашем канале. Цель данных уроков поделится своими знаниями в сфере Java/Android Development-а, показать как мы строим процесс разработки, и в итоге написать готовое приложение, которое будет общаться с сервером.

Внимание!
Данными уроками мы лишь показываем, то, как мы видим процесс разработки, и делимся лично своим опытом. Все что мы объясняем, является лишь нашим мнением и решением, которое может не сходится с вашим.

Чтобы сделать курс более понятным, мы решили не брать мегасложное приложение, тем самым сделав процесс более простым.

Немного подумав мы решили писать приложение которое бы напоминало нам о важных событиях, делах на текущий день, неделю, месяц или год.

Да, да, да! Мы знаем что таких приложений горы, но цель не создать мега уникальное и популярное приложение, а показать процесс его разработки.

Процесс приготовлений

Прежде чем приступить, мы продумали, что будем писать, как и даже накидали прототипы и макеты. После чего распланировали первый спринт в Youtrack. Таски иногда пополняются, но в на данный момент первый спринт выглядит так:

Также уже в процессе было создано макет приложения, которое мы планируем написать и весь этот процесс записать на видео:

Источник

Lecture 1. Introduction to the architecture of client-server android applications. Part 1

We present the tutorial on the architecture of client-server android applications based on the materials of the course of Arthur Vasilov, which was held at Google Developers Group 2016 in Kazan.

Introduction to the architecture of android applications

Before proceeding directly to the study of how to build the architecture of client-server Android-applications, it would be good to know why this topic is important at all.

And this question is logical. First, the user is completely indifferent to the architecture of your application. Seriously, how many of you, when using programs and applications, often think about whether they did MVP or MVC? The answer is no one. Secondly, working with architecture requires additional efforts: it needs to be created, it needs to delve into and teach people how to work on it. But in order to create a clearer picture for answering this question, we need to return to the relatively recent past, namely in 2007 and 2008, when the first versions of iOS and Android devices were released, respectively.

We must admit that Google managed to lag behind Apple in terms of entering the mobile market and this led to some consequences, namely to the rush when the first version of Android was released. There is nothing surprising in that Google aspired first of all to finish the basic user functions, and care of convenience of developers was the second priority. Therefore, along with the first version of Android, Google did not provide developers with any standard recommendations for either development, or design and UX. That led to the fact that every developer or every company was forced to write as they wanted and as they could.

Of course, we must admit that in the future Google did a great job of popularizing the Android system among developers. But at the same time the original problems were not completely solved.

What are these problems? In terms of design, it is clear that completely different styles of applications confuse the user of the Android system, and it can be difficult to navigate. But what’s wrong with the lack of standards in the code itself? After all, as it was said just above, the user can not know in any way how good the code of your application is, and this does not affect its use. The problem is that not all developers have a good knowledge of design patterns and are able to develop a good application architecture. If you do not follow clear principles in architecture, you will very soon receive a code that:

• Unable to support. The code will have a lot of complex logic, it will not be located in strictly defined classes, it will be unclear how this or that part of your application works. From this it follows that when you add a new functional, you have to either long and hard to understand the written code, refactor it and do it right, or to do the task somehow, that is, figuratively speaking, through crutches. Due to the fact that not all developers understand the need for refactoring and are able to convince the leadership of this need, and not every manager agrees to delay the release of the new version and incur additional expenses due to refactoring, the second option is much more often chosen. This often leads to horrific consequences. Personally, I have repeatedly seen huge applications consisting of three Activity files. Of course, each of these activities consisted of thousands, and even tens of thousands of lines, which made them absolutely impossible to read. Moreover, every new functional implemented through crutches is the cause of additional bugs and crashes.
• It is impossible to test. This problem flows smoothly from the first. You will not be able to write unit tests if the entire application is one large module. Moreover, due to the peculiarities of writing tests for Android-applications on JVM, with a large number of dependencies from Android classes in the tested classes, you can not write tests. And the absence of tests:
  1. Gives you much less confidence that your code is working correctly.
  2. You will not be able to quickly check that the added changes do not break the work of the rest of your application.

This situation lasted long enough. Applications for Android continued to be written in different styles with completely different approaches to design and architecture. Someone was taking a design from the iOS system, and design patterns from Web development (in particular, attempts to use MVC in Android owe their existence to the Web developers who have switched to Android). And it’s hard to say why there were no attempts to fix this situation, Android is a very young system, and by the time of its release all the design patterns and architectural patterns were already widely known.

In general, everything went on as usual until 2014, when two important events happened at once. The first is well known to everyone — this is the presentation of the Material Design concept on Google I / O. You can treat this concept differently, someone considers it unsuccessful, someone says that in this way Google restricts the freedom of developers in choosing a design. But the fact that the emergence of this concept greatly improved the situation on average, is unquestionable.

It’s clear that the Google I / O conference is being monitored by everyone and that Google has put a lot of effort into popularizing the Material Design philosophy, so that Material Design was doomed to be used by everyone. But another significant event happened with less popularity, as it was just an article. This article is «Architecting Android … The clean way?» By Fernando Cejas. In fact, these are just an adaptation of the principles of Clean Architecture from «Uncle Bob» (Robert Martin) for use in Android. This article gave a huge push (and it is quite possible that this is just a coincidence and the article came out at a time when developers were already ready to look for better solutions) in the development of application architecture.

To put it briefly (and we will take a closer look at the course), a good architecture should allow writing tests for classes containing business logic and should build application modules independent of almost all external elements. And if to speak even easier, your code should be testable and it should be easy to apply and pleasant to read. The quality of the application code can even be measured by the standard unit of measure — the amount of WTF per minute (from Robert Martin’s book “Clean Code”).

Now we can roughly imagine what is required of us when building the application architecture and can go directly to the consideration of all topics!

The main tasks in the development of client-server applications

So what is the complexity of creating client-server Android-applications that would satisfy all the principles that were described earlier? There are 2 major problems, each of which in fact can be broken down into even more problems:

• Implementation of client-server interaction. It would seem, what is the problem here? We all know how to execute requests to the server using various tools, process the result and show it to the user. Yes and no. There are many factors. First, you need to be able to correctly handle errors, which can be very different: from the absence of the Internet and the wrong parameters in the query, to the non-responding server and errors in the response. Secondly, there can be more than one query in your application, and a lot, and it is quite possible that you will have to combine the results of these queries in a complex way: execute them in parallel, use the result of the previous query to perform the next and so on. Thirdly, and this is the most unpleasant — requests can take a considerable time, and the user is often not the most patient and quiet person — he can twist the device (and then you lose the current data in Activity), and maybe completely close the application, and then you You can get desync in the data (when the data on the server is updated, and the application does not know about it and displays incorrect or outdated information). And all this needs to be solved in some way.
• Provide the ability to test the classes that contain the business logic of the application. It also implies a lot of internal problems. First, you need to ensure the modularity of classes. This follows from the very essence and from the very name of Unit-tests. To ensure modularity, you need to separate classes into logical layers for each screen. That is, instead of writing all the code pertaining to one screen in one activity, it is necessary to divide it competently into several classes, each of which will have its own zone of responsibility. Secondly, if we talk about tests using JUnit, then we need to understand that the classes tested in this way should contain the minimum number of dependencies from Android-classes, since Java and its virtual machine know nothing about these classes (in more detail this moment will be described In a lecture about testing). Third, the most complex application logic is almost always associated with working with data from the server. We need to test various possible situations, such as the expected server response, server error, and various responses that lead to different behavior of the application. But when performing the test, we can not «drop» the server at will or force it to give us the data we need. In addition, server requests are executed long and asynchronously, and the tests must work consistently. All these problems can be solved if you substitute the implementation of the server for a certain layer, which will be accessed by the tested classes. All this will also be considered below.

These problems also have to be solved when creating a competent and correct architecture, and it is always not very simple. Moreover, sometimes it is impossible to achieve the desired result, and each method has its own shortcomings and advantages. We will study all these methods throughout the course, and after that you will be able to decide exactly how you want to develop client-server applications.

Part 2 Lectures 1 Course on the architecture of android applications:

Источник