Стиль программирования Android

Question

В последнее время я кодировал свой телефон Android, и мне было интересно ... этот класс Intent должен был наметить новый стиль программирования?

Я подозреваю, что дизайн API обескураживает MVC: намерения - это основной способ взаимодействия со всеми объектами, связанными с пользователем (Activities, Services, Other apps ...).

Действительно ли мой ход мысли? Должен ли придерживаться «загрязняющих» действий бизнес-логикой?

Я читал сайт разработчиков Android, но особого стиля кодирования не поощряли.

Answer 1

Я взял много следующих идей, которые я взял из этого OReilly book. Это просто то, что сработало лучше для меня.

Что касается архитектуры, то это помогло мне подумать об интерфейсе Android как шаблоне Page Controller - я нашел его похожим на .Net Web Forms на самом деле. Таким образом, да, он подходит для MVC (по крайней мере, для параметра «Контроллер страницы»). Активность - это ваш контроллер, который обычно хранит ваше представление в XML, и вы можете создать свою модель, как вам нравится.

В Android вы видите множество идей веб-дизайна. Навыки во многом похожи на HTTP, или, как правило, REST. У намерений есть «существительное», которое говорит о том, к чему они относятся (может быть явное объявление класса, то есть: перейти к определенной Деятельности или быть более неявным с использованием Intent Filters), действие очень похоже на HTTP-глагол (Get, Post , и т. д.), Bundle очень похож на список параметров строки запроса или полезной нагрузки ... и т. д.

И похоже на веб-страницу, вы хотите, чтобы Activity могла позаботиться о себе.Я имею в виду, что вы не хотите передавать какой-то большой сериализованный объект от активности к активности, его намного более чистый/устойчивый/надежный, чтобы просто передать идентификатор данной записи в следующую активность и позволить этой активности захватить запись с этим идентификатором из db (ContentProvider, некоторый другой постоянный источник ...). Кроме того, действия также должны быть тесно связаны, и вы должны быть в состоянии перейти к одному из разных путей, а также сделать их более пригодными для повторного использования. Таким образом, позволяя вызывающим агентам просто предоставить recordId намного проще, чем Activity, ожидая, что его потребитель предоставит большой сериализованный объект.

Подводная черта - нет, вам не нужно загрязнять деятельность бизнес-логикой, убирать этот материал на прикладном уровне или шлюз или что-то в этом роде. Что касается настойчивости, интерфейс ContentProvider довольно хорошо разработан - мне это нравится. Он также продолжает тему Android RESTful, доступ к контенту через URL-адреса и глаголы (запрос, удаление, обновление, вставка).

Answer 2

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

На мой взгляд, Android действительно ничего не меняет с точки зрения стиля кодирования. Ваш стиль кодирования с Java все равно будет работать нормально, и большинство приложений для Android выглядят очень похожими на другие приложения. В реферате есть некоторые вещи, которые вы, возможно, захотите сделать в Android, вы не делаете так много на других языках, see the Android guide for details. Основная идея: память ограничена, не используйте ее, если вам это не нужно.

Что касается архитектуры всей программы, да, стиль Android очень основан на стиле передачи сообщений (через объекты Intent). Как вы реагируете на события GUI в пределах Активность по-прежнему в основном такая же: вы используете обработчики событий для реагирования на события, такие как нажатия кнопок и т. Д. Но платформа сильно сосредоточена вокруг разработки приложений с использованием разных компонентов (Activities, Services , BroadcastReceivers и т. Д.) И намерения общаться между ними. Хотя Intents обеспечивают гибкий способ обмена данными между компонентами, вы все равно не должны передавать огромные объемы данных в Intents, вместо этого вы должны помещать такие вещи в ContentProvider или что-то подобное.

Answer 3

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