Нарисованная “крупными мазками” UML диаграмма классов для наследников Context-а (из Android API) выглядит следующим образом:
Важно! На этой диаграмме отображены только некоторые классы, которые являются (is) Context-ом. Методы также приведены в сокращенном количестве, чтобы упростить восприятие картины в целом.
Сразу хочу заметить, что я не являюсь апологетом андроидного пути в архитектуре и дизайне, но поскольку многим программистам волей-неволей приходиться разрабатывать приложения под Android, то считаю нужным как минимум описать некоторые догмы этой архитектуры.
Context
Легко видеть, что Context (контекст) – это “священная корова” в Android API. Эта сущность занимает центральное место в иерархии классов.
Из контекста получаются различные объекты для работы с сетью, навигаторы, вибраторы, сенсоры и другие объекты, полезные в жизни прикладного программиста. Через контекст достают строчки, файлы, запускают сервисы и активити. Как правило, если вам что-то понадобилось, то посмотрите в контексте – может повезет и это там есть.
Специально искать контекст не приходится поскольку:
во-первых от контекста наследуются: Service extends ContextWrapper
во-вторых его агрегируют: dialog.getContext()
в-третьих передают как аргумент: public void onUpdate(Context context, ….. ) { } )
ContextWrapper
Контекст, как всякое высшее создание, есть чистая абстракций. Для того, чтобы с ним можно было работать в иерархии классов есть наследник-обертка – ContextWrapper.
У этого контекста-обертки есть три наследника: Application, Activity (не напрямую, а через ContextThemeWrapper) и Service. Вот такое вот триединство.
В сокращенном виде все выглядит следующим образом:
abstract class Context {...}
class ContextWrapper extends Context {.. }
class ContextThemeWrapper extends ContextWrapper {...}
class Activity extends ContextThemeWrapper {...}
class Application extends ContextWrapper {...}
class Service extends ContextWrapper {...}
Application, Activity и Service
Application – основной класс для приложения. Что-то вроде глобального контекста. Многие программисты его никак не трогают, не наследуют и слабо взаимодействуют с ним.
Activity – видимая сторона приложения. Работа с кнопками, текстовыми полями и другими интерактивными объектами начинается здесь.
Service – невидимая сторона приложения. Нужен для фоновых задач, т.е. тех которые будет работать, если вы нажали кнопку назад или домой. Важно! Service – это НЕ процесс и НЕ нитка (Thread). Если нужна многопоточность, то реализовать придется самостоятельно уже внутри Service-а.
Наследники Activity
ListActivity – специально сделанный класс для работы со списком, на его базе сделали PreferenceActivity – для различных настроек.
ActivityGroup и TabActivity – уже устарели, на их смену пришли фрагменты, которые добавлены в иерархию классов минуя наследование (наконец-то).
MapActivity – для работы с картами. Поскольку сделать гугловые карты без MapActivity не получится, то это нужно учитывать при проектирование классов для своего приложения.
В конце кратко про пакеты:
- Context и ContextWrapper в android.content
- ContextThemeWrapper в android.view
- Application, Service, Activity, ListActivity, ActivityGroup, TabActivity в android.app
- PreferenceActivity в android.preference
Полезные ссылки
- Android API http://developer.android.com/reference/packages.html
- UML диаграмма класса нарисована с помощью umlet-a.
- Вопрос про “Android API class diagram” на Stackoverflow: http://stackoverflow.com/questions/4761141/android-api-class-diagram.