getApplication () против getApplicationContext()
Я не мог найти удовлетворительного ответа на это, так что вот мы идем: в чем дело с Activity/Service.getApplication()
и Context.getApplicationContext()
?
в нашем приложении оба возвращают один и тот же объект. В ActivityTestCase
однако, издевательство над приложением сделает getApplication()
вернись с макетом, но getApplicationContext
все равно вернет другой экземпляр контекста (один, введенный Android). Это жучок? Это нарочно?
Я даже не понимаю разницу в первую очередь. Есть дела за пределами Test suite, где оба вызова могут возвращаться с разными объектами? Когда и почему? Более того, почему getApplication
определен Activity
и Service
, а не Context
? Разве не всегда должен быть допустимый экземпляр приложения, доступный из в любом месте?
4 ответов
очень интересный вопрос. Я думаю, что это в основном семантическое значение, а также может быть связано с историческими причинами.
хотя в текущей деятельности Android и реализации услуг,getApplication()
и getApplicationContext()
верните тот же объект, нет никакой гарантии, что это всегда будет так (например, в конкретной реализации поставщика).
поэтому, если вы хотите, чтобы класс приложения, который вы зарегистрировали в Манифесте, вы должны никогда вызов getApplicationContext()
и приведите его в свое приложение, потому что это может быть не экземпляр приложения (который вы, очевидно, испытали с тестовой платформой).
почему ?
getApplication()
доступно только в классе Activity и классе Service, тогда как getApplicationContext()
объявляется в классе Context.
это на самом деле означает одно : при написании кода в широковещательном приемнике, который не является контекстом, но задается контекстом в его onReceive метод, вы можете вызвать только getApplicationContext()
. Это также означает, что вам не гарантируется доступ к вашему приложению в BroadcastReceiver.
при просмотре кода Android вы видите, что при подключении активность получает базовый контекст и приложение, и это разные параметры. getApplicationContext()
делегирует это вызов baseContext.getApplicationContext()
.
еще одна вещь: в документации говорится, что в большинстве случаев вам не нужно подкласс приложения:
обычно нет необходимости в подклассе
Application
. В большинстве ситуаций, статические singletons могут обеспечить такую же функциональность в более модульном путь. Если ваш синглтон нуждается в глобальном контексте (например, для регистрации широковещательные приемники), функция, чтобы получить его можно датьContext
внутри которой используетсяContext.getApplicationContext()
когда сначала построим синглтон.
я знаю, что это не точный и точный ответ, но все же, делает это ответить на твой вопрос?
сравнить getApplication()
и getApplicationContext()
.
getApplication
возвращает Application
объект, который позволит вам управлять глобальным состоянием приложения и реагировать на некоторые ситуации устройства, такие как onLowMemory()
и onConfigurationChanged()
.
getApplicationContext
возвращает глобальный контекст приложения-отличие от других контекстов заключается в том, что, например, контекст действия может быть уничтожен (или иным образом недоступно) Android, когда ваша деятельность заканчивается. Контекст приложения остается доступным все время, пока существует объект приложения (который не привязан к определенному Activity
), поэтому вы можете использовать такие вещи, как уведомления которые требуют контекста, который будет доступен в течение более длительных периодов и не зависит от переходных объектов пользовательского интерфейса.
Я думаю, это зависит от того, что делает ваш код, могут ли они быть или не могут быть одинаковыми - хотя в обычном использовании я ожидал бы их быть иными.
кажется, в контексте упаковки. Большинство классов, производных от Context
на самом деле ContextWrapper
, который по существу делегирует другой контекст, возможно, с изменениями оболочкой.
контекст-это общая абстракция, которая поддерживает издевательство и проксирование. Поскольку многие контексты привязаны к объекту с ограниченным временем жизни, такому как Activity
, должен быть способ получить более длительный контекст для целей например, регистрация будущих уведомлений. Это достигается Context.getApplicationContext()
. Логической реализацией является возврат global Application
object, но ничто не мешает реализации контекста возвращать оболочку или прокси с подходящим временем жизни.
деятельность и услуги, более конкретно связанные с Application
чтобы ответить на вопрос, getApplication() возвращает объект приложения, а getApplicationContext() возвращает объект контекста. Основываясь на ваших собственных наблюдениях, я бы предположил, что контекст обоих идентичен (т. е. за кулисами класс приложения вызывает последнюю функцию для заполнения контекстной части базового класса или происходит какое-то эквивалентное действие). На самом деле не имеет значения, какую функцию вы вызываете, если вам просто нужен контекст.