Как написать бэкенд для мобильного приложения

Обновлено: 08.01.2025

В настройках файла settings.py прописываем необходимые настройки для базы данных, локализацию, время. Устанавливаем пакет tastypie:

Обратите внимание, что требуется Python2.6+ и Django 1.5+. Из-за незнания этого факта пришлось потратить немного больше времени, т.к. фреймворк отказывался работать. Кроме того, нужно установить аналогичным образом пакет python-mimeparse.
Далее, в файле settings.py, прописываем:

или добавляем уже в существующий список приложение ‘tastypie’.
Теперь пропишем модели нашей предметной области:

Мы написали модель докладчика (Speaker) и модель выступления (Event). У каждого выступления обязательно есть докладчик. Теперь, сделаем так, чтобы мы могли полноценно работать с нашими моделями как с ресурсами через REST протокол.
Создаем в нашем приложении пакет api и файлом resources.py (или можно его создать в основном пакете).

В этом файле мы создали классы, так называемых ресурсов, основных объектов в нашем REST сервисе. Это как раз те ресурсы, к которым мы будем обращаться. Каждый класс содержит ссылку на ту модель, которую он представляет. Поле queryset возвращает нам набор объектов получаемых из базы при обращении к даному ресурсу. Поле resource_name необязательно, и позволяет нам указать дополнительно наименование ресурса, по которому он будет доступен нам.
Еще один момент, в классе EventResources мы указали отдельное поле speaker, которое указывает что ресурс события ссылается на ресурс спикера.
Теперь осталось только прописать в файле urls.py обращения к нашему сервису. Это делает очень просто.

Теперь запускаем наш проект

В нем, мы находим спикера в базе и подставляем его в объект bundle, который представляет из себя словарь который отдается ресурсом. Теперь, ответ на запрос будет выглядеть так (напишу только основную часть):

Заключение

Отлично! Теперь мы уже можем обращаться к серверу, получать от него данные. А ведь именно это нам и требовалось.
Если статья вызовет интерес, то можно продолжить рассказ о том как сюда добавить валидацию, авторизацию и прикрутить симпатичную админку в такие кратчайшие сроки.

Меня зовут Ленар Деллерт, я фулстек-разработчик мобильных приложений в IT-компании Neti. Разрабатывать и для веба, и для «мобилок» научился сам, какого-то специального «программистского» образования у меня нет. В статье объясню, какие специалисты требуются в мобильной разработке, расскажу, как освоил программирование с нуля, и поделюсь ресурсами, на которых можно учиться.

Бэкенд, фронтенд, фулстек: кто есть кто в мобильной разработке

В основном мобильные приложения состоят из фронтенда и бэкенда: фронтенд — интерфейс, с которым взаимодействует пользователь, а бэкенд — серверная часть, на которой хранится и обрабатывается информация. Фронтенд и бэкенд обмениваются данными через API.

Сделать бэк сложнее, чем фронт, потому что чаще всего именно на бэкенде закладывается бизнес-логика программы. Если бэкенд и API реализованы плохо, приложение будет тормозить, вылетать и раздражать пользователей. Серверную часть и API делают бэкенд-разработчики. В нашей компании бэкендеры кодят на PHP на фреймворках Laravel и Yii2.

Бывают простые приложения без бэка, но они «зациклены» на самих себе: через них нельзя, например, оплатить заказ в корзине, попереписываться с менеджером в чате, забронировать столик.

3–4 декабря, Онлайн, Беcплатно

Теперь поговорим о том, кто реализует фронтенд. Если бы речь шла о разработке сайтов, я бы написал, что для создания фронта нужен фронтенд-разработчик. Но в мобильной разработке все немного запутаннее: здесь фронтендом занимаются разработчики кроссплатформенных решений и разработчики нативных приложений.

При нативном подходе для операционных систем Android и iOS делают два отдельных приложения. Для этого требуются два специалиста: android-разработчик, который пишет на Java или Kotlin, и iOS-разработчик, который пишет на Objective-C или Swift.

Java vs Kotlin для Android-разработки: ответы «за» и «против»

Еще есть фулстек-разработчики — это специалисты два в одном, которые могут сделать и бэкенд, и фронтенд. Я фулстек-разработчик мобильных приложений: бэкенд реализую на Yii2, фронтенд — на React Native. Нативные приложения не совсем мой профиль: я пробовал писать под iOS и Android в рамках коммерческой разработки, но считаю, что у меня недостаточно опыта, чтобы давать какие-то советы.

Теория

Если человек задумывается о карьере в IT, в первую очередь он должен понять, интересна ли ему эта сфера. Готов ли он целый день сидеть и писать код? Не захочет ли все бросить, если над задачей придется биться несколько часов? Идти в программирование из-за хороших зарплат не стоит, потому что деньги — недостаточная мотивация. Многие забывают, что зарабатывать люди начинают после того, как потратят несколько лет на обучение и приобретение опыта.

Я считаю, что человеку должно быть по-настоящему интересно то, что он делает. В этом секрет. Когда у меня появился высокоскоростной интернет, мне стало интересно, как работают сайты. Я полазил по разным ресурсам, форумам и узнал об HTML и CSS. Нашел по ним уроки, познакомился с базовыми понятиями и стал делал html-странички. Потом захотел придать им интерактивности, понял, что для этого нужен язык JavaScript, и начал изучать его.

Сайты, на которых я изучал HTML, CSS, JavaScript:

Дальше я заинтересовался, как сделать полноценный сайт. Только на одном фронтенде приложение держаться не может: для более сложных действий, например, для авторизации пользователя, нужен бэкенд. Так я вышел на язык PHP и объектно-ориентированное программирование.

Ресурсы для изучения PHP:

.
• Книга Мэтта Зандстра «PHP: объекты, шаблоны и методики программирования».

Я увлекся программированием, когда учился в консерватории. Времени на хобби было мало: иногда занятия в вузе начинались в 7 утра и заканчивались в 7 вечера плюс я работал педагогом в музыкальной школе. Но разрабатывать сайты нравилось мне все больше. На втором курсе я понял, что хочу стать программистом, а не музыкантом, и бросил консерваторию. Но музыкой занимаюсь до сих пор для себя.

Моя страсть узнавать новое привела меня в мобильную разработку. Когда я уже работал PHP-программистом, мне было скучно использовать одни и те же инструменты, и я попросил тимлида, который писал под iOS и Android, научить меня разрабатывать под одну из этих ОС. Он показал, как делать приложения под Android. Это меня увлекло. Сначала я писал под Android, потом захотелось попробовать кроссплатформенные решения и я разобрался во фреймворке Xamarin.

В 2019 году мне предложили сделать мобильное приложение на React Native для логистической компании, и я согласился, хотя раньше не писал на этом фреймворке. Было интересно, как он работает. Чтобы освоить React Native, я читал документацию, лазил по GitHub и форумам. Как всегда, спасал сервис Stack Overflow: если не хватало информации, я находил там ответы на свои вопросы. Если я не знал, как решить задачу, я гуглил. Умение гуглить очень важно для любого разработчика. Кстати, лучше формулировать запросы на английском языке — так больше шансов найти ответ.

Практика

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

Изучая новый язык или фреймворк, я часто пишу что-то для себя. К примеру, чтобы понять, как работает Zend Framework, я разбирал его компоненты. Брал Query Builder, который используется для построения SQL-запросов, копался в нем и пытался написать свой «велосипед». Затем разбирался в следующем компоненте.

Чтобы освоить Swift и среду разработки Xcode, я написал для часов Apple Watch приложение, которое в реальном времени показывает погоду. Не скажу, что после этого стал крутым iOS-разработчиком, но теперь проверяя код для iOS других программистов, могу понять, что написано, и посоветовать, как сделать лучше.

Алгоритм для тех, кто хочет стать разработчиком, такой:

Дальше расскажу, какие технологии должны знать начинающие React Native и бэкенд-разработчики, чтобы найти работу.

Что должен знать начинающий React Native разработчик

Чтобы устроиться младшим React Native разработчиком, нужно освоить на базовом уровне следующие технологии:

• Язык программирования JavaScript.
• Навыки верстки с применением HTML, CSS.
• Фреймворки ReactJS и React Native.
• Основы разработки под Android и iOS. Необходимые понятия: «жизненный цикл», «активность», «фрагмент». Уметь работать с файлами настроек: для Android это AndroidManifest.xml, для iOS — info.plist. Знать, как поднять версию приложения и выставить права для определенных сервисов (например, геолокации или доступ к фотогалереи).
• Основы работы с системой контроля версий Git.

Как разработать своё первое приложение на React Native

Что должен знать начинающий бэкенд-разработчик мобильных приложений

Вот что должен знать джун-бэкендер, чтобы получить работу:

У нас на собеседовании еще могут поспрашивать по архитектурным паттернам. Это сложнее, поэтому знать необязательно, но будет плюсом.

Soft Skills

Стоит добавить, что кроме hard skills джуниор-программисту пригодятся такие soft skills:

Нет универсального рецепта, по которому каждый человек освоил бы программирование. Я поделился своим видением. Возможно, кому-то больше понравится проходить курсы. Хорошие курсы помогут быстрее составить правильное представление о базовых вещах, чем формировать его самому. Но разбираться, как лучше решить практическую задачу заказчика, исходя из контекста ситуации, все равно придется самостоятельно, параллельно восполняя пробелы по документации, сайтам и форумам. Это и называется опыт. В любом случае главное — не бояться и делать. Если с первого раза не получилось — переделывать. Тогда точно получится.

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

1. Что такое бэк-энд?

Прежде чем мы углубимся в детали доступного сервиса, давайте разберемся с терминологией.

Что касается мобильных и веб-приложений, мы часто говорим о фронтэнде и бэкэндах. В то время как внешний интерфейс определяет пользовательский интерфейс, взаимодействие с пользователем и представление информации, внутренний обрабатывает бизнес-логику, хранение данных и безопасность. Внешний интерфейс — это веб-браузер пользователя или мобильное устройство, а внутренний — сервер или серверы, на которых хранятся и передаются данные.

2. Кто разрабатывает это?

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

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

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

3. Back-End как услуга (BaaS) для спасения

Облачные вычисления вошли в мейнстрим, и XaaS (то есть BaaS, SaaS, PaaS и т. Д. — Back-End как услуга, Программное обеспечение как услуга или Платформа как услуга) уже начали пересматривать способы разработки, публикации программного обеспечения, и потребляется.

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

В то время как различные поставщики BaaS предлагают разнообразные функции благодаря большому разнообразию моделей ценообразования, большинство из них используют какую-то модель «freemium». Это означает, что основные функции, такие как хранение данных, аналитика пользователей / использования, push-уведомления и аутентификация, предоставляются бесплатно до определенного предела использования. Как только использование превышает этот лимит или запрашиваются дополнительные функции, взимается плата. Это позволяет легко создавать и запускать приложения на уровне бесплатного использования, а затем расширять до платного уровня по мере добавления клиентов.

Обычно разработчик должен использовать SDK и API поставщика BaaS для подключения своего приложения к серверной части.

4. Плюсы и минусы BaaS

Самым большим преимуществом BaaS является то, что он освобождает разработчиков от бремени создания и управления бэкэндами самостоятельно. Это позволяет разработчику сосредоточиться на более важных вещах, таких как создание привлекательного пользовательского интерфейса, который будет фактическим фактором успеха приложения. Кроме того, это помогает разработчику избежать крутых кривых обучения, обычно связанных с большинством внутренних технологий. Таким образом, это снижает стоимость и время разработки. Это также обеспечивает дешевый способ экспериментировать с идеями приложений и увидеть, как они работают в реальном мире.

Как и во всем остальном, BaaS имеет некоторые компромиссы. Самым большим недостатком является опасность того, что ваш поставщик BaaS может внезапно прекратить свою деятельность и закрыть сервис. В таком случае, даже если вы переключаетесь на другого провайдера, вам может потребоваться существенно изменить дизайн и перекодировать ваше приложение, поскольку новая служба может иметь совершенно другой API. Фактически, один из самых популярных поставщиков BaaS, Parse, недавно закрылся, что затронуло многих разработчиков (хотя инфраструктура Parse была выпущена по лицензии с открытым исходным кодом, и появились новые поставщики, чтобы предоставить BaaS-совместимый с Parse) ,

Другим недостатком является то, что настройка серверной инфраструктуры в BaaS часто ограничена. Это может означать, что некоторые функции, которые вы хотите использовать для своего приложения, недоступны.

5. Как выбрать провайдера BaaS?

Есть несколько вопросов, которые вы должны задать себе о каждом провайдере BaaS, прежде чем выбрать один для своего мобильного приложения.

Для всех, кто не любит делать UI, «дышит» очередями и мечтает об идеальном API, в четвёртый выпуск подкаста «Сушите вёсла» мы позвали backend-разработчиков Андрея, Азата и Антона.

Железные разработчики Redmadrobot Артём и Рома записывают подкаст, где вместе с гостями обсуждают разные стороны создания ИТ-продуктов и делятся опытом в диджитале. В четвёртом выпуске ведущие разузнали у собеседников, с чего начинался их путь в backend, какой web-framework стоит выбрать, снится ли им верстка экранов и как объяснить маме, кем ты работаешь.

Прикладываем подкаст и ответы на несколько животрепещущих вопросов.

01:27 — Как приходят в backend-разработку.

10:33 — Что привлекает специалистов в backend.

12:32 — Срыв покровов: нужны ли глубокие знания алгоритмов для тех, кто «пилит апишку»?

15:17 — Вопросики масштабирования и безопасности.

16:23 — Одинаковую ли работу делают все backend-разработчики?

19:23 — Ruby on Rails, его «магия», взлёт и падение.

24:23 — Как выбрать платформу?

28:06 — Зачем нужны микрофреймворки и как с ними работать?

33:55 — Что такое асинхронный сервер и для чего он нужен?

35:58 — Go: простота и архитектура.

41:46 — Postgresql вместо MySQL. Почему?

44:58 — Зачем нужно изучить Docker как можно быстрее и для чего стоит поставить nginx?

50:49 — «Зелёные» разработчики: какими минимальными навыками необходимо обладать выпускникам университетов, чтобы устроиться на работу?

1:04:21 — Лучшие книги по алгоритмам.

1:09:33 — Что нужно знать и что не нужно делать на собеседовании?

1:14:29 — Не хочется ли ребятам уйти из backend?

1:20:28 — И все-таки, чего не стоит делать на работе и почему «с людьми нужно общаться»?

Несмотря на популярность мобильной разработки, остались еще те, кому милее старый-добрый backend. Среди них, разумеется, и наши гости.

Азат, например, рассказал, как он не пошел в мобильную разработку и решил, что логичнее заниматься веб-разработкой в широком смысле. А вот история Антона тесно связана с Python.

Я учился в университете и выучил Python. Он мне нравился, и мне хотелось продолжать делать что-то на «питоне». А в Белгороде, где я жил и учился, можно было найти только какую-нибудь веб-студию, которая делает сайты на CMS — просто подверстывают шаблоны. Мне этим вообще заниматься не хотелось.

Поэтому мы с другом нашли каких-то людей, сделали им сайт, а потом ещё кому-то сделали. И было классно, потому что я делал то, что хотел. Но хотел я, наверное, не то, что было нужно в тот момент. Но по крайней мере я научился делать backend и после этого нашёл нормальную работу.

…Когда есть суперпопулярный frontend?

Артём вспомнил множество собеседований, на которых соискатели рассказывали, почему они хотят строить карьеру в мобильной разработке. Просто чтобы потом похвастаться крутостью приложения. В backend с этим сложнее.

Но на самом деле, если друзья, с которыми ты делишься радостью создания backend, понимают в ИТ-разработке, то они похвалят тебя. А вот маме можно сказать, что делал сервер для мобильного приложения магазина, которым она пользуется. И даже если ей не до конца понятно, что такое сервер, мама всё равно будет гордиться.

Азат предположил, что людей привлекает тот факт, что не нужно верстать. Ещё есть мнение, что backend сложнее и круче, хотя каждому, конечно же, свое. После этого ребята ушли в беседу о масштабировании и безопасности. Подробнее — с 15:17.

Это не так. Задачи в backend-разработке бывают разными, и они зависят не от языка или платформы, а от потребностей и специфики компании, а также от уровня самого разработчика.

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

Ребята в студии заговорили о том, как выбрать платформу. А также о том, что Ruby «ещё живет» (Рома недавно видел доказательство), а ещё почему Антон начал учить Python, о странных именах создателей языков программирования, простоте Go, микрофреймворках (о них говорили особенно много — слушайте с 28:06), MySQL, Docker, асинхронных серверах и магии рельсов.

«Зелёные» разработчики и минимальные навыки для соискателя

Насколько глубоко должен, например, выпускник университета разбираться в backend, чтобы получить работу?

Во время обсуждения выяснилось, что он должен быть «уверенным пользователем ПК». А если серьезно, то? по мнению Азата, молодой специалист обязан обладать минимальными навыками администрирования Unix-систем — знать определенный набор команд: cd, ls и другие.

Также должен понимать, что такое процесс, какие есть права доступа, какая система прав Linux и как вообще в ней функционируют сети, как работает IPC (inter process communications), TCP сокеты. Для начала этого достаточно. Нужно просто уметь программировать.

Есть базовые вещи, общие для любой разработки, допустим, для ООП (объектно-ориентированного программирования) есть правила написания, проектирования классов. Если это алгоритмы, нужно просто знать, как они проектируются, что там есть, динамическое программирование, ну и «использовать stack везде, где можно».

Иными словами, для начала погружаться в это с головой не нужно.

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

Андрей «топил» за Стивена Скиена и его «Алгоритмы. Разработка и применение». Антон порекомендовал книгу Томаса Кормена, в которой «есть баланс между строгостью, понятностью и простотой изложения», и ещё “Cracking the Coding Interview” — хорошее практическое руководство, чтобы быстро разобраться в алгоритмах.

Также гости посоветовали «Искусство программирования» Дональда Кнута, которая задумывалась как пособие по компиляторам, а стала настоящей «книгой книг».

Ребята пришли к выводу, что во всех сферах веб-разработки есть свои плюсы и минусы. И это нормально. Если вам нравится backend, алгоритмы и очереди, то вам стоит задуматься о карьере именно в нём. Это если кратко.

Если же хочется вживую услышать рассуждения, то включайтесь в подкаст с 1:14:29.

Сказать, что по нашей улице прошел инкассатор, — это ничего не сказать. Займемся изучением инструмента вплотную!

Farewell VK, hello Firebase

В своих предыдущих статьях я рассматривал VK API как бесплатный бэкенд мобильных приложений. У него есть ряд преимуществ. Хостинг безлимитный, типов контента много, управлять им может даже школьник, достаточно объяснить ему структуру наполнения приложения.

На наше счастье, Google выкупила компанию Firebase и открыла ее для использования всем желающим.

Подробнее, что там есть интересного

В нашем распоряжении имеются:

• Analytics — аналитика по приложению: размер аудитории, информация о пользователях, события в приложении и прочее.
• Authentication — пользователи могут привязать свои учетные записи к приложению, а к ним мы можем привязать любые данные. Из коробки поддерживаются следующие провайдеры авторизации: Google, Facebook, Twitter, GitHub, анонимный вход и имейл-пароль для своей регистрации. Не хватает только VK-авторизации.

• Realtime Database — самая настоящая база данных, работает с живыми изменениями в реальном времени.
• Storage — хранилище для файлов пользователей, можно легко сделать персональное хранилище, а можно и делиться файлами.
• Hosting — тут просто моментальное развертывание веб-приложений и мобильных приложений с помощью безопасной глобальной сети доставки контента.
• Test Lab for Android — тестируй приложения Android на самых разных устройствах.
• App Indexing — свяжи информацию с веб-сайта с внутренними страницами приложения, также есть возможность индексировать данные приложения и отображать их в результатах поиска на устройстве.
• Crash Reporting — сбор информации о сбоях в приложении (на ранних версиях и сам был источником крашей, но вроде починили).
• Notifications — уведомления, замена старым Google Cloud Messaging.
• Remote Config — способ менять поведение приложения прямо со своего сервера, изменяя нужные параметры.
• Dynamic Links — полезный способ прокинуть контекст в приложение (например, пользователь читал про аспирин на твоем сайте, перешел в маркет, установил приложение, и ему открылась страница с аспирином).
• AdMob — рекламный сервис с множеством форматов, по праву занимает лидирующие позиции в мобильной рекламе. У этой сети рекламы всегда много, и она модерируется.

А за что попросят деньги?

Деньги с нас справедливо попросят, если наш бизнес действительно разрастется. Когда он упрется в бесплатные лимиты, платить нам уже будет с чего.

Бесплатно нам доступно:

• Realtime Database:
  • 100 единовременных подключений
  • 1 Гбайт хранилища
  • 10 Гбайт в месяц трафика
  • 5 Гбайт хранилища
  • 1 Гбайт в день трафика
  • 20 000 операций загрузок в день
  • 50 000 операций скачивания в день
  • 1 Гбайт хранилища
  • 10 Гбайт в месяц трафика
  • Custom domain hosting & SSL
  • запуск не более пятнадцати тестов в день (десять на виртуальных и пять на физических устройствах)

  Более подробно читай здесь.

  
  

  Наш бесплатный Spark
  

  Аутентификация в приложении

  Чтобы пользователь мог сохранять настройки приложения на сервере, нужно создать учетную запись. Firebase позволяет это делать при помощи создания собственной учетной записи, как на любом сайте с имейлом-паролем. Также можно привязаться к учетным записям Google, Facebook, Twitter, GitHub. В своих приложениях я использую аккаунты Firebase и Google.

  
  

  Разрешенные способы входа
  

  Хороший пример кода для вдохновения ты найдешь здесь. А как сделать свою регистрацию, внятно описано тут.

  Для связки Google-аккаунта с приложением я делаю следующее. В методе OnCreate нужной Activity создаю объекты GoogleApiClient, FirebaseAuth и слушателя аутентификации FirebaseAuth.AuthStateListener.

  Чтобы запустить аутентификацию, используем простой метод:

  Запущенная активити предложит нам выбрать учетную запись Google из хранящихся на устройстве. После выбора нужно обработать результат в методе onActivityResult :

  После выполнения функции firebaseAuthWithGoogle сработает наш слушатель аутентификации mAuthListener.

  Отключить приложение от учетной записи поможет метод revokeAccess() : в его колбэке обновляем интерфейс приложения.

  Данные пользователя

  Информацию о текущем привязанном пользователе мы получаем из объекта FirebaseUser:

  • getPhotoUrl() — вернет null или ссылку на аватар пользователя;
  • getEmail() — имейл-адрес;
  • getUid() — уникальный ID пользователя в системе;
  • getDisplayName() — имя пользователя;
  • getProviderData().get(1).getProviderId() — подскажет, как пользователь аутентифицировался (проверь на equals("password") , если через email/пароль).

  Имея ссылку на аватар пользователя, можно в одну строчку кода загрузить его и отобразить в приложении. Для этого есть множество сторонних библиотек: Glide, Fresco, Picasso. Но если на счету каждый килобайт, то можно использовать свой AsyncTask. Вызываем загрузку так:

  DownloadImageTask в фоне загружает картинку, а в UI-потоке устанавливает ее в нужный ImageView:

  
  

  Раздел «Аутентификация» в консоли разработчика
  

  Работа с Realtime Database

  Читать данные из Realtime Database можно и не представившись, для описания уровней доступа к информации используются правила. Описываются они в древовидной форме, можно задать отдельные правила на каждую ветвь.

  Древовидная структура данных
  Пример правил из моего проекта
  

  В моем проекте настройки пользователей хранятся в ветке history. Пользователь может читать только свою ветвь и только если он представился. Для проверки работы правил доступа есть симулятор.

  
  

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

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

  
  

  В бесплатный тариф укладываемся с запасом
  

  Резервные копии на текущем тарифе недоступны, но если бизнес разрастется, то обязательно купим и настроим.

  Пишем и читаем данные с Android

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

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

  • String ;
  • Long ;
  • Double ;
  • Boolean ;
  • Map<String, Object> ;
  • List<Object> .

  Вот как просто объект User записывается в ветку users:

  Получить уникальный userId пользователя после аутентификации очень просто: user.getUid() . Чтобы обновить данные, нужно просто вызвать setValue() с новыми данными. Уникальный ключ для каждого объекта позволяют получить методы push() и getKey() . В следующем примере я запрашиваю ключ для еще не добавленной записи, а потом создаю ветку с этим ключом и в нее сохраняю объект:

  Для чтения данных используются слушатели ValueEventListener, их нужно устанавливать на интересующие нас ветки методом addValueEventListener . Событие будет происходить каждый раз при обновлении данных на сервере, при первом подключении к БД, и просто так про запас еще раза два-три может произойти. Так что будь готов к этому морально и практически. Если тебе нужно прочитать данные один раз и больше не мучиться, то используй метод addListenerForSingleValueEvent .

  Вот пример одноразового получения списка объектов для текущего пользователя из ветки history.

  А если нам нужно постоянно отслеживать изменяющийся список, то в этом поможет слушатель ChildEventListener, который позволяет слушать не единичный элемент, а всю дочернюю ветку:

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

  Узнай своего пользователя при помощи Analytics

  Старый инструмент Google Analytics создавался изначально как инструмент для работы с вебом. Позже его адаптировали под нужды мобайла, но ограничение его было существенным. В новой аналитике Firebase собирается данных намного больше. Например, данные об удалении приложения, обновлении ОС на устройстве, очистка кеша приложения. Множество событий отслеживается автоматически и не требует нашего вмешательства.

  Если мы хотим собрать события внутри приложения, то нам поможет класс FirebaseAnalytics. В своих проектах, чтобы иметь возможность вызывать методы аналитики в любом месте проекта, я размещаю ссылку на объект аналитики в классе Application. Инициализирую его один раз при создании приложения:

  Метод select_content можно вызвать одной строчкой. Например, соберем данные по использованию пунктов меню: App.selectContent("меню","окно о-программе") или App.selectContent("меню","окно настройки") .

  Установив отслеживание событий в приложении, мы будем знать, что пользователя интересует больше всего. Данные, отправленные методом logEvent , нужно искать в консоли проекта на вкладке «События».

  
  

  События нашего проекта
  

  Все события на рисунке собраны системой автоматически, кроме select_content (его реализация описана выше). Вот детали по этому методу (тут ясно видно, куда отправились параметры CONTENT_TYPE и ITEM_ID ):

  
  

  Карточка события select_content
  

  Полный список событий FirebaseAnalytics доступен тут.

  Про подключение и вместо заключения

  После настройки всех необходимых модулей Firebase в консоли необходимо получить файл конфигурации с настройками проекта google-services.json . Там же можешь добавить контрольные суммы сертификатов SHA (это можно сделать через ассистент прямо из Android Studio: Tools → Firebase). Я добавляю два сертификата: один от дебаг-ключа и один релизный. Файл google-services.json размести в папку app проекта. В gradle-файле проекта не забудь подключить нужные библиотеки, например:

  И в конце допиши apply plugin: 'com.google.gms.google-services' , этот плагин обработает файл google-services.json .

  Эта статья — только первый подход к такому тяжелому снаряду, как Firebase. Недавно этот снаряд стал еще тяжелее, а значит, нам есть что изучать и использовать.

  Думаю, в будущем хакеры найдут достойное применение такой мощной и бесплатной технологии :).

  Читайте также:

    
  • Как адаптировать приложение под планшет android
    
  • Как пользоваться whatsapp recovery
    
  • Какая точка приложения силы трения
    
  • Почему постоянно слетает whatsapp на компьютере
    
  • Как пользоваться приложением mighty amp