Евгений Третьяков 

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

Практически любая CMS (content management system, система управления содержимым) обладает определенным набором функций, свойственных бэкэнду для приложения, но не любая сможет работать с мобильным приложением.

Для того, чтобы приложение могло "общаться" с CMS надо, чтобы CMS поддерживала такие технологии, как REST API для обмена данных и современные протоколы авторизации.  

На момент написания статьи, впрочем, как и десять лет назад, наиболее популярные CMS это WordPress, Joomla и Drupal. 

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

Преимущества CMS-бэкэнда перед остальными вариантами:

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

2. В случае "переезда" на более мощный тариф или к другому провайдеру сложность работ будет равна сложности переноса обычного сайта

3. Можно использовать как хостинг, так и VPS

4. Открытый исходный код и популярность позволят легко найти недорогого исполнителя на доработку функционала в случае необходимости

5. Легко соответствовать всем ФЗ, поскольку никто не мешает размещаться на отечественных серверах

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

Flutter поддерживает множество разных архитектурных подходов, и все они могут уживаться в одном приложении. Конечно, есть библиотеки, одновременное использование которых приведет к ошибке, но таких очень мало. Связано это с тем, что каждый виджет, каждый экран, в каком-то смысле сам по себе - когда Flutter отрисовывает виджет на экране, ему в этот момент не важно, с помощью чего был отрисован предыдущий виджет. Именно поэтому мы можем сочетать элементы управления Android (material) и iOS (cupertino) на одном экране. 

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

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

Это всегда выглядит как колода карт - когда мы переходим на новый экран, он как бы ложится поверх предыдущего, и когда мы возвращаемся "назад" по кнопке или программно - то мы убираем "верхний" экран обратно в колоду.

Способы поиска и "извлечения карты из колоды" и есть маршрутизация. 

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

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

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

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

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

Вы скачали исходный код, проверили, что он запускается без неразрешимых ошибок и настала пора сделать так, чтобы оно стало "вашим".

Сразу оговорка: если вдруг вас мучает совесть, что вы нагло пользуетесь плодами чужих трудов - помните две вещи:

Во-первых, вам не стоит говорить, что все написано именно вами. Упомяните настоящего автора как источника вашей программы. Такие замечания помогут ему сделать карьеру в будущем. Иногда вместо этого достаточно поставить ему звезду на GitHub - она одна стоит дороже тысячи лайков в инстаграме. Главное, если есть возможность - задонатьте ему! Часто такие авторы, выставляющие свой код напоказ пишут способы, которыми можно его поблагодарить. В общем, карму можно не испортить и даже улучшить. Скромно, но публично похвалив его за качественный код (даже если это немного не так) вы увеличите его шансы на дальнейшую счастливую жизнь.

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

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

В своем первом домашнем задании вы получили архив с проектом. Вам его надо будет распаковать и открыть в Android Studio. 
Распаковывать его лучше всего в отдельную папку в корне, как мы раньше говорили, чтобы легче было потом найти файлы - например, c:\app если у вас windows или в папку app в домашней папке пользователя, если у вас Linux или MacOS. Самое главное - не распаковывайте архив на рабочий стол, в папку "загрузки" или "документы"

Дальнейшие инструкции только в самом начале будут для пользователей Windows, сама работа с Android Studio не отличается в разных операционных системах.

После того, как папка с проектом была скачана и помещена куда надо, нажимаем на нее правой кнопкой мыши и нажимаем на пункт меню "Извлечь все". 

Система спросит путь, если ничего не трогать то распакуется прямо сюда

Если так получилось, что Ваш компьютер не обновлялся последние лет 5, и это не Mac, то у вас все еще есть шансы получить более-менее комфортную среду разработки.

С учетом того, что типовой проект на Flutter это где-то 20 тысяч файлов, то наиболее важным улучшением рабочей машины будет приобретение хотя бы дешевенького SSD. Опять же, 4 гигабайта ОЗУ - это однозначное использование файла подкачки, который, опять же, на жестком диске.

Традиционная Windows здесь противопоказана как минимум по трем причинам:

1. Она постоянно чем-то занята в фоне

2. В ней практически невозможно отключить антивирус, который в нашем случае бесполезен

3. Сама по себе винда сжирает почти два гига оперативки, половину от того что имеем

Выход тут один: ставим линукс. Его очень легко поставить рядом с Windows, вы не заметите никаких дополнительных тормозов и ограничений (кроме того, что для установки Linux "откусит" часть диска). Я далее покажу, как это делается.

Я протестировал несколько максимально "легких" дистрибутивов, оценивая в том числе комфорт для людей, которые до этого видели только винду.

Мой выбор пал на Manjaro XFCE Desktop (https://manjaro.org/download/), который сочетает в себе простоту установки, легкость использования и максимальную скорость работы.

Android Studio с запущенным начальным проектом на смартфоне "скушал" 2,1 гигабайта оперативки. Это не рекорд, но комфортная работа уже реальна.
Тем не менее, что вас ждет при использовании Linux на системе с 4Gb RAM и HDD:

1. первая компиляция проекта - около 30 минут. Потом все будет быстро

2. нельзя пользоваться эмулятором - только реальный смартфон на базе Android

3. браузер - Midori, так как Firefox/Chrome/Yandex заклинят ваш компьютер лучше ручного тормоза

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

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

Для старта я установил чистую Windows на свой MacBook второй системой, и мы постараемся в ходе установки описать все потенциальные проблемы.

Начинаем с того, что переходим на сайт https://flutter.dev/ и нажимаем на кнопку Get Started справа вверху