наследование пользовательских действий с перегрузкой setContentView, setListAdapter и т. д. - PullRequest
2 голосов
/ 21 августа 2011

Уважаемые коллеги-разработчики

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

Пожалуйста, поразите меня, является ли подход, описанный ниже, правильным или нет.Буду признателен за ваши предложения, как максимально использовать функциональность уже выполненных действий .

Я думаю унаследовать мой браузер треков, браузер плейлистов, воспроизведение мультимедиа и т. Д. От стандартных оригинального музыкального плеера.Затем мне нужно будет заменить макет и перехватить с соответствующей обработкой некоторых событий.

Задача 1: setContentView уже устанавливает макет внутри onCreate оригинальной деятельности.Мне нужно вызвать super.onCreate в моем onCreate , а затем снова вызвать setContentView .Я исследовал, что можно вызывать setContentView несколько раз , но необходимо каждый раз создавать экземпляры всех элементов пользовательского интерфейса.Я думаю, что они могут быть проблемы с производительностью и совместимостью. Мое предложение 1: перегрузить setContentView и определить, передан ли экземпляр соответствующего макета.В случае, если мы раздуваем действие.

Задача 2: почти все участники являются закрытыми в исходных действиях, но мне нужно будет заменить адаптер и, возможно, некоторые широковещательные приемники загружены в исходных действиях, Мое предложение 2: снова могу перегрузить setListAdapter , registerReceivers и т. Д. И проверить, какие экземпляры они пытаются загрузить.Если экземпляры не относятся к моим классам, я бы пропустил их загрузку, иначе я бы загрузил их.

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

...