Які схеми архітектури використовуються на Android? [зачинено]

Я займаюся невеликим дослідженням мобільних платформ, і хотілося б дізнатися, які шаблони дизайну використовуються в Android?

наприклад, в iOS Model-view-controller дуже широко використовується разом з делегуванням та іншими моделями.

Які схеми і де зокрема використовується Android?

EDIT

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

Я спробував використовувати як модель-перегляд-контролер (MVC), так і модель-перегляд-презентатор архітектурних моделей для роботи з Android. Мої висновки - модель-перегляд - контролер працює чудово, але є кілька "проблем". Все зводиться до того, як ви сприймаєте Activityклас Android . Це контролер, чи це вид?

Фактичний Activityклас не розширює Viewклас Android , але він, однак, обробляє відображення вікна користувачеві, а також обробляє події цього вікна (onCreate, onPause тощо).

Це означає, що коли ви використовуєте шаблон MVC, ваш контролер насправді буде псевдо-контролером. Оскільки він обробляє відображення вікна користувачеві, з додатковими компонентами перегляду ви додали до нього за допомогою setContentView, а також обробляєте події щонайменше для різних подій життєвого циклу діяльності.

У MVC контролер повинен бути основною точкою входу. Що трохи дискусійно, якщо це стосується застосування його до розробки Android, оскільки діяльність є природним вхідним пунктом для більшості програм.

Через це я особисто вважаю, що модель “перегляд - презентатор” є ідеальною формою для розробки Android. Оскільки роль цього виду в цій моделі є:

• Служить вхідною точкою
• Візуалізація компонентів
• Маршрутизація подій користувача на ведучого

Це дозволяє вам реалізувати свою модель так:

Перегляд - це вміст ваших компонентів інтерфейсу користувача та обробляє події для них.

Ведучий - це допоможе спілкуванню між вашою моделлю та вашим поглядом, розгляне це як шлюз до вашої моделі. Тобто, якщо у вас є складна модель домену, що представляє, Бог знає що, а ваш погляд потребує лише дуже невеликого підмножини цієї моделі, завдання презентаторів полягає в тому, щоб запитувати модель, а потім оновити вигляд. Наприклад, якщо у вас є модель, яка містить абзац тексту, заголовок та кількість слів. Але в заданому вікні вам потрібно лише відобразити заголовок у поданні. Тоді ведучий прочитає дані, необхідні від моделі, та оновить подання відповідно.

Модель - це в основному має бути ваша повна модель домену. Сподіваємось, це також допоможе зробити вашу модель домену більш "тісною", оскільки вам не знадобляться спеціальні методи для розгляду справ, про які було сказано вище.

Від'єднуючи модель від поданого виду разом (за допомогою використання презентатора), ви також протестуєте свою модель набагато інтуїтивніше. Ви можете провести одиничні тести для вашої моделі домену та одиничні тести для своїх презентаторів.

Спробуй. Я особисто вважаю це чудовим пристосуванням для розробки Android.

Оновлення листопада 2018 року

Пропрацювавши і ведучи блоги про MVC та MVP в Android протягом декількох років (див. Основу відповіді нижче), я вирішив захопити свої знання та розуміння у більш всебічній та легкозасвоюваній формі.

Отже, я випустив повноцінний відеокурс про архітектуру програм Android. Тож, якщо вам цікаво оволодіти найсучаснішими архітектурними зразками в розробці Android, ознайомтеся з цим всебічним курсом тут .

Цю відповідь було оновлено, щоб залишатися актуальною з листопада 2016 року

Схоже, ви шукаєте архітектурні візерунки, а не шаблони дизайну .

Шаблони дизайну мають на меті описати загальний "трюк", який може застосувати програміст для обробки певного набору програмних завдань, що повторюються. Наприклад: У ООП, коли є необхідність, щоб об'єкт повідомляв набір інших об'єктів про деякі події, може бути використана схема дизайну спостерігача .

Оскільки програми Android (і більшість AOSP) написані на Java, яка є об'єктно-орієнтованою, я думаю, вам буде важко шукати єдиний шаблон дизайну OOP, який НЕ використовується на Android.

З іншого боку, архітектурні зразки не стосуються конкретних програмних завдань - вони спрямовані на створення шаблонів організації програмного забезпечення на основі випадків використання відповідної програмної компоненти.

Це звучить дещо складно, але я сподіваюся, що приклад з’ясує: Якщо якась програма буде використана для отримання даних з віддаленого сервера та представлення їх користувачеві структуровано, то MVC може стати хорошим кандидатом для розгляду. Зауважте, що я нічого не говорив про програмні завдання та програмний потік програми - я просто описав це з точки зору користувача, і з’явився кандидат на архітектурну схему.

Оскільки ви згадали про MVC у своєму питанні, я здогадуюсь, що архітектурні зразки - це те, що ви шукаєте.

Історично не було офіційних вказівок Google щодо архітектури додатків, що (серед інших причин) призвело до тотального безладу у вихідному коді програм для Android. Насправді, навіть сьогодні більшість застосунків, які я бачу, як і раніше не дотримуються кращих практик OOP і не показують чіткої логічної організації коду.

Але сьогодні ситуація інша - нещодавно компанія Google випустила бібліотеку Data Binding , яка повністю інтегрована з Android Studio і, навіть, розгорнула набір креслення архітектури для додатків Android .

Два роки тому було дуже важко знайти інформацію про MVC або MVP на Android. Сьогодні MVC, MVP та MVVM стали "гучними словами" в Android-спільноті, і ми оточені незліченними експертами, які постійно намагаються переконати нас у тому, що MVx кращий, ніж MVy. На мій погляд, обговорювати, чи MVx кращий за MVy, абсолютно безглуздо, оскільки самі терміни дуже неоднозначні - просто подивіться на відповіді на це питання , і ви зрозумієте, що різні люди можуть пов'язувати ці абревіатури з абсолютно різними конструкціями.

У зв'язку з тим, що офіційно розпочато пошук найкращого архітектурного шаблону для Android, я думаю, ми збираємось побачити ще кілька ідей. На даний момент насправді неможливо передбачити, яка модель (або закономірності) стануть галузевими стандартами в майбутньому - нам потрібно буде зачекати і подивитися (я думаю, це питання року чи двох).

Однак є одне передбачення, яке я можу зробити з високим ступенем впевненості: Використання бібліотеки прив'язки даних не стане галузевим стандартом. З впевненістю можу сказати, що оскільки бібліотека прив'язки даних (при її нинішньому впровадженні) забезпечує короткочасне підвищення продуктивності та якесь архітектурне керівництво, але це зробить код нерентабельним у довгостроковій перспективі. Як тільки довготривалі ефекти цієї бібліотеки вийдуть на поверхню - від неї відмовляться.

Зараз, хоча у нас сьогодні є якісь офіційні вказівки та інструменти, я особисто не думаю, що ці вказівки та інструменти є найкращими доступними варіантами (і вони, безумовно, не єдині). У своїх програмах я використовую власну реалізацію архітектури MVC. Він простий, чистий, читабельний і перевірений і не потребує додаткових бібліотек.

Цей MVC не просто косметично відрізняється від інших - він заснований на теорії, що Діяльність в Android не є елементами інтерфейсу , що має величезний вплив на організацію коду.

Отже, якщо ви шукаєте гарну архітектурну схему для додатків Android, яка відповідає принципам SOLID , ви можете знайти опис у моєму дописі про архітектурні схеми MVC та MVP в Android .

Коли я доходжу до цієї публікації, це дійсно допомагає мені зрозуміти зразки на прикладі, тому я маю зробити нижче таблицю, щоб чітко побачити шаблони дизайну та їх приклад в Android Framework

Сподіваюся, вам це стане в нагоді.

• Деякі корисні посилання:
  

  1. Загальні шаблони дизайну для Android з Kotlin

  2. Ознайомлення з моделями дизайну Android

  3. Шаблони дизайну

Існують різні схеми, які використовуються в рамках Android, наприклад:

• Приймач широкомовної передачі використовує шаблон спостерігача
• Для виклику служби віддаленого користування використовується шаблон проксі
• Група перегляду та перегляду використовує композитний візерунок
• Медіа рамки використовують шаблон фасаду

Ось чудова стаття про загальні шаблони дизайну для Android :

Шаблони творчості:

• Builder (наприклад, AlertDialog.Builder )
• Ін'єкційна залежність (наприклад, кинджал 2 )
• Сінглтон

Структурні структури:

• Адаптер (наприклад, RecyclerView.Adapter )
• Фасад (наприклад, Модернізація )

Поведінкові моделі:

• Команда (наприклад, EventBus )
• Спостерігач (наприклад, RxAndroid )
• Контролер перегляду моделі
• View View ViewModel ( схожа на модель MVC вище )

У наступних класах Android використовуються шаблони дизайну

1) Власник перегляду використовує шаблон дизайну Singleton

2) Намір використовує заводський шаблон дизайну

3) Адаптер використовує шаблон дизайну адаптера

4) Транслятор трансляції використовує модель дизайну спостерігача

5) Перегляд використовує композитний шаблон дизайну

6) Media FrameWork використовує шаблон дизайну фасадів

У випадку сповіщеньNotificationCompat.Builder використовується Шаблон Builder

подібно до,

mBuilder = new NotificationCompat.Builder(this)
                    .setSmallIcon(R.drawable.ic_stat_notification)
                    .setContentTitle(getString(R.string.notification))
                    .setContentText(getString(R.string.ping))
                    .setDefaults(Notification.DEFAULT_ALL);

Android також використовує шаблон дизайну ViewHolder.

Він використовується для підвищення продуктивності ListView під час прокрутки.

Шаблон дизайну ViewHolder дозволяє отримувати доступ до кожного перегляду елемента списку без необхідності пошуку, зберігаючи цінні цикли процесора. Зокрема, це дозволяє уникнути частих дзвінків findViewById () під час прокрутки ListView, і це зробить його плавним.

Всі ці зразки, MVC, MVVM , MVP та Presentation Model , можна застосувати до програм Android, але без сторонніх фреймів не просто отримати організовану структуру та чистий код.

MVVM походить від PresentationModel. Коли ми застосовуємо MVC, MVVM і презентаційну модель до програми Android, ми дійсно хочемо, щоб це було чіткий структурований проект і, що ще важливіше, простіше для одиничних тестів.

На даний момент без сторонніх фреймворків у вас зазвичай багато коду (наприклад, addXXListener (), findViewById () тощо), що не додає ніякої цінності для бізнесу. Більше того, вам потрібно запустити тести Android, замість звичайних тестів на JUnit, які потребують віків, і тести для модулів дещо недоцільні.

З цієї причини, кілька років тому ми розпочали проект з відкритим кодом, RoboBinding - Рамка для презентації, що зобов'язує дані, для платформи Android. RoboBinding допомагає писати код інтерфейсу, який простіше читати, тестувати та підтримувати. RoboBinding знімає необхідність у непотрібному коді, наприклад addXXListener або іншому , і переносить логіку інтерфейсу користувача на модель презентації, яка є POJO і може бути протестована за допомогою звичайних тестів JUnit . Сам RoboBinding поставляється з більш ніж 300 тестами JUnit для забезпечення його якості.

Я хотів би додати схему дизайну, застосовану в Android Framework. Це Half Sync Half Async, що використовується в реалізації Asynctask. Дивіться мою дискусію на

https://docs.google.com/document/d/1_zihWXAwgTAdJc013-bOLUHPMrjeUBZnDuPkzMxEEj0/edit?usp=sharing

В Android "шаблон роботи робочої черги" зазвичай використовується для завантаження завдань з основного потоку програми.

Приклад: Дизайн класу IntentService.

Служба IntentService отримує Інтенти, запускає робочу нитку та припиняє послугу за необхідності. Усі запити обробляються на одному робочому потоці.

Binder використовує "Шаблон спостерігача" для сповіщення одержувача смерті.