Составные представления и контроллеры представления - PullRequest
0 голосов
/ 29 мая 2010

Я немного новичок в Android и нахожусь в процессе разработки приложения с парой довольно сложных представлений. Одно из представлений предназначено для использования сложного представления, отображающего информацию, связанную с объектами модели и разделенную на несколько различных представлений; навигация по которому должна быть достигнута с помощью скользящих эффектов (то есть скольжение пальца по экрану для перемещения от одного экрана к другому и т. д.). Само представление будет использоваться для размещения нескольких наборов представлений для различных типов объектов модели, но с общей структурой, которая повторно используется между ними всеми. В качестве грубого примера, представление может отображать информацию о человеке (объект модели), отображая несколько подробных представлений: представление общей информации, представление, отображающее список хобби, и представление, отображающее список других людей. связано с их социальной сетью. Тот же общий вид, когда ему дается объект модели, представляющий конкретный автомобиль, дает несколько разных видов: общий вид с деталями, вид, содержащий фотоизображения для этого транспортного средства, вид, представляющий места, где его можно приобрести, и вид, обеспечивающий список связанных автомобилей. (ПРИМЕЧАНИЕ. Это не реальные данные, а общие намерения представления). Подвиды НЕ будут охватывать всю область экрана, и другие функции в пределах представления должны быть как видимыми, так и взаимодействовать с пользователем.

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

Я пытаюсь определить подходящий способ использования фреймворка Android, чтобы наилучшим образом добиться этого, не нарушая целостность фреймворка. По сути, я пытаюсь определить, как разбить это увеличенное представление на блоки многократного использования (т. Е. Общий вид, контроллеры подвидов для конкретной модели и отдельные подробные представления). Чтобы быть более конкретным, я пытаюсь определить, лучше ли это представление составлять из нескольких пользовательских классов представления или из нескольких классов Activity. Я видел несколько примеров пользовательских составных представлений, но они, как правило, используются для составления простых представлений без сложных контроллеров и без учета общего жизненного цикла Activity (то есть, при необходимости, хранения и извлечения данных, связанных с объектами модели). С другой стороны, единственный реальный пример, который я видел в отношении представления, состоящего из компоновки Activity, - это сам TabActivity, и его нельзя настроить так, как для этого необходимо.

Есть ли у кого-нибудь какие-либо предложения относительно подходящего способа структурирования моего взгляда для достижения нужной мне среды приложения? Просмотры? Мероприятия? Что-то еще?

Любое руководство будет оценено. Заранее спасибо.

Ответы [ 2 ]

0 голосов
/ 29 мая 2010

Я не уверен, что следовал всему, что вы там говорили, диаграмма, показывающая поток, может помочь, но ..

Обычно вы можете видеть только одно действие одновременно. Эта деятельность отвечает за отображение всего представления. Единственное исключение из того, что я видел, - это всплывающее окно с предупреждением. По моему опыту, они, как правило, немного медленные. Как правило, у вас есть новое действие каждый раз, когда вы меняете страницы. Похоже, в вашем случае это может происходить каждый раз, когда меняется общий вид.

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

0 голосов
/ 29 мая 2010

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

Телефоны имеют очень ограниченную оперативную память и очень ограниченные процессоры. Ваше среднее Android-устройство имеет мощность ПК десятилетней давности или хуже. Пожалуйста, не перегружайте ваше приложение.

Если быть более конкретным, я пытаюсь определить, является ли это мнение лучшим разработан как композит из нескольких пользовательские классы просмотра или составной несколько занятий Activity.

Я бы сказал, "ничего из вышеперечисленного". Если вы хотите создать «пользовательские классы View» для распространения среди сообщества разработчиков Android, это одно. Однако, для ваших обстоятельств, просто создайте свой Views - не делайте их подклассами. Я определенно придерживаюсь подхода «композиция поверх наследования», когда речь заходит о системе Android View.

ИМХО, Activity - это ваш контроллер (или, возможно, презентатор, как MVP, лучшая архитектурная аналогия), XML-макет и его составляющая Views - это уровень представления, а ваша база данных - ваша модель.

...