getApplication () і getApplicationContext ()

Я не міг знайти задовільну відповідь на цей питання , так що тут ми йдемо: то , що угода з Activity/Service.getApplication()і Context.getApplicationContext()?

У нашому додатку обидва повертають один і той же об’єкт. В одному , ActivityTestCaseпроте, глузливий додаток зробить getApplication()повернутися з знущатися, але по- getApplicationContext, як і раніше буде повертати інший контекст примірника (один впорскується Android). Це помилка? Це цілеспрямовано?

Я навіть не розумію різниці в першу чергу. Чи є випадки поза тестовим набором, коли обидва дзвінки можуть повертатися з різними об'єктами? Коли і чому? Крім того, чому getApplicationвизначено на Activityі Service, але не на Context? Чи не завжди має бути дійсний примірник програми, доступний з будь-якого місця ?

Дуже цікаве запитання. Я думаю, що це в основному смислове значення, а також може бути пов'язано з історичними причинами.

Незважаючи на те, що в поточних реалізаціях Android Activity і Service getApplication()і getApplicationContext()повертається той самий об’єкт, немає гарантії, що так буде завжди (наприклад, у конкретній реалізації постачальника).

Отже, якщо ви хочете, щоб клас Application, який ви зареєстрували в Manifest, ніколи не повинен дзвонити getApplicationContext()і передавати його своїй програмі, тому що це може бути не екземпляр програми (що, очевидно, ви мали досвід тестових рамок).

Чому getApplicationContext()існує в першу чергу?

getApplication()доступний лише у класі активності та у службовому класі, тоді getApplicationContext()як оголошується у класі контексту.

Це насправді означає одне: коли ви пишете код у широкомовному приймачі, який не є контекстом, а надається контекстом у його методі onReceive, ви можете лише зателефонувати getApplicationContext(). Це також означає, що вам не гарантується доступ до вашої програми в BroadcastReceiver.

Переглядаючи код Android, ви бачите, що при вкладенні активність отримує базовий контекст і додаток, і це різні параметри. getApplicationContext()делегатів, на які він закликає baseContext.getApplicationContext().

І ще одне: документація говорить про те, що в більшості випадків вам не потрібно підкласифікувати додаток:

Зазвичай не потрібно підклас Application. У більшості випадків статичні одинаки можуть надавати однакові функціональні можливості більш модульним способом. Якщо вашому синглтону потрібен глобальний контекст (наприклад, для реєстрації приймачів широкомовної передачі), функція його отримання може бути надана функцією, Contextяка використовується внутрішньо Context.getApplicationContext()при першому конструюванні сингтона.

Я знаю, що це не точна і точна відповідь, але все-таки це відповідає на ваше запитання?

Порівняйте getApplication()і getApplicationContext().

getApplicationповертає Applicationоб’єкт, який дозволить вам керувати своїм глобальним станом програми та реагувати на деякі ситуації на пристрої, такі як onLowMemory()і onConfigurationChanged().

getApplicationContextповертає глобальний контекст програми - відмінність від інших контекстів полягає в тому, що, наприклад, Android може бути знищений (або іншим чином недоступний) Android, коли ваша діяльність закінчиться. Контекст програми залишається доступним весь час, поки існує ваш об’єкт Application (який не прив'язаний до конкретного Activity), тому ви можете використовувати це для речей, як сповіщення, для яких потрібен контекст, який буде доступний протягом більш тривалого періоду та незалежно від перехідних об'єктів інтерфейсу.

Я думаю, це залежить від того, що робить ваш код, чи вони можуть бути, чи не можуть бути однаковими, хоча я б при звичайному використанні очікував, що вони будуть різними.

Здається, це стосується обговорення контексту. Більшість класів, похідних від Contextнасправді, є a ContextWrapper, який по суті делегує іншому контексту, можливо, із змінами, яку обгортає.

Контекст - це загальна абстракція, яка підтримує глузування та наближення. Оскільки багато контекстів пов'язані з об'єктом з обмеженим терміном експлуатації, таким як, наприклад, an Activity, існує необхідний спосіб отримати контекст з тривалістю життя для таких цілей, як реєстрація для майбутніх сповіщень. Це досягається шляхом Context.getApplicationContext(). Логічна реалізація полягає у поверненні глобального Applicationоб'єкта, але ніщо не перешкоджає реалізації контексту повернення обгортки або проксі-сервера з відповідним терміном експлуатації.

Діяльність та послуги більш конкретно пов'язані з Applicationоб’єктом. Корисність цього, я вважаю, полягає в тому, що ви можете створити і зареєструвати в маніфесті користувацький клас, похідний від Applicationі бути впевненим, що Activity.getApplication()або Service.getApplication()поверне той конкретний об'єкт того конкретного типу, який ви можете передавати вашому похідному Applicationкласу і використовувати для будь-якого спеціальна мета.

Іншими словами, getApplication()гарантовано повернути Applicationоб’єкт, тоді getApplicationContext()як вільний повернути проксі натомість.

Щоб відповісти на питання, getApplication () повертає об’єкт Application, а getApplicationContext () повертає об'єкт Context. Виходячи з ваших власних спостережень, я вважаю, що контекст обох є однаковим (тобто поза кадром клас Application викликає останню функцію для заповнення частини контексту базового класу або відбувається якесь еквівалентне дію). Насправді не має значення, яку функцію ви викликаєте, якщо вам просто потрібен контекст.