Android-разработка: XML-макеты или современный декларативный подход?
В современном мире Android-разработки мы оказались на перекрестке двух разных философий создания интерфейса. С одной стороны — проверенный временем XML, с другой — стремительно набирающий популярность декларативный подход (Jetpack Compose). Что выбрать в 2024 году? Давайте разберем плюсы и минусы обоих методов.
Долгое время XML был единственным стандартом. Вы описываете структуру экрана в одном файле, а затем «оживляете» её в Kotlin/Java коде через findViewById или View Binding.
Плюсы:
Минусы:
Классический путь: XML-макеты (Imperative UI)
Долгое время XML был единственным стандартом. Вы описываете структуру экрана в одном файле, а затем «оживляете» её в Kotlin/Java коде через findViewById или View Binding.
Плюсы:
- Разделение ответственности: Дизайн (XML) отделен от логики (Kotlin).
- Предсказуемость: Огромное количество документации, библиотек и готовых решений.
- Визуальный редактор: Возможность видеть структуру дерева элементов в режиме Preview.
Минусы:
- Избыточность: Чтобы изменить одну кнопку, вам нужно создать XML, найти её в коде, привязать слушатель и обновить состояние.
- Сложность иерархии: Глубокая вложенность
LinearLayoutиRelativeLayoutчасто приводит к падению
- Жалоба
Уведомления в Android: Как они устроены на самом деле
Если вы когда-нибудь писали мессенджер или любое приложение, которому нужно сообщать пользователю о новых событиях, вы рано или поздно сталкиваетесь с тем, что уведомления в Android — это не «показать текст в шторке», а целая система с собственными правилами. В этой статье я разберу, как уведомления устроены внутри, почему идентификация пушей — это отдельная инженерная задача, и какие решения здесь работают надёжнее всего. Материал не привязан к конкретному проекту, но примеры будут на Kotlin.
Каждое уведомление в шторке — это объект с двумя ключами: тегом (строка, необязательная) и ID (целое число, обязательное). Именно пара «тег — ID» определяет уникальность. Это значит, что два уведомления с одинаковым ID, но разными тегами, спокойно сосуществуют, а два уведомления с одинаковой парой заменяют друг друга.
Это первое место, где начинающие разработчики теряются. Типичный сценарий: приложение шлёт уведомления о новых сообщениях, и разработчик генерирует для...
Атомарность уведомления
Каждое уведомление в шторке — это объект с двумя ключами: тегом (строка, необязательная) и ID (целое число, обязательное). Именно пара «тег — ID» определяет уникальность. Это значит, что два уведомления с одинаковым ID, но разными тегами, спокойно сосуществуют, а два уведомления с одинаковой парой заменяют друг друга.
Это первое место, где начинающие разработчики теряются. Типичный сценарий: приложение шлёт уведомления о новых сообщениях, и разработчик генерирует для...
Хранение ID пользователя в памяти устройства
Решение о хранении ID пользователя на устройстве зависит от контекста и требований к безопасности:
- Плюсы: Хранение ID может упростить аутентификацию и улучшить пользовательский опыт, так как не потребуется каждый раз вводить логин/пароль.
- Риски: Если ID будет скомпрометирован (например, при утечке данных или взломе устройства), это может привести к несанкционированному доступу к аккаунту пользователя. Особенно критично, если ID используется в качестве уникального идентификатора без дополнительных мер защиты.
- Альтернативы: Вместо хранения ID можно использовать токены или сессии с ограниченным сроком действия. Также можно реализовать двухфакторную аутентификацию или биометрическую проверку при каждом входе.
Рекомендации по повышению безопасности
- Используйте надёжные алгоритмы шифрования и безопасные ключи: Ключи должны генерироваться случайным образом и храниться в защищённом хранилище (например, Android Keystore).
- Ограничьте доступ к данным: Убедитесь, что к зашифрованным данным нет
Шифрование токена
Шифрование токена и его сохранение во внутреннем хранилище приложения повышает уровень безопасности данных по сравнению с хранением в открытом виде. Однако степень защиты зависит от ряда факторов, и нельзя однозначно утверждать, что это полностью обезопасит пользователя. Рассмотрим ключевые аспекты.
Если токен зашифрован надёжным алгоритмом (например, AES-256) и ключи шифрования хранятся безопасно (например, в Android Keystore), это значительно усложняет доступ к данным для злоумышленника. Внутреннее хранилище приложения по умолчанию приватно: другие приложения и пользователь не могут получить к нему доступ без root-прав или эксплойтов.
Однако важно учитывать:
О шифровании токена
Если токен зашифрован надёжным алгоритмом (например, AES-256) и ключи шифрования хранятся безопасно (например, в Android Keystore), это значительно усложняет доступ к данным для злоумышленника. Внутреннее хранилище приложения по умолчанию приватно: другие приложения и пользователь не могут получить к нему доступ без root-прав или эксплойтов.
Однако важно учитывать:
- Риск рутирования устройства: Если устройство рутировано, злоумышленник может получить доступ к файлам приложения, включая зашифрованные данные.
- Уязвимости в реализации шифрования: Ошибки в коде (например, использование слабого ключа или его небезопасное хранение) могут сделать шифрование неэффективным.
- Физическая
Реклама





