Перейти к содержимому
Лекции

Практика 2. Практическая работа 2. Классы приложений, платформы и паттерны

Раздел 1. Привязка к лекции 2 (классы приложений, подходы к разработке, паттерны MVC/MVP/MVVM). Работа аналитическая/проектная, без программирования.

Цели работы

  • Научиться классифицировать мобильные приложения по способу реализации, назначению и зависимости от сети.
  • Научиться сравнивать нативный, кроссплатформенный, гибридный подходы и PWA по ключевым критериям.
  • Освоить выбор оптимального подхода к разработке под конкретный продукт с обоснованием.
  • Разобраться в различиях презентационных паттернов MVC, MVP и MVVM и в организации потока данных в каждом из них.

Задания

Задание 1. Сравнительная таблица подходов к разработке

Заполните таблицу по четырём подходам. Для каждого укажите язык/стек, производительность, доступ к нативным API, относительную стоимость и 1–2 примера реальных приложений.

КритерийНативныеКроссплатформенныеГибридныеPWA
Язык / стекSwift, Kotlin/JavaJS/TS (React Native), Dart (Flutter)HTML/CSS/JS + WebView (Cordova, Capacitor, Ionic)HTML/CSS/JS + Service Worker
Кодовых баз2 (iOS + Android)111
ПроизводительностьМаксимальнаяБлизкая к нативнойСредняяСредняя / низкая
Доступ к API и сенсорамПолныйШирокий (через мосты)Ограниченный (через плагины)Ограниченный (особенно iOS)
Качество UXЭталонноеВысокоеСреднее, «не родной»Зависит от браузера
Скорость разработкиНизкаяВысокаяОчень высокаяОчень высокая
СтоимостьВысокаяСредняяНизкаяНизкая
ДистрибуцияМагазиныМагазиныМагазиныБраузер / ссылка
ПримерыИгры на Unreal/Metal, банк-клиент с биометриейInstagram, Discord (RN); банковские и e-commerce приложения (Flutter)ранние Ionic-приложения каталоговTwitter Lite, Telegram Web

Вывод (2–3 предложения): какой подход даёт лучший баланс «цена/качество» для типичного бизнес-продукта и почему.

Задание 2. Классификация приложений

Для каждого из приложений определите: (а) назначение по классификации лекции; (б) тип по зависимости от сети (онлайн / офлайн / гибридный); (в) краткое обоснование.

ПриложениеНазначениеТип по сетиОбоснование
YouTubeРазвлекательное / медиаОнлайнВидео-стриминг с сервера, без сети неработоспособно
КалькуляторУтилитаОфлайнВсе вычисления локальны, сеть не нужна
TelegramСоцсети / коммуникацииГибридныйЛокальный кэш сообщений + синхронизация с сервером
Google MapsУтилита / навигацияГибридныйРаботает с кэшем карт офлайн, маршруты — онлайн
Сбербанк ОнлайнБизнес / банковский клиентОнлайнОперации требуют связи с сервером и авторизации
DuolingoОбразовательноеГибридныйУроки можно скачать офлайн, прогресс синхронизируется

Заполните таблицу самостоятельно (значения выше — образец); при желании замените 1–2 строки своими примерами.

Задание 3. Выбор подхода для одного приложения

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

В обосновании раскройте:

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

Пример вывода: для учебного сервиса типа Duolingo оптимален кроссплатформенный подход (React Native/Flutter) — одна кодовая база под iOS и Android при ограниченном бюджете, высокая скорость разработки, нет тяжёлой графики и экзотических сенсоров. Нативный путь избыточно дорог (две команды), гибрид/PWA проигрывают в плавности UX и в работе офлайн.

Задание 4. Схемы потоков данных MVC, MVP и MVVM

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

MVC (Model–View–Controller)

Пользователь ──ввод──> View ──> Controller ──обновляет──> Model
                         ^                                   │
                         └──────── обновление View ──────────┘
  • Model — данные и бизнес-логика. Controller — принимает ввод, меняет Model, выбирает View. View — отображение.
  • Связь View ↔ логика прямая; View активна. Риск «Massive View Controller».

MVP (Model–View–Presenter)

Пользователь ──событие──> View ──> Presenter ──> Model
                           ^           │
                           └─через интерфейс─┘ (обновление View)
  • View пассивна (только отображает и шлёт события). Presenter содержит всю логику представления и обновляет View через интерфейс.
  • Связь через абстракцию → высокая тестируемость.

MVVM (Model–View–ViewModel)

View  <──data binding──>  ViewModel  ──>  Model
(декларативный UI)      (состояние,
                         команды)
  • ViewModel хранит состояние и команды, не знает о конкретной View. Связь через двустороннюю привязку данных: изменения состояния автоматически отражаются в UI.
  • Реактивная View. Естественен для SwiftUI, Jetpack Compose, React/React Native.

Ключевые отличия: третий компонент (Controller / Presenter / ViewModel); способ связи View с логикой (прямая / через интерфейс / привязка данных); знает ли логика о конкретной View (да / да через интерфейс / нет).

Критерии оценки

КритерийВес
Задание 1: полнота и корректность сравнительной таблицы, вывод25%
Задание 2: верная классификация всех приложений с обоснованием25%
Задание 3: обоснованность выбора подхода, разбор альтернатив25%
Задание 4: корректные схемы потоков данных и формулировка отличий20%
Оформление, аккуратность, терминология5%

Вопросы для самопроверки

  1. Чем кроссплатформенный подход отличается от гибридного и от PWA?
  2. Может ли одно приложение относиться сразу к нескольким классам? Приведите пример.
  3. Как зависимость от сети влияет на проектирование (кэш, синхронизация, обработка обрывов)?
  4. Почему в MVVM View не знает о Model напрямую и в чём роль привязки данных?
  5. В каком паттерне View максимально «глупая» и почему это повышает тестируемость?

Ресурсы