Чтобы получить доступ к пользовательским данным или сенсорам, разработчику приходится работать с механизмом разрешений (permissions): пользователь должен выдать приложению право на использование соответствующего ресурса. Однако наличие
Permission не гарантирует, что приложение действительно сможет получить эти данные.Например, приложению выдали доступ к геолокации, и формально оно имеет право узнать, где находится пользователь. Но при запросе локации приложение получает null. Почему?
Здесь и появляется понятие
Ability — фактическая возможность получить данные в текущий момент времени. И она может отсутствовать даже при наличии разрешения.Причин может быть множество:
👉 пользователь отключил геолокацию через быстрые настройки;
👉 система временно приостановила доступ (например, в режиме энергосбережения);
👉 прошивка вендора ограничила работу сенсора;
👉 администратор устройства запретил доступ к геолокации;
👉 отсутствует физический сигнал (GPS недоступен, нет сети и т.д.).
Итог:
Permission — это юридическое право, Ability — это реальная техническая возможность.С точки зрения архитектуры, наличие permission не должно рассматриваться как гарантия наличия данных. Бизнес-логика и use case’ы должны быть спроектированы так, чтобы корректно работать в ситуации отсутствия ability.
Другими словами: приложение должно быть готово к тому, что внешний мир в любой момент может стать недоступным — даже если формально все разрешения выданы. Это означает:
1️⃣ отсутствие жёстких предположений о доступности данных;
2️⃣ обработку null, ошибок и таймаутов как нормального сценария;
3️⃣ явное моделирование состояний «данные недоступны» в доменной модели.
Permission — это контракт с пользователем. Ability — это контракт с реальностью. И именно второй чаще всего нарушается.#AndroidDev #AndroidOS #Архитектура