Есть ли шаблон проектирования, чтобы сократить дублирование кода при подклассовках в Android?

У меня есть общая задача, которую я делаю с некоторыми действиями – загрузка данных, а затем их отображение. У меня есть часть загрузки вниз погладить; Это, конечно, немного сложно из-за возможности изменения пользователем ориентации или отмены действия до завершения загрузки, но код есть. Существует достаточно кода, обрабатывающего эти случаи, так что я не хочу, чтобы он копировал / вставлял его в каждое действие, которое у меня было, поэтому я решил создать абстрактный объект подкласса, так что он обрабатывает одну фоновую загрузку, которая затем запускает метод Который заполняет страницу данными.

Все это работает. Проблема в том, что из-за единственного наследования я вынужден воссоздать тот же самый класс для любого другого типа Activity – например, я использую Activity, ListActivity и MapActivity. Для использования одного и того же метода для всех трех требуется три повторяющихся класса, за исключением того, что каждый из них расширяет другое действие.

Существует ли шаблон проектирования, который может сократить дублирование кода? Как бы то ни было, я сохранил много дублирования, но мне больно видеть тот же самый код в трех классах, чтобы каждый подкласс занимался другим типом Activity.

Изменить: Поскольку мне кажется, что мне нужно быть более конкретным …

Предположим, я пытаюсь решить проблему загрузки фонограммы AsyncTask во время изменений ориентации. Решение, которое я имею прямо сейчас, – использовать обратные вызовы; Есть менеджер загрузок, который у меня есть, который запускает эти загрузки, а затем у меня есть Activity attach callback к нему. Когда ориентация изменяется, действие уничтожается, а затем воссоздается; Во время этого процесса я отсоединяю обратный вызов старой активности, а затем присоединяю новый обратный вызов из нового действия.

Изменения ориентации являются общей проблемой, и во многих действиях я запускаю Activity с представлением прогресса, пока данные загружаются. То, что я пытаюсь решить, – это не повторять эту логику управления ориентацией в десять раз; Мое первоначальное решение заключалось в подклассе Activity, но затем я получил проблему выше.

Предпочитают композицию по наследованию . Что бы ни было распространено, делегируйте некоторые классы (классы), которые могут быть членами Activity, ListActivity и MapActivity.

Проблема в том, что вы смешиваете представление и логику своей программы. Фоновый поток, такой как AsyncTask, будет работать до тех пор, пока ваше приложение не будет убито из системы. Вы можете выполнить загрузку всего в асинхронной задаче, а затем сохранить ее где-нибудь на SD-карте, чтобы получить ее оттуда, если она будет готова.

Вы можете подклассифицировать класс приложения для ссылки на задание или обработчик для связи с классом из каждого Activity.

Если это не решение вашей проблемы, возможно, вы можете немного разъяснить этот вопрос. Это поможет узнать, что вы делаете в методах onCreate ….

Я не использовал MapActivity, но я решил эту проблему, не используя ListActivity и предоставляя функциональность себе в Activity. В ListActivity действительно не так много, если вы посмотрите: http://google.com/codesearch/p?hl=ru#uX1GffpyOZk/core/java/android/app/ListActivity.java Внедрите функциональность самостоятельно, вы получите больше настроек И больше места для роста.

Любой способ для вас иметь вспомогательный класс со статическими методами, которым вы будете передавать свои действия, и выполнять общую работу там, а не в каждом мероприятии?