Из чего состоит приложение андроид

Из каких базовых компонент состоит приложение?

Базовые компоненты андроид приложения: Activity, Service, BroadcastReceiver, ContentProvider. Каждый из базовых компонент объявляется в андроид манифесте и может являться точкой входа в приложение.

Activity представляет UI и функциональность, видимые пользователю.

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

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

ContentProvider используется для обмена данными с другими приложениями.

Каждый из компонентов подробнее рассмотрим в будущем.

Архитектура Android-приложений. Часть III — основные части приложения

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

В этой статье будут представлены основные «персонажи» архитектуры Android-приложения.

В общем случае, Android-приложение состоит из:

• Java-классов, являющихся подклассами основных классов из Android SDK (View, Activity, ContentProvider, Service, BroadcastReciever, Intent) и Java-классов, у которых нет родителей в Android SDK.
• Манифеста приложения
• Ресурсов наподобие строк, изображений и т.п.
• Файлов

Java классы

На следующей диаграмме представлена иерархия основных классов из Android SDK, с которыми предстоит иметь дело разработчику:

На самом деле классов намного больше, но это основные. Выделенные жёлтым — те, с которыми разработчик работает непосредственно (в частности, наследуются от них). Остальные так же важны, но они реже используются напрямую.

View — базовый класс для всех виджетов пользовательского интерфейса (GUI widgets). Интерфейс Android-приложения представляет собой дерево экземпляров наследников этого класса. Можно создать это дерево программно, но это неправильно. Пользовательский интерфейс определяется с помощью XML (файлы слоёв, layout files), а во время исполнения автоматически превращается (inflate, термин Android) в дерево соответствующих объектов.

Класс Activity и его подклассы содержат логику, лежащую за пользовательским интерфейсом. При ближайшем рассмотрении этот класс соответствует ViewModel в архитектурном шаблоне Model-View-ViewModel (MVVM). Отношение между подклассом Activity и пользовательским интерфейсом — это отношение один к одному; обычно каждый подкласс Activity имеет только один связанный с ним слой пользовательского интерфейса, и наоборот. Activity имеет жизненный цикл.

В течении жизненного цикла Activity может находиться в одном из трёх состояний:

• Активно и выполняется — этот пользовательский интерфейс находится на переднем плане (говоря технически — на вершине стека активити)
• Приостановлено — если данный интерфейс пользователя потерял фокус, но всё ещё видим. В таком состоянии никакой код не выполняется.
• Завершено — если интерфейс пользователя невидим. В таком состоянии код не выполняется.

Класс ContentProvider и его подклассы представляют model в архитектуре MVVM. В большинстве практических случаев это обёртка над базой данных SQLite с немного причудливым способом доступа на основе URI. Теоретически, никто не мешает разработчику создать ContentProvider на основе чего-то ещё, кроме базы данных. Тем не менее, существующий метод query() контент-провайдера возвращает объект Cursor, который крайне похож на JDBC ResultSet интерфейсом и тем, как он работает. Поэтому вряд ли кто-то усомнится, что настоящее назначение контент-провайдеров — инкапсулировать базу данных.

Я не знаю, как комманда Android пришла к такому дизайну, но, по-моему, здесь соединены две хороших, но не слишком совместимых идеи.

И вот почему я так считаю. Основная идея контент-провайдеров, похоже, базируется на архитектуре AJAX приложений. AJAX приложения обычно используют архитектуру MVVM, где модель представлена как URI на стороне сервера (тем не менее, это изменилось с поялвинем HTML5, который позволяет хранить данные локально). В самом деле, тот факт, что контент-провайдеры запрашиваются с помощью URI и создают расширение с помощью типов MIME указывает на то, что в основе лежит AJAX. Напомню, ребята из Google создали большое количество AJAX приложений, таких как Gmail, Google Docs и т.п., поэтому вполне естественно, что идеи заимствовались из архитектуры AJAX.

Возможно, кто-то ещё пришёл с ещё одной отличной идеей: как было бы здорово иметь полноценную реляционную базу на мобильном устройстве! (замечу, это было примерно в 2005 году, когда мобильные телефоны были намного слабее, чем сейчас). И, как результат, они соединили две хороших идеи в один класс ContentProvider. Как это обычно и случается в разработке ПО, соединение двух хороших идей не всегда даёт в результате хорошую идею; в случае Android мы имеем несколько обескураживающий дизайн контент-провайдеров.

Класс Service и его подклассы я затрудняюсь как-то классифицировать. Я думаю, ребята из Google испытывают те же трудности (прочтите, пожалуйста, их документацию). Их классификация, в основном, говорит, чем этот класс не является. Я лично думаю, что сервис — это разновидность Model, обслуживающая несколько иные варианты использования, нежели ContentProvider.

По-моему, архитектурный дизайн Android Service навеян сервисами OSGI.

Думаю, сервисы были созданы ребятами из Google как решение логической проблемы, возникшей из-за модели потоков Android.

Подумайте над этим: Activity активно и выполняется только когда его пользовательский интерфейс находится на переднем плане. Как только интерфейс другого Activity закрывает собой текущее, последнее останавливается, даже если оно что-то делало. А что, если вам нужно выполнять некую операцию, даже если процесс, которые её выполняет, не на переднем плане? С помощью Activity вы не сможете этого сделать. Вы не сможете это сделать и с помощью ContentProvider, поскольку у них нет собственного жизненного цикла, и они могут выполняться только пока Activity, использующее его, активно.

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

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

Как я уже упоминал, Service, как model, приследует более общие цели, нежели ContentProvier. Он может использовать базу данных, но его API не связано с БД, как в случае ContentProvider. В большинстве случаев сервисы используются для связи с внешними серверами.

Класс BroadcastReceiver и его подклассы представляют собой «подписчика» в механизме взаимодейтсвия издатель/подписчик, реализованном в архитектуре Android.

Мы уже говорили о механизмах взаимодействия в предыдущей статье.

Конечно, разработчик под Android не ограничен одним только расширением классов из Android SDK. Он может писать собственные классы так, как захочет. Но все они будут только хелперами («helper classes») для классов из Andoird SDK.

Манифест Android

Манифест Android — ещё одна важная часть Android-приложения. Идея была навеяна манифестами плагинов для Eclipse.

Манифест Android представляет собой XML файл и выполняет несколько функций. Вот как их описывает Google:

• Определяет имя Java-пакета приложения. Имя пакета представляет собой уникальный идентификатор для приложения.
• Описывает компоненты приложения — активити, сервисы, броадкаст-ресиверы и контент-провайдеры. Определяет имена классов, реализующие каждый из компонентов и оглашает их возможности (например, какие Intent-сообщения они могут обрабатывать). Эти объявления позволяют системе Android знать, какие компоненты и при каких условиях могут быть запущены.
• Предопределяет процессы, которые будут содержать компоненты приложения.
• Объявляет разрешения, которые приложение должно иметь для доступа к защищённым частям API и взаимодействия с другими приложениями.
• Также объявляет разрешения, которые требуются для доступа к компонентам приложения.
• Перечисляет классы Instrumentation, которые предоставляют профайлинг и другую информацию во время работы приложения. Эти объявления присутствуют в манифесте только пока приложение разрабатывается и тестируется; они удаляются перед публикацией приложения.
• Объявляет минимальный уровень Android API, который требует приложение.
• Перечисляет библиотеки, с которыми приложение должно быть связано.

Обратите внимание на второй пункт. Имеется ввиду, что если некий класс расширяет Activity, ContentProvider, BroadcastReceiver или Service в вашем приложении, этот класс не может быть использован до тех пор, пока он не описан в манифесте.

Ресурсы

Каждое современное GUI приложение в той или иной форме использует ресурсы. Android-приложения — не исключение. Они используют следующие типы ресурсов:

• Изображения
• Слои GUI (XML файлы)
• Объявления меню (XML файлы)
• Текстовые строки

Давайте рассмотрим следующий пример. Файл с именем mybutton.png содержит картинку для кнопки. Разработчик совершает ошибку и набирает mybuton.png, ссылаясь на ресурс из кода. Как итог, код пытается использовать несуществующий ресурс, но компиляция пройдёт успешно. Ошибка может быть обнаружена только в ходе тестирования (а может и не быть обнаружена вовсе).

Ребята из Google нашли элегантное решение этой проблемы. При сборке Android-приложения генерируется специальный Java-класс с именем R (всего лишь одна буква). Этот класс содержит несколько static final наборов данных. Каждый такой набор данных — ссылка на отдельный ресурс. Эти ссылки используются в коде приложения для связи с ресурсами. Теперь каждая ошибка в ссылке на ресурсы проявляет себя в процессе компиляции.

Файлы

Android-приложение использует несколько разных типов файлов:

• Файлы «общего назначения»
• Файлы БД
• Файлы Opaque Binary Blob (OBB) (они представляют собой зашифрованную файловую систему, которая может быть монтирована для приложения)
• Закешированные файлы

API для работы с файлами реализован классом Context, от которого порождены классы Activity и Service. Этот класс уже обсуждался нами здесь.

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

• Архитектура Android-приложений. Часть I — истоки
• Архитектура Android-приложений. Часть II — архитектурные стили и шаблоны

• android
• Vlad Nevzorov
• Влад Невзоров
• архитектура приложений
• архитектура Android-приложений

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

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

Анатолий Ализар

Пишет про разработку в Skillbox Media. Работал главным редактором сайта «Хабрахабр», ведёт корпоративные блоги.

Язык программирования для мобильной разработки на Android очень простой — это Java. Сейчас Google активно продвигает Kotlin как язык, который сможет заменить Java. Приложения пишут и на C++.

Создание простейшего приложения состоит из нескольких этапов:

• проект в Android Studio;
• создание пользовательского интерфейса;
• добавление активностей, навигации и действий;
• тест-драйв приложения в эмуляторе.

Необходимые инструменты

Первым делом установите программу Android Studio. Это официальная среда разработки (IDE) для Android, она работает на Windows, macOS и Linux. Хотя при разработке программ для Android можно использовать и другие среды, кроме Android Studio.

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

Android SDK компилирует код вместе с любыми данными и ресурсами в файл с расширением .apk. Он содержит всё необходимое для установки приложения на Android-устройство.

Полезно установить и эмулятор Android, чтобы запускать и тестировать приложения. Эмулятор поставляется в комплекте с Android Studio.

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

Из чего состоит приложение
на Android

Android-приложение состоит из четырёх компонентов. Каждый компонент — это точка входа, через которую система или пользователь может получить доступ.

• Активность(activity) — элементы интерактивного пользовательского интерфейса.
  Одна активность задействует другую и передаёт информацию о том, что намерен делать пользователь, через класс Intent (намерения). Активности подобны веб-страницам, а намерения — ссылкам между ними. Запуск приложения — это активность Main.
• Сервис(service) — универсальная точка входа для поддержания работы приложения в фоновом режиме.
  Этот компонент выполняет длительные операции или работу для удалённых процессов без визуального интерфейса.
• Широковещательный приемник (broadcast receiver) транслирует нескольким участникам намерения из приложения.

Теперь попробуем сделать своё приложение для Android.

Создаём Android-приложение
в Android Studio

Шаг 1

Выбираем название приложения, домен компании, путь к проекту и название пакета. Указываем, включить ли поддержку опциональных языков программирования C++ и Kotlin.

Шаг 2

Задаём одну или несколько целевых платформ для сборки. Для этого используется SDK и AVD, менеджер виртуальных устройств Android. Инструмент позволяет устанавливать в SDK пакеты, которые поддерживают несколько версий ОС Android и несколько уровней API (интерфейсов программирования приложений).

Справка

Чем ниже версия Android, тем больше устройств, на которых приложение запустится. Чем выше версия, тем богаче функциональность API.

Шаг 3

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

Шаг 4

После нескольких минут сборки Android Studio открывает интерфейс IDE. Здесь три основных момента.

Если выбрать в выпадающем меню вид Android, то вы увидите файлы проекта. Например, наша основная активность называется app > java > ru.skillbox.skillboxapp > FullscreenActivity. При создании проекта мы указали вместо активности Main полноэкранную активность.

Далее можно посмотреть файл app > res > layout > activity_fullscreen.xml. Это XML-файл с макетом для UI нашей основной активности.

Наконец, третий важный файл app > manifests > AndroidManifest.xml описывает фундаментальные характеристики приложения и определяет все его компоненты.

Содержимое манифеста

Создаём простой пользовательский интерфейс

Пользовательский интерфейс Android-приложения создаётся через иерархию макетов (layouts, объекты ViewGroup) и виджетов (объекты View). Макеты управляют расположением дочерних виджетов на экране. Сами виджеты — это непосредственно компоненты UI: кнопки, текстовые поля на экране и т.п.

Интерфейс активностей создаётся в Android Studio в редакторе макетов (Layout Editor) и хранится по большей части в XML-файлах.

• Открываем файл app > res > layout > activity_fullscreen.xml.
• Добавляем на экран из палитры (Palette) виджеты перетаскиванием мышью.
• Например, берём текстовое поле (PlainText). Это виджет EditText, куда пользователь может вводить текст.
• Добавляем кнопки и другие нужные элементы.

Добавляем действия, активности и навигацию

Предположим, мы создали активность с текстовым полем и кнопкой «Отправить». После этого нужно написать, что конкретно будет происходить при нажатии кнопки «Отправить».

• Заходим в код app > java > FullscreenActivity.
• Добавляем метод SendMessage() в класс FullscreenActivity, чтобы при нажатии на кнопку вызывался этот метод.
• Создаём намерения (класс Intent) для перехода от одной активности к другой, новые активности, навигацию и всё остальное, что необходимо для приложения.

И, конечно, начинаем мечтать, как монетизировать приложение.

Больше интересного про код в нашем телеграм-канале. Подписывайтесь!

Как создают мобильные приложения? Разбор

Сегодня мы углубимся в вопросы разработки приложений для разных мобильных операционных систем и снова попытаемся понять разницу между iOS и Android?

aka_opex 31 августа 2022 в 08:28

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

Разработчики при помощи кода, по сути, просто текста, заставляет очень глупое сознание — компьютер или смартфон совершать невероятные вещи. Угадывать наши музыкальные вкусы, отслеживать пульс, управлять умным домом и так далее. Поэтому сегодня мы узнаем, что стоит за этой магией.

Разберемся, что такое среда разработки? Узнаем, чем отличаются приложения под iOS и Android? Что лучше, нативные или кросс-платформенные приложения?
И зададим главные вопросы разработчику!

Где разрабатываются приложения?

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

IDE — Integrated development environment — интегрированная (или единая) среда разработки

Для Android такой средой разработки является Android Studio, а для iOS – Xcode.

Среда разработки – это просто программа, где есть всё что вам нужно для создания приложения. Тут есть:

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

Окей, двигаемся дальше.

На каких языках пишутся приложения?

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

Swift и Kotlin – это более современные и дружелюбные языки программирования. Эти языки очень похожи, вплоть до того, что некоторые участки кода могут совпадать на 70% и даже больше.

Вот пример функции которая на основе текущего дня и вида погоды создает сообщение о прогнозе.

Интересно, что Swift создан только для разработки под iOS. А вот на Kotlin можно писать под разные платформы, и под Windows, и под Linux, и даже под iOS. Думаю, это одна из причин радости разработчиков, когда Kotlin добавили в Android Studio. Это было на Google I/O в 2017 году.

Из чего состоят приложения?

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

Разберем на примере Android.

Тут все приложения состоят из четырёх основных компонентов, это:

1. Активность (activity)
2. Сервис (service)
3. Широковещательный приемник (broadcast receiver)
4. Поставщик содержимого (content provider)

Чтобы вас сильно не грузить, подробнее остановимся на двух из них: Активностях и сервисах.

Начнем с Активностей. По сути, это основной интерфейс приложения. Это пустое окно, в которое мы запихиваем текст, картинки, кнопки и прочие элементы интерфейса. Как правило, активность занимает полный экран, и по своей сути она похоже на веб-страницу.

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

Каждая Активность имеет свой жизненный цикл. Выглядит он вот так сложно:

Но если упростить, активность может находиться в одном из четырех состояний:

1. Запущена
2. На паузе
3. Остановлена
4. Уничтожена

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

Иными словами активность не может работать в фоне. Для этого в Андроиде существует другой компонент — сервис (service)

Сервисы — очень удобная штука. При помощи сервисов в Android очень легко можно реализовать любые фоновые задачи: воспроизведение музыки, скачивание файлов, навигацию и прочее, прочее.

Сложность только одна, можно сильно увлечься с фоновыми процессами и сожрать весь заряд аккумулятора.

iOS и фоновые задачи

А вот в iOS проблемы совсем иного рода. В качестве аналога Сервисов тут есть шутка, которая называется Background Task, то есть буквально фоновая задача.

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

Из плюсов: вряд ли какое-то приложение сожрет в фоне батарейку на вашем iPhone. Из минусов — вам придется постоянно тыкать в экран пока грузится видосик в Telegram.

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

Иными словами, разработка для iOS и Android очень похожа. Отсюда возникает вопрос, а можем ли мы написать одно приложение, которое будет работать и на iOS и Android? На самом деле можем, но с оговорками.

Когда перед разработчиком стоит задача погнаться сразу за двумя зайцами, то есть разработать приложение сразу под две ОС. У него есть три пути:

1. Использовать нативную разработку,
2. Использовать кросс-платформенную разработку
3. Использовать гибридную разработку.

Нативные, кросс-платформенные и гибридные разработки

Итак, нативная разработка — это самый прямолинейный, понятный, и при этом, наверное, самый затратный путь.

От англ. native — родной, естественный

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

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

Поэтому существует очень манящая идея кросс-платформенной разработки. Представляете, вы пишите один код, который работает на разных платформах. Звучит как настоящая мечта для заказчика. Нужно вдвое меньше разработчиков, вдвое меньше времени и, чисто теоретически, вдвое меньше бюджет. Более того есть масса инструментов, то есть фреймворков, которые позволяют это сделать: React Native, Flutter, Xamarin, Cordova, Ionic, Titanium Appcelerator, Vue Native.

Самые популярные — React Native и Flutter.

Естественно, каждый из таких фреймворков обещает, что их кросс-платформенное приложение будет ничем не хуже нативного, но на практике всё не так.

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

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

Но какой из этих подходов круче?

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

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

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

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

• Можно ли на этой технологии в принципе сделать тот набор фичей, который нужен продукту?
• Можно ли их отнести к стандартным фичам, которые известно как реализовывать? Насколько часто нам нужно выходить за пределы стандартных фичей? Насколько важен внешний вид приложения?
• Насколько критичны требования к производительности приложения? Предполагается ли, что оно должно делать какие-то тяжелые вычисления, обрабатывать большие объемы данных, рисовать сложный пользовательский интерфейс?
• Насколько критична скорость разработки, быстрота найма и стоимость работы разработчиков?
• Каков риск и насколько он критичен в случае, если владельцы технологии поменяют к ней отношение? Они могут снизить затраты или вообще остановить ее разработку, поменять лицензионную политику, ввести какие-то другие ограничения на ее пользователей.

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

Кросс-платформенный подход, например React-Native, тут может отлично сработать. Почему?

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

Какой подход использовался при разработке приложения «МойОфис Документы»?

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

Приложение “МойОфис Документы” можно разделить на две части:

1. Файловый менеджер (ФМ)
2. Редактор документов

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

Редакторы — совсем другая история. Их «сердцем» является общее ядро, написанное на C++. За счет этого мы получаем полную унификацию того, как выглядят и ведут себя редакторы на всех платформах на которых мы умеем работать. Цена этой унификации конкретно нашего приложения — необходимость работы с C++, языком который сложно назвать стандартным для мобильной разработки. Что интересно, из-за ядра мы вполне можем назвать наше приложение гибридным, т.к. в нем есть кросс-платформенная часть. Разница лишь в том, что в такой кросс-платформе код ядра работает даже быстрее, чем если бы он был написан на наших «нативных» Java и Kotlin.

Помимо ядра у нас есть нестандартные элементы интерфейса, которые так же критичны к производительности. Я люблю приводить в качестве примера логику рендеринга документов. Этот компонент состоит из двух частей: логика ядра, которая рисует содержимое документа в буфер и логика рисования этого буфера уже на экране. Почему так работает — отдельная история, но сейчас важно, что это позволяет нам находить баланс между скоростью рисования содержимого и эффективным потреблением памяти и CPU. (Тут нужно вставить видео в котором включен developer mode в рендеринге, добавит наглядности)

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

Под какую платформу сложнее программировать iOS или Android?

После совместных обсуждений мы пришли к выводу, что сложность именно в работе примерно одинакова. Обе системы сейчас стремительно движутся в общем направлении как по фичам, так и по подходам к разработке (kotlin ~ swift, ComposeUI ~ SwiftUI). Отличия, конечно, остаются, но они не такие значительные чтобы о них говорить в контексте “сложнее-проще”. Другой вопрос, что порог входа в iOS по прежнему выше, чем в Android: вам нужен мак и айфон для того чтобы начать.

А можно ли написать приложение вообще без кода?

На сегодняшний день, действительно, существуют технологии, которые позволяют создавать некоторый вид приложений буквально не написав ни строчки кода. Чтобы понять как это работает можно вернуться к предыдущей теме. На разработку удобнее смотреть не бинарно (нативное или кросс-платформенное), а как на непрерывный процесс поиска наиболее оптимального способа решать бизнес-задачи. Двигаясь от нативной к полностью кросс-платформенной разработке мы также двигаемся по пути абстрагирования от конкретных платформ и ОС к технологиям которые позволяют сфокусироваться только на бизнес-задачах. Зерокодинг — это пример крайнего положения на спектре разработки. Тут вас ждет огромное количество ограничений: внешний вид, потенциально реализуемые фичи, производительность, полная зависимость от конкретной компании. С другой стороны, вы получаете возможность запустить первую версию приложения буквально за выходные. А в некоторых случаях это может быть крайне важно.

Подписывайтесь на МойОфис ВКонтакте, будьте в курсе новостей разработки приложений.

Установить бесплатные редакторы для решения повседневных задач на домашнем компьютере или мобильном устройстве: ПК, Google Play Store, AppStore.