Как сделать клиент серверное приложение android
Создано большое количество приложений как для Android, так и для других ОС, которые взаимодействуют друг с другом с помощью установления соединенией по сети. К таким приложениям относятся, например, мессенджеры социальных сетей WhatsApp, Viber. Как правило, для установления соединения между такими приложениями используются сокеты.
Сокет (socket) — это интерфейс, позволяющий связывать между собой программы различных устройств, находящихся в одной сети. Сокеты бывают двух типов: клиентский (Socket) и серверный (ServerSocket). Главное различие между ними связано с тем, что сервер «открывает» определенный порт на устройстве, «слушает» его и обрабатывает поступающие запросы, а клиент должен подключиться к этому серверу, зная его IP-адрес и порт. В Android сокеты для передачи данных используют по умолчанию протокол TCP/IP, важной особенностью которого является гарантированная доставка пакетов с данными от одного устройства до другого.
Особенности использования сокетов
Что важно знать при использовании сокетов в Android ?
- соединения сокетов отключаются при переходе устройства в спящий режим;
- чтобы не «рвать» соединение при наступлении спящего режима в устройстве можно использовать сервис;
- для использования интернет-сети необходимо Android-приложению предоставить нужные права в манифесте.
Для определения прав в манифесте необходимо в файл AndroidManifest.xml добавить следующую строку :
Теперь android-приложения будет иметь доступ к сети.
Клиентский android-сокет
Клиентское приложение создадим из двух классов : класс взаимодействия с серверным сокетом Connection и класс стандартной активности MainActivity.
Класс Connection
Класс взаимодействия с сервером Connection получает при создании (через конструктор) параметры подключения : host и port. Методы Connection вызываются из активности и выполняют следующие функции :
Листинг Connection
Класс активности MainActivity
Листинг активности
Методы управления сокетным соединением
Серверное приложение
Листинг ConnectionWorker
Серверный класс
Чтобы иметь возможность остановить сервер «снаружи» в серверный класс Server включим 2 внутренних реализующих интерфейс Callable класса : CallableDelay и CallableServer. Класс CallableDelay будет функционировать определенное время, по истечении которого завершит свою работу и остановит 2-ой серверный поток взаимодействия с клиентами. В данном примере CallableDelay используется только для демонстрации остановки потока, организуемого пакетом util.concurrent.
Листинг CallableDelay
Листинг CallableServer
Конструктор CallableServer в качестве параметров получает значение открываемого порта для подключения клиентов. При старте (метод call) создается серверный сокет ServerSocket и поток переходит в режим ожидания соединения с клиентом. Остановить поток можно вызовом метода stopTask, либо завершением «задачи» типа FutureTask с данным потоком.
При подключении клиента метод serverSoket.accept возвращает сокет, который используется для создания объекта ConnectionWorker и его запуска в отдельном потоке. А сервер (поток) переходит к ожиданию следующего подключения.
В случае закрытия сокета (завершение внешней задачи FutureTask с данным потоком) будет вызвано исключение Exception, где выполняется проверка закрытия сокета; при положительном ответе основной цикл прерывается и поток завершает свою работу.
Листинг серверного класса Server
Cерверный класс Server создает два потоковых объекта (callable1, callable2), формирует из них две задачи futureTask и запускает задачи на выполнение методом execute исполнителя executor. После этого контролируется завершение выполнение обоих задач методом isTasksDone. При завершении выполнения обеих задач завершается также и цикл работы executor'а.
Два внутренних описанных выше класса (CallableDelay, CallableServer) не включены в листинг.
Представляем курс по архитектуре клиент-серверных андроид-приложений на основе материалов курса Артура Василова, который проходил на Google Developers Group 2016 в Казани.
Чтобы на практике познакомиться с архитектурой клиент-серверных приложений, записывайтесь на продвинутый курс по разработке приложения «Чат-мессенжер»
Введение в архитектуру android приложений
Прежде чем приступить непосредственно к изучению способов построения архитектуры клиент-серверных Android-приложений, было бы хорошо узнать, почему вообще эта тематика важна.
И этот вопрос логичен. Во-первых, пользователю совсем-совсем безразлична архитектура вашего приложения. Серьезно, кто из вас при использовании программ и приложений часто задумывается о том, сделали его по MVP или MVC? Ответ – никто. Во-вторых, работа с архитектурой требует дополнительных усилий: ее нужно создавать, в нее нужно вникать и учить людей работать по ней. Но чтобы создать более четкую картину для ответа на этот вопрос, нужно вернуться в относительно недалекое прошлое, а именно в 2007 и 2008 года, когда были выпущены соответственно первые версии устройств под iOS и Android.
Нужно признать, что Google успел отстать от Apple в плане выхода на мобильный рынок и это привело к некоторым последствиям, а именно к спешке при выходе первой версии Android. Нет ничего удивительного в том, что Google стремился в первую очередь доделать основные пользовательские функции, а забота об удобстве разработчиков была вторым приоритетом. Поэтому вместе с первой версией Android Google не предоставил разработчикам каких-то стандартных рекомендаций ни по разработке, ни по дизайну и UX. Что привело к тому, что каждый разработчик или каждая компания были вынуждены писать как хотели и как умели.
Конечно, нужно признать, что в дальнейшем Google проделал огромную работу по популяризации системы Android среди разработчиков. Но при этом изначальные проблемы так и не были до конца решены.
Какие же это проблемы? В плане дизайна понятно, что абсолютно разные стили приложений смущают пользователя системы Android, и ему бывает тяжело ориентироваться. Но что не так с отсутствием стандартов в самом коде? Ведь как было сказано чуть выше, пользователь никак не может знать, насколько хорош код вашего приложения, и это не влияет на его использование. Проблема заключается в том, что не все разработчики хорошо владеют паттернами проектирования и умеют разрабатывать хорошую архитектуру приложений. Если же не следовать четким принципам в архитектуре вы очень скоро получите код, который:
- Невозможно поддерживать. В коде будет много сложной логики, она не будет расположена в строго определенных классах, будет непонятно, как работает та или иная часть вашего приложения. Из этого следует, что при добавлении нового функционала вам придется либо долго и усиленно разбираться в написанном коде, рефакторить его и делать все правильно, либо сделать задачу кое-как, то есть, образно говоря, через костыли. В связи с тем, что не все разработчики понимают необходимость рефакторинга и умеют убеждать в этой необходимости руководство, и не каждый руководитель согласится отсрочить выход новой версии и понести дополнительные траты из-за рефакторинга, намного чаще выбирается второй вариант. Это часто приводит к ужасающим последствиям. Лично мне не раз приходилось видеть огромные приложения, состоящие из трех файлов Activity. Разумеется, каждая из этих Activity состояла из тысяч, а то и из десятков тысяч строк, что делало их абсолютно невозможными для чтения. Более того, каждый новый функционал, реализованный через костыли, является причиной дополнительных багов и крашей.
- Невозможно протестировать. Эта проблема плавно вытекает из первой. Вы не сможете писать модульные тесты, если все приложение – это один большой модуль. Более того, в силу особенностей написания тестов для Android-приложений на JVM, при большом количестве зависимостей от классов Android в тестируемых классах, вы не сможете писать тесты. А отсуствие тестов:
- Дает вам гораздо меньше уверенности в том, что ваш код работает правильно.
- Вы не сможете быстро проверить, что добавленные изменения не сломают работу остальных частей вашего приложения.
В общем, все шло своим чередом до 2014 года, когда случилось сразу два важнейших события. Первое хорошо известно всем – это презентация концепции Material Design на Google I/O. Можно по-разному относиться к этой концепции, кто-то считает ее неудачной, кто-то говорит, что таким образом Google ограничивает свободу разработчиков в выборе дизайна. Но то, что появление этой концепции сильно улучшило ситуацию в среднем, – это бесспорно.
Понятно, что за конференцией Google I/O следят все и что Google приложил немало усилий в популяризации философии Material Design, так что Material Design был обречен на использование всеми. А вот другое знаковое событие произошло куда с меньшей популярностью, так как это была всего лишь статья. Это статья “Architecting Android… The clean way?” от Fernando Cejas. По сути эти всего лишь адаптация принципов Clean Architecture от “дядюшки Боба” (Роберта Мартина) для использования в Android. Эта статья дала огромный толчок (а вполне возможно, что это просто совпадение и статья вышла в тот момент, когда разработчики уже были готовы искать лучшие решения) в развитии архитектуры приложений.
Если говорить кратко (а подробнее мы посмотрим дальше по курсу), то хорошая архитектура должна позволять писать тесты для классов, содержащих бизнес-логику и должна строить модули приложения независимыми от почти всех внешних элементов. А если говорить еще проще, то ваш код должен быть тестируемым и его должно быть легко применять и приятно читать. Качество кода приложения можно даже замерить стандартной единицей измерения – количество WTF в минуту (из книги Роберта Мартина “Clean Code”).
Теперь мы можем примерно представить, что от нас требуется при построении архитектуры приложения и можем перейти непосредственно к рассмотрению всех тем!
Основные задачи при разработке клиент-серверных приложений
Так в чем же заключается сложность создания клиент-серверных Android-приложений, которые бы удовлетворяли всем принципам, которые были описаны ранее? Есть 2 крупные проблемы, каждую из которых на самом деле можно разбить еще на большее число проблем:
- Реализация клиент-серверного взаимодействия. Казалось бы, в чем здесь проблема? Мы все умеем выполнять запросы к серверу с использованием различных средств, обрабатывать результат и показывать его пользователю. И да, и нет. Здесь существует масса факторов. Во-первых, нужно уметь корректно обрабатывать ошибки, которые могут быть самыми разными: от отсутствия интернета и неправильных параметров в запросе, до не отвечающего сервера и ошибках в ответе. Во-вторых, в вашем приложении может быть не один запрос, а много, и вполне возможна ситуация, что вам придется комбинировать результаты этих запросов сложным образом: выполнять их параллельно, использовать результат предыдущего запроса для выполнения следующего и так далее. В-третьих, и это самое неприятное – запросы могут занимать значительное время, а пользователь часто не самый терпеливый и тихий человек – он может крутить устройство (и тогда вы потеряете текущие данные в Activity), а может и вовсе закрыть приложение, и тогда вы можете получить рассинхронизацию в данных (когда на сервере данные обновились, а приложение не знает об этом и отображает некорректную или устаревшую информацию). И все это нужно каким-то образом решать.
- Обеспечение возможности тестирования классов, содержащих бизнес-логику приложения. Это также подразумевает под собой немало внутренних проблем. Во-первых, нужно обеспечить модульность классов. Это следует из самой сути и из самого названия Unit-тестов. Чтобы обеспечить модульность, нужно разделять классы по логическим слоям для каждого экрана. То есть вместо того, чтобы писать весь код, относящийся к одному экрану, в одной активити, нужно грамотно разделить его на несколько классов, каждый из которых будет иметь свою зону ответственности. Во-вторых, если говорить о тестах с помощью JUnit, то нужно понимать, что тестируемые таким образом классы должны содержать минимальное количество зависимостей от Android-классов, так как Java и ее виртуальная машина об этих классах не знает ничего (подробнее этот момент будет описан в лекции про тестирование). В-третьих, самая сложная логика приложения почти всегда связана с работой с данными от сервера. Мы должны протестировать различные возможные ситуации, такие как ожидаемый ответ сервера, ошибка сервера и разные ответы, приводящие к разному поведению приложения. Но при выполнении теста мы не можем по своему желанию “уронить” сервер или заставить его отдать нужные нам данные. К тому же, серверные запросы выполняются долго и асинхронно, а тесты должны работать последовательно. Все эти проблемы можно решить, если подменять реализацию сервера на определенном слое, к которому будут обращаться тестируемые классы. Все это также будет рассмотрено далее.
Эти проблемы и приходится решать при создании грамотной и правильной архитектуры, и это всегда не очень просто. Более того, иногда невозможно добиться желаемого результата, и у каждого способа есть как свои недостатки, так и достоинства. Рассмотрением всех этих способов мы и будем заниматься на протяжении курса, и после вы сможете решить, как именно вы хотите разрабатывать клиент-серверные приложения.
Сегодня у нас насыщенная программа (еще бы, столько областей кибербезопасности за раз!): рассмотрим декомпиляцию Android-приложения, перехватим трафик для получения URL-адресов, пересоберем apk без исходного кода, поработаем криптоаналитиками и многое другое:)
1. Реверсим apk
Итак, перед нами то немногое, что удалось извлечь из полуразобранного робота – apk-приложение , которое каким-то образом должно помочь нам получить ключ. Сделаем самое очевидное: запустим apk и посмотрим на его функционал. Более чем минималистичный интерфейс приложения сомнений не оставляет – это кастомный файловый клиент FileDroid, позволяющий скачать файл с удаленного сервера. Окей, выглядит несложно. Подключаем телефон к Интернету, делаем пробную попытку скачивания (сразу key.txt – ну а вдруг?) – безуспешно, файл на сервере отсутствует.
Переходим к следующему по уровню сложности мероприятию – декомпилируем apk c помощью JADX и анализируем исходный код приложения, который, к счастью, совсем не обфусцирован. Наша текущая задача – понять, какие файлы предлагает удаленный сервер для скачивания, и выбрать из них тот самый, с ключом.
Начинаем с класса com.ctf.filedroid.MainActivity, содержащего пока самый интересный для нас метод onClick(), в котором обрабатывается нажатие на кнопку «Download». Внутри этого метода дважды происходит обращение к классу ConnectionHandler: cперва вызывается метод ConnectionHandler.getToken(), а только затем – ConnectionHandler.getEncryptedFile(), в который передается имя файла, запрошенного пользователем.
Ага, то есть сначала нам нужен токен! Разберемся чуть подробнее с процессом его получения.
Метод ConnectionHandler.getToken() принимает на вход две строки, а затем отправляет GET-запрос, передавая эти строки в качестве параметров «crc» и «sign». В ответ сервер присылает данные в JSON-формате, из которых наше приложение извлекает токен доступа и использует его для скачивания файла. Это всё, конечно, хорошо, но что за «crc» и «sign»?
Чтобы понять это, двигаемся дальше в сторону класса Checks, любезно предоставляющего методы badHash() и badSign(). Первый из них подсчитывает контрольную сумму от classes.dex и resources.arsc, конкатенирует эти два значения и оборачивает в Base64 (обратим внимание на флаг 10 = NO_WRAP | URL_SAFE, вдруг пригодится). А что же второй метод? А он делает тоже самое с SHA-256 fingerprint’ом подписи приложения. Эх, похоже, что FileDroid не очень-то жаждет быть пересобранным :(
Окей, допустим, что токен получили. Что дальше? Передаем его на вход метода ConnectionHandler.getEncryptedFile(), который присовокупляет к токену имя запрошенного файла и формирует еще один GET-запрос, на этот раз с параметрами «token» и «file». Сервер в ответ (судя по названию метода) отправляет зашифрованный файл, который сохраняется на /sdcard/.
Ладно, будем решать проблемы по мере их поступления, а сейчас наша основная проблема состоит в том, что мы всё еще не знаем, какой файл нам нужно скачать. Однако в процессе изучения класса ConnectionHandler мы не могли не заметить, что прямо между методами getToken() и getEncryptedFile() разработчики FileDroid забыли еще один очень соблазнительный метод под говорящим названием getListing(). Значит, сервер такой функционал поддерживает… Кажется, это то, что нужно!
Для получения листинга нам потребуются уже известные «crc» и «sign» – не проблема, мы уже знаем, откуда они берутся. Считаем значения, отправляем GET-запрос и … Так, стоп. А куда мы GET-запрос собираемся отправлять? Неплохо было бы сначала получить URL-адрес удаленного сервера. Эх, возвращаемся в MainActivity.onClick() и смотрим, как формируются аргументы netPath для вызова методов getToken() и getEncryptedFile():
Странные буквосочетания «fnks» и «qdmk» вынуждают нас обратиться к результату декомпиляции метода wat.getSecure(). Спойлер: этот результат у JADX так себе.
При более пристальном рассмотрении становится понятно, что всё это не слишком приятное содержимое метода можно заменить на привычный switch-case такого вида:
Так как «fnks» и «qdmk» уже используются для получения токена и скачивания файла, то «tkog» должен давать URL, необходимый для запроса листинга доступных файлов на сервере. Кажется, появляется надежда дешево получить требуемый путь… В первую очередь посмотрим, как хранятся URL’ы в приложении. Открываем функцию com.ctf.filedroid.x37AtsW8g.rlieh786d() и видим, что каждый URL сохранен в виде закодированного массива байтов, а сама функция формирует из этих байтов строку и возвращает её.
Хорошо. Но далее строка передается в функцию com.ctf.filedroid.wat.radon(), реализация которой вынесена в нативную библиотеку libae3d8oe1.so. Реверсить arm64? Хорошая попытка, FileDroid, но давай в другой раз?
2. Получаем URL-адреса сервера
Попробуем подойти с другой стороны: перехватить трафик, получить URL-адреса в открытом виде (а в качестве бонуса – еще и значения контрольной суммы и подписи!), сопоставить их байтовым массивам из com.ctf.filedroid.x37AtsW8g.rlieh786d() – может быть шифрование окажется обычным шифром Цезаря или XOR. Тогда не составит труда восстановить третий URL-адрес и выполнить листинг.
Для перенаправления трафика можно использовать любой удобный прокси ( Charles , fiddler , BURP и т.п.). Выполняем настройку переадресации на мобильном устройстве, устанавливаем соответствующий сертификат, проверяем, что перехват осуществляется успешно, и запускаем FileFroid. Пытаемся скачать произвольный файл и … видим «NetworkError». Вызвана эта ошибка наличием certificate-pinning (см. метод com.ctf.filedroid.ConnectionHandler.sendRequest): файловый клиент проверяет, что «зашитый» в приложение сертификат соответствует серверу, с которым осуществляется взаимодействие. Теперь понятно, почему контролируется целостность ресурсов приложения!
Однако в перехваченном трафике мы можем увидеть хотя бы доменное имя сервера, к которому обращается файловый клиент, а значит, надежда расшифровать URL-адреса остается!
Вернемся к функции com.ctf.filedroid.x37AtsW8g.rlieh786d() и отметим, что во всех массивах совпадают первые несколько десятков байт:
Кроме того, последний байт третьего массива намекает, что без base64 дело не обошлось. Попробуем декодировать и поксорить получившиеся байты с известной частью URL:
Кажется, никто никогда еще так не радовался ARMag3dd0n’у! Дело за малым: последовательно декодируем из base64 URL-адреса и ксорим с найденным ключом. Но… а если бы это был не XOR, а самопальный перестановочный шифр, который не подберешь и со ста попыток?
3. Пересобираем apk с помощью Frida
В рамках этого write-up’а рассмотрим более безболезненный (и, на наш взгляд, более красивый) способ решения – с помощью фреймфорка Frida , который позволит в run-time исполнить произвольные методы apk-приложения с нужными нам аргументами. Для этого потребуется телефон с root-правами или эмулятор. Предполагаем следующий план действий:
- Установка компонентов Frida на ПК и подопытный телефон.
- Восстановление URL-адресов, соответствующих запросам на получение токена или листинга, и скачивание файла (с помощью Frida).
- Извлечение значений контрольной суммы и подписи оригинального приложения.
- Получение листинга файлов, хранящихся на сервере, и выявление нужного файла.
- Скачивание и расшифрование файла.
Вновь обращаемся к классу MainActivity и обнаруживаем, что в onCreate() вызывается метод doChecks(), который и вывел в лог приведенные ошибки:
Кроме того, в onResume() также проверяется, открыт ли типичный для Frida порт:
Наш файловый клиент оказывается немного нетолерантным к отладке, руту и самой Frida. Такое противодействие абсолютно не входит в наши планы, поэтому получаем smali-код приложения с помощью утилиты apktool , открываем в любом текстовом редакторе файл MainActivity.smali, находим метод onCreate() и превращаем вызов doChecks() в безобидный комментарий:
Затем лишаем метод suicide() возможности действительно завершить работу приложения:
Далее снова соберем наше слегка улучшенное приложение с помощью apktool и подпишем его, выполнив следующие команды (могут понадобиться права Администратора):
Переустанавливаем приложение на телефоне, запускаем его – ура, загрузка проходит без происшествий, лог чист!
Переходим к установке фреймворка Frida на ПК и мобильное устройство:
Запускаем сервер фреймворка Frida на мобильном устройстве:
Подготавливаем простой скрипт get-urls.js, который вызовет wat.getSecure() для всех поддерживаемых серверов запросов:
Запускаем FileDroid на мобильном устройстве и «цепляемся» нашим скриптом к соответствующему процессу:
4. Получаем листинг файлов на сервере
Наконец-то удаленный сервер стал для нас чуть ближе! Теперь нам известно, что сервер поддерживает запросы по следующим путям:
Вручную тоже можно. Любым удобным инструментом считаем CRC32 от classes.dex и resources.arsc (например, для Linux – стандартной утилитой crc32), получаем значения 1276945813 и 2814166583 соответственно, конкатенируем их (выйдет 12769458132814166583) и кодируем в base64, например, тут :
Для того, чтобы выполнить аналогичную процедуру для подписи приложения, в окне JADX переходим в раздел «APK Signature», копируем значение «SHA-256 Fingerprint» и кодируем его в base64 как байтовый массив:
Важно: в оригинальном apk base64-кодирование осуществляется с флагом URL_SAFE, т.е. вместо символов «+» и «/» используются «–» и «_» соответственно. Необходимо убедиться, что при самостоятельном кодировании это будет тоже соблюдаться. Для этого при кодировании онлайн можно заменить используемый алфавит с «ABCDEFGHIJKLMNOPQRSTUVWXYZabcde fghijklmnopqrstuvwxyz0123456789+/» на «ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijkl mnopqrstuvwxyz0123456789–_», а при использовании скрипта на python3 – просто вызвать функцию base64.urlsafe_b64encode().
Наконец-то у нас есть все составляющие успешного получения листинга файлов:
Далее запросим одноразовый токен доступа и скачаем файл:
Открываем скачанный файл и вспоминаем об одном небольшом обстоятельстве, оставленном нами на потом:
5. Добавим щепоточку криптографии.
Эх, рановато мы отложили FileDroid. Снова вернемся в JADX и посмотрим, не оставили ли разработчики файлового клиента чего-нибудь полезного для нас. Да, это тот случай, когда code cleanup явно не популярен: неиспользуемый метод decryptFile() спокойно ждет нашего внимания в классе ConnectionHandler. Что мы имеем?
Помещаем зашифрованный файл 0p3n1fuw4nt2esk4p3.jpg на /sdcard/, запускаем FileDroid и инжектим скрипт decrypt.js с помощью Frida. После того, как скрипт отработает, на /sdcard/ появится файл plainfile.jpg. Открываем его и … just solved!
Это непростое задание требовало от участников знаний и навыков сразу в нескольких сферах инфобеза, и мы рады тому, что большинство соревнующихся успешно с ним справилось! Надеемся, что те, кому чуть-чуть не хватило времени или знаний до получения ключа, теперь тоже успешно пройдут аналогичные таски в любом CTF :)
Android разработка клиент-сервера
Всем привет! Встал вопрос создания клиент-сервера, но к сожалению об обращении клиента к серверу.
Разработка под Android на C++
Всем привет! Господа, подскажите пожалуйста есть ли технологии/способы/методы/инструменты для.
Разработка под Android на c++
Возможно ли на c++ написать игру или прогу под андроид. Ну или же на том же UE4?Многие говорили что.
TCP клиент под Android
Доброго времени суток. Имеется TCP сервер под Windows, написанный на Delphi XE5, также имеется.
Клиент, соответственно, находит сервер в интернетах
по ip адресу и порту.
Примеров в сети масса, как из этого вагона информации вы не смогли найти ответы на такие простые вопросы - загадка.
И где и как мне разместить серверную программу ни где информации нет Да где угодно. Это либо хостинг, либо какой-то ваш компьютер с доступом в интернет. 1. эта тема не для раздела андроида
2. нормальные люди используют имена серверов, а не обращаются по IP нормальные люди используют имена серверов, а не обращаются по IP там циферки через точечку, а там буковки
серьезно, не понимаешь или просто не согласен? Не понимаю в чем принципиальная разница в рамках данной темы.
а нет разницы - в рамках этой темы или не в рамках
Для чего? Ответ всегда один и тот же - нет жесткой привязки по IP.
Ну и я считаю эта тема не для раздела андроида. В хостинг или к админам дорога.
Для новичка firebase достаточно будет. Подключается из коробки за 5 минут. Отправка всякой херни и сохранение в пару строк кода.
Добавлено через 2 минуты
Использовать IP как минимум неудобно.
С firebase я бы не связывался, особенно, если корпоративное решение собираетесь делать. Политика и поведение гугла в долгой перспективе непредсказуемо.
Сложного ничего нет. Отдельно создается веб-сервер (или в рамках корпоративного сервера) со своей базой данных, а в приложение встраивается функционал общения с этим сервисом.
Арендуете какой нибудь VDS, я например выбрал first (не реклама), но у них приятная wiki на все случаи жизни.
При аренде выберите ОС и конфигурацию, после завершения придёт письмо с вашим личным IP для вашего VDS.
На нём поднимаете что хотите, хоть java сервер, хоть web(можно заренее установить автоматически).
В самой java программе должен быть сервер сокет
new ServerSocket(2000);
2000 это порт
теперь чтобы подключиться из android, в android надо использовать соответственно
При этом на сервере можете в одном потоке работать пока с одним клиентом, потом или nio или по потоку на клиента, тут от кол-ва клиентов исходить и своих возможностей.
В android же обязательно отдельный поток, ну это поймёте на автомате потом.
Сейчас пока арендовать ничего не надо, работайте в локальной сети, чтобы деньги зря не тратить.
Потом когда научитесь работать дома тогда и переносите сервер в vds, а в android приложении просто в addr замените ip и всё.
И да, мы прописываем ip циферками в приложении дабы исключить проблемы с DNS различного рода.
Разработка под Android и Windows
Добрый день. Написал приложение на Android, использовал Android Studio. Приложение на Java. Можно.
Мобильный клиент для сайта под Android
Здравствуйте! Уже год как программирую на JAVA под Android. Вот решил написать для друга клиент на.
Разработка под Android. Состояние пункта в списке
При разработке приложения столкнулся с такой проблемой. У меня есть ListView, нужно что бы при.
В предыдущих статьях [1, 2] из этой серии было описано проектирование и создание внешнего вида интерфейса. Результат изображен на следующих скриншотах экрана (рисунок 1).
Рисунок 1 – скриншоты верстки приложения.
Следующая стадия разработки – это получение контента каждой страницы приложения от сервера и обработка нажатия кнопок. Она включает в себя следующие этапы:
- Разработка серверной части приложения (создание модуля обработки запросов на сервере):
- Написание функции получения информации о конкретном фильме;
- Написание функции получения информации о конкретном кинотеатре;
- Написание функции получения списка всех кинотеатров;
- Написание функции получения списка всех фильмов;
- Написание функции получения списка расписания одного кинотеатра;
- Написание функции получения списка расписания одного фильма;
- Создание браузерного клиента для получения контента с сервера;
- Создание меню приложения;
- Обработка события нажатия кнопки назад.
Получаем схему работы нашего приложения:
- Делается запрос на сервер.
- Сервер обрабатывает запрос и формирует соответствующий контент.
- Сервер посылает сгенерированный контент приложению.
- Приложение воспроизводит контент.
Самая простая и эффективная реализация предложенной схемы – это организация работы приложения, как браузера, который будет обмениваться информацией с сервером, загружать и показывать нужные страницы. Сервер будет отдавать контент в виде полноценной html-страницы со ссылками на другие страницы.
Перейдем к написанию кода приложения. Открываем файл main.java. В этом файле требуется описать событие создания основного класса. Фрагмент кода показан ниже.
На данном этапе при загрузке приложение будет обращаться к указанному нами адресу. Далее требуется настроить веб клиент. Дописываем следующий код в onCreate
Теперь при загрузке приложения будет открываться главный интерфейс с сервера (страница кинотеатров). При переходе по ссылке предыдущее значение ссылки запоминается. Далее опишем событие нажатия кнопки назад.
Создаем меню приложения.
Клиентская часть приложения написана. Код работы сервера написан на php. Так как целью данной статьи является создание приложения для android, то код серверной части приведен не будет.
Сделаем выводы. Поставленные задачи выполнены: приложение имеет все запланированные интерфейсы и легко управляется с помощью ссылок, выступая в роли браузера. Пользователь может получить доступ к предыдущей странице как с помощью кнопки назад, так и используя ссылку на странице. Существует небольшое меню для того, чтобы сделать навигацию еще более простой. Каждый интерфейс дает исчерпывающую информацию на свою тему.
Данная реализация хороша тем, что приложение не сильно задействует ресурсы телефона или планшета. Адаптивная верстка страниц выглядит одинаково на устройствах с разным разрешением экрана.
Минусы текущей реализации заключаются в том, что без доступа в интернет пользователь не сможет пользоваться приложением. Так же уже загруженные страницы при повторном заходе на них обновляются. Данная проблема решается кешированием страниц, что будет реализовано в дальнейшей модификации проекта.
Список литературы
Читайте также: