Какие бывают мобильные приложения

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

Цель этой темы — научиться различать основные подходы, объяснять их возможности и ограничения. После изучения вы должны уметь описать путь от действия пользователя до результата, сравнить мобильный сайт, нативное приложение и PWA, а также объяснить, почему значок на экране не доказывает работу без интернета.

Приложение начинается с задачи

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

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

В разработке нужно различать три вещи. Задача описывает потребность человека. Интерфейс — способ взаимодействия с программой: экран, кнопки, поля, сообщения. Технология — средства реализации. Кнопка «Моя группа» относится к интерфейсу; необходимость быстро найти аудиторию — к задаче; использование браузера — к техническому решению.

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

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

Даже простой счётчик содержит несколько связанных частей:

1. Интерфейс показывает число и кнопку «Добавить».
2. Логика определяет, что происходит после нажатия: число увеличивается на единицу.
3. Данные хранят текущее значение.
4. Среда выполнения запускает программу и предоставляет ей необходимые возможности.

Эти части можно объяснить на бумаге. До нажатия значение равно 2. Пользователь нажимает кнопку. Программа применяет правило «прибавить 1». На экране появляется 3. При этом нажатие и изменение числа — разные события: кнопка сама по себе ничего не считает без заданного правила.

Состояние — сведения о текущем положении приложения. Для счётчика это число; для расписания — выбранная группа и дата; для формы — введённые значения. Обновление экрана отражает изменение состояния, но не обязательно означает сохранение результата на будущее.

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

Платформа в нашем обсуждении — среда с определёнными правилами выполнения приложений. Android и iOS предоставляют приложениям системные возможности. Браузер выполняет веб-интерфейсы и предоставляет веб-возможности. Версия системы, браузера и характеристики устройства могут влиять на поведение программы.

Где находятся данные: телефон и сервер

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

Для расписания возможна следующая цепочка:

Студент выбирает группу
        ↓
Приложение запрашивает расписание
        ↓
Сервер возвращает данные
        ↓
Приложение показывает занятия

Сервер не обязательно нужен для каждого нажатия. Фильтрацию уже загруженного расписания можно выполнить на телефоне. Личный счётчик тоже может считать локально. Но получить новое изменение аудитории с сервера при отсутствии связи нельзя.

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

Ошибка сети не должна превращаться в пустой непонятный экран. Понятное поведение: «Связи нет. Показано расписание, сохранённое вчера в 18:00». Время здесь — учебный пример, а не сведения о реальном расписании колледжа.

Нативное приложение

Нативное приложение создают с использованием средств конкретной платформы. Для Android и iOS существуют свои инструменты и правила разработки. Готовая программа устанавливается на устройство; её запуском управляет операционная система.

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

Разрешение — согласие на доступ к определённой возможности или данным. Если программа просит камеру, пользователь может отказать. Тогда нужно объяснить, какая функция недоступна, и по возможности предложить другой путь. Нельзя считать отказ неожиданной поломкой пользователя: это обычный вариант работы.

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

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

Цена нативного подхода — освоение инструментов платформы, сборка, установка и проверка на устройствах. Если нужны разные платформы, следует отдельно продумать разработку и тестирование для каждой. Общая идея продукта может быть одной, но конкретные системные возможности не обязаны совпадать.

Мобильный сайт и веб-приложение

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

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

В веб-интерфейсе обычно используют три дополняющих друг друга средства:

• HTML описывает структуру: заголовок, список занятий, кнопку.
• CSS определяет оформление: размер текста, цвет, расположение, адаптацию к экрану.
• JavaScript задаёт поведение: реакцию на нажатие, выбор группы, пересчёт результата.

JavaScript и Java — разные языки. Похожее название не означает взаимозаменяемость. Подробное программирование на этих средствах будет позже; сейчас достаточно понять разделение их ролей.

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

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

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

PWA: веб-приложение с дополнительными возможностями

PWA — Progressive Web App, прогрессивное веб-приложение. Оно сохраняет веб-основу, а в поддерживаемой среде может запускаться с экрана устройства как отдельное приложение. Важно различать три задачи: оформление установки, сохранение данных и автономную работу.

Для управляемой установки применяется манифест — файл с описанием имени, значков и параметров запуска. Возможность установки и её интерфейс зависят от браузера и платформы. Для соответствующего сценария нужны HTTPS или среда разработки localhost. Локальный HTML, открытый с флешки, может показывать интерфейс, но сам по себе этим не становится устанавливаемой PWA. Некоторые браузеры позволяют создать приложение или ярлык и для обычного сайта. Поэтому одного значка недостаточно для технической классификации. MDN: установка PWA.

Для выбранного автономного сценария часто используют service worker: компонент, позволяющий организовать обработку запросов и получение заранее сохранённых ресурсов. Разработчик определяет, что доступно без сети и как обновляется. Установка и автономность — отдельные свойства; service worker не является универсальным требованием установки. MDN: автономная работа.

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

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

PWA не превращает веб-код автоматически в нативную программу и не снимает ограничения браузера. Для курса её ценность в том, что один веб-проект можно постепенно развивать: сначала сделать работающую страницу, затем добавить подходящие возможности установки и автономности.

Гибридный и кроссплатформенный подходы

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

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

Общий код сокращает некоторые повторения, но не отменяет проверки Android и iOS отдельно. Например, разрешения, клавиатура, размеры экрана и поведение кнопки возврата могут отличаться. Формулировка «написали один раз — работает везде без проверки» неверна.

Визуальное программирование — ещё одно измерение: способ задания логики, например блоками вместо набора текста. Оно не определяет автоматически способ распространения программы. Конструктор может создавать устанавливаемое приложение. Поэтому нельзя ставить «блоки» и «нативное приложение» в один ряд как взаимоисключающие типы.

Сравнение на одном продукте

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

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

Три разобранных примера

Расписание по ссылке

Требование: любой студент открывает адрес и видит актуальную таблицу. Начальный вариант — мобильный сайт. Это позволяет проверить полезность интерфейса до усложнения установки. Если позже требуется просмотр сохранённой таблицы без связи и запуск с экрана, можно рассмотреть PWA.

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

Личный счётчик привычки

Требование: нажатие увеличивает число; результат сохраняется после закрытия; сеть для этого не нужна. Веб-вариант с подходящим локальным хранением может быть достаточен. Нативный вариант тоже возможен. Из условий пока не следует единственный обязательный подход.

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

Съёмка и обработка фотографии

Требование «работать с фотографией» слишком широкое. Выбор готового изображения и сложная съёмка с особыми настройками камеры — разные задачи. Сначала уточняют операции, затем проверяют возможности выбранной среды. Для тесной интеграции с платформой можно рассматривать нативный подход, но нельзя объявлять любой фото-сценарий невозможным в вебе.

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

Задания и проверка понимания

1. В расписании студент выбрал группу, но после перезапуска выбор исчез. Какая часть поведения не предусмотрена?
2. На экране телефона появился значок сайта. Можно ли по этому признаку утверждать, что приложение нативное и работает без сети?
3. В автономном приложении открывается экран расписания, но занятия не показываются. Назовите возможную причину.
4. Выберите начальный подход для расписания по ссылке. Какие новые требования заставят пересмотреть решение?
5. Счётчик должен сохранять результат и работать без связи. Докажите, почему только слова «нативное» или «PWA» ещё не гарантируют выполнение задачи.
6. Нарисуйте цепочку работы расписания и отметьте, какие действия могут выполняться локально, а какие требуют свежих данных сервера.

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

Итог

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

К следующей теме подготовьте пример приложения или сайта, которым пользуетесь. Опишите задачу, одно действие и одно ограничение. Если внутреннее устройство неизвестно, так и укажите: предположение по виду интерфейса не становится подтверждённым фактом.