├── Intro.md
├── LICENSE
├── README.md
├── cases
├── Cases_article.md
├── auth
│ └── Auth_article.md
└── wizards
│ └── Wizards_article.md
├── ebook
└── Android Architecture Book.epub
├── practice
└── Practice_article.md
└── theory
└── Theory_article.md
/Intro.md:
--------------------------------------------------------------------------------
1 | Всем привет!
2 |
3 | В Андроид-мире архитектурой в общем и Чистой архитектурой в частности уже никого не удивишь. На практически любой конференции/митапе всегда будет доклад-другой об этом. И на самом деле это очень здорово, что разработчики все больше внимания уделяют данному вопросу. Ведь в итоге мы получаем работоспособное, стабильное и простое в сопровождении приложение. Я не беру в расчет героев-одиночек, которые пилят крутые приложения без каких-либо архитектур, и живут прекрасно. Дай Бог здоровья этим людям, ведь без них я даже не представляю, что будет с приложением потом.
4 |
5 | Андроид-разработчикам больше приживается подход под названием "Clean Architecture". На самом деле, подход изначально презентовался Бобом Мартином, и на хабре можно найти несколько статей о том, как её видят разработчики Go и разработчики Python, например.
6 | Основная идея подхода состоит в том, чтобы сделать приложение, которое:
7 | 1. Не зависит от UI
8 | 2. Не зависит от БД
9 | 3. Не зависит от внешних фреймворков
10 | 4. Является тестируемым
11 |
12 | Таким образом, в хорошо спроектированном приложении можно "откладывать" решения до того момента, когда они действительно необходимы. Если разработка затянется, и вместо одной технологии хранения появится другая, или если ваше приложение вдруг станет хайповым, и хранилище "на файликах" перестанет справляться с нагрузкой - возможность лёгкой смены решения сыграет вам на руку. В итоге вы получаете слоистую и гибкую архитектуру. Вы получаете единый подход в осмыслении вашего приложения.
13 |
14 | На текущий момент в интернете можно найти большое количество информации по этой теме. Как это часто бывает, местами она противоречит друг другу, местами она просто раскидана на множество частей. Но самое грустное заключается в том, что когда разработчик начинает использовать данный подход, он зачастую не знает с чего начать, и он спотыкается о множество деталей и нюансов.
15 | В январе 2017 года был создан [архитектурный чатик](https://t.me/Android_Architecture), призванный как раз помогать и приходить к чему-то единому в архитектуре. И в этом чатике мы в очередной раз убедились, что очень часто задаются одни и те же вопросы, и люди проходят по одним и тем же граблям. Не хватает просто хорошего практического рассмотрения определенных нюансов и примеров решения конкретных кейсов.
16 | Именно поэтому мы решили попробовать создать некий "**Clean Architecture CookBook**" - ресурс, на котором можно будет посмотреть все элементы подхода "от А до Я", с теоретическим обоснованием и, что немаловажно, практическими примерами.
17 | У нас за плечами большой опыт написания самых различных приложений с Чистой архитектурой, и мы уверенно можем сказать, что данный подход работает и делает нашу жизнь намного проще.
18 |
19 | Итак, перед вами **версия 0.1**. Первый набросок, который состоит из трех частей:
20 | 1. [Теория](https://github.com/AndroidArchitecture/AndroidArchitectureBook/blob/master/theory/Theory_article.md). В этом разделе представлено краткое теоретическое введение в тему Чистой архитектуры.
21 | 2. [Практические вопросы](https://github.com/AndroidArchitecture/AndroidArchitectureBook/blob/master/practice/Practice_article.md). Обзор наиболее задаваемых вопросов в виде "Проблема - Решение".
22 | 3. [Практические кейсы](https://github.com/AndroidArchitecture/AndroidArchitectureBook/blob/master/cases/Cases_article.md). Самая сладкая часть. Реальные жизненные и нетривиальные кейсы, реализованные в парадигме Чистой архитектуры.
23 | Уже подробно рассмотрены [Аутентификация](https://github.com/AndroidArchitecture/AndroidArchitectureBook/blob/master/cases/auth/Auth_article.md) и [Визарды](https://github.com/AndroidArchitecture/AndroidArchitectureBook/blob/master/cases/wizards/Wizards_article.md) в Чистой архитектуре.
24 | 4. [Многомодульность в Android с точки зрения архитектуры. От А до Я](https://habr.com/company/kaspersky/blog/422555/)
25 | Подробно рассмотрен переезд на многомодульность.
26 |
27 | Сразу оговорюсь, представленное в CookBook мнение не является абсолютной истиной. Абсолютная истина не достижима, тем более в архитектуре. Но мы сделали попытку, и будем безмерно рады, если вы оставите свою обратную связь в виде звездочек и предложений/замечаний в виде issues и pull requests, которые можно обсудить либо в задачах, либо в чате.
28 | Присоединяйтесь к проекту! Сделаем нашу программистскую жизнь проще и лучше! За Чистую архитектуру!
29 |
30 | **Авторы**:
31 | Евгений Мацюк(@eugene_matsyuk)
32 | Артур Бадретдинов(@gaketo)
33 | Александр Блинов(@xanderblinov)
34 | Александр Жеребцов(@mansonheart)
35 | и все-все-все в [архитектурном чатике](https://t.me/Android_Architecture)
36 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | Apache License
2 | Version 2.0, January 2004
3 | http://www.apache.org/licenses/
4 |
5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
6 |
7 | 1. Definitions.
8 |
9 | "License" shall mean the terms and conditions for use, reproduction,
10 | and distribution as defined by Sections 1 through 9 of this document.
11 |
12 | "Licensor" shall mean the copyright owner or entity authorized by
13 | the copyright owner that is granting the License.
14 |
15 | "Legal Entity" shall mean the union of the acting entity and all
16 | other entities that control, are controlled by, or are under common
17 | control with that entity. For the purposes of this definition,
18 | "control" means (i) the power, direct or indirect, to cause the
19 | direction or management of such entity, whether by contract or
20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the
21 | outstanding shares, or (iii) beneficial ownership of such entity.
22 |
23 | "You" (or "Your") shall mean an individual or Legal Entity
24 | exercising permissions granted by this License.
25 |
26 | "Source" form shall mean the preferred form for making modifications,
27 | including but not limited to software source code, documentation
28 | source, and configuration files.
29 |
30 | "Object" form shall mean any form resulting from mechanical
31 | transformation or translation of a Source form, including but
32 | not limited to compiled object code, generated documentation,
33 | and conversions to other media types.
34 |
35 | "Work" shall mean the work of authorship, whether in Source or
36 | Object form, made available under the License, as indicated by a
37 | copyright notice that is included in or attached to the work
38 | (an example is provided in the Appendix below).
39 |
40 | "Derivative Works" shall mean any work, whether in Source or Object
41 | form, that is based on (or derived from) the Work and for which the
42 | editorial revisions, annotations, elaborations, or other modifications
43 | represent, as a whole, an original work of authorship. For the purposes
44 | of this License, Derivative Works shall not include works that remain
45 | separable from, or merely link (or bind by name) to the interfaces of,
46 | the Work and Derivative Works thereof.
47 |
48 | "Contribution" shall mean any work of authorship, including
49 | the original version of the Work and any modifications or additions
50 | to that Work or Derivative Works thereof, that is intentionally
51 | submitted to Licensor for inclusion in the Work by the copyright owner
52 | or by an individual or Legal Entity authorized to submit on behalf of
53 | the copyright owner. For the purposes of this definition, "submitted"
54 | means any form of electronic, verbal, or written communication sent
55 | to the Licensor or its representatives, including but not limited to
56 | communication on electronic mailing lists, source code control systems,
57 | and issue tracking systems that are managed by, or on behalf of, the
58 | Licensor for the purpose of discussing and improving the Work, but
59 | excluding communication that is conspicuously marked or otherwise
60 | designated in writing by the copyright owner as "Not a Contribution."
61 |
62 | "Contributor" shall mean Licensor and any individual or Legal Entity
63 | on behalf of whom a Contribution has been received by Licensor and
64 | subsequently incorporated within the Work.
65 |
66 | 2. Grant of Copyright License. Subject to the terms and conditions of
67 | this License, each Contributor hereby grants to You a perpetual,
68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable
69 | copyright license to reproduce, prepare Derivative Works of,
70 | publicly display, publicly perform, sublicense, and distribute the
71 | Work and such Derivative Works in Source or Object form.
72 |
73 | 3. Grant of Patent License. Subject to the terms and conditions of
74 | this License, each Contributor hereby grants to You a perpetual,
75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable
76 | (except as stated in this section) patent license to make, have made,
77 | use, offer to sell, sell, import, and otherwise transfer the Work,
78 | where such license applies only to those patent claims licensable
79 | by such Contributor that are necessarily infringed by their
80 | Contribution(s) alone or by combination of their Contribution(s)
81 | with the Work to which such Contribution(s) was submitted. If You
82 | institute patent litigation against any entity (including a
83 | cross-claim or counterclaim in a lawsuit) alleging that the Work
84 | or a Contribution incorporated within the Work constitutes direct
85 | or contributory patent infringement, then any patent licenses
86 | granted to You under this License for that Work shall terminate
87 | as of the date such litigation is filed.
88 |
89 | 4. Redistribution. You may reproduce and distribute copies of the
90 | Work or Derivative Works thereof in any medium, with or without
91 | modifications, and in Source or Object form, provided that You
92 | meet the following conditions:
93 |
94 | (a) You must give any other recipients of the Work or
95 | Derivative Works a copy of this License; and
96 |
97 | (b) You must cause any modified files to carry prominent notices
98 | stating that You changed the files; and
99 |
100 | (c) You must retain, in the Source form of any Derivative Works
101 | that You distribute, all copyright, patent, trademark, and
102 | attribution notices from the Source form of the Work,
103 | excluding those notices that do not pertain to any part of
104 | the Derivative Works; and
105 |
106 | (d) If the Work includes a "NOTICE" text file as part of its
107 | distribution, then any Derivative Works that You distribute must
108 | include a readable copy of the attribution notices contained
109 | within such NOTICE file, excluding those notices that do not
110 | pertain to any part of the Derivative Works, in at least one
111 | of the following places: within a NOTICE text file distributed
112 | as part of the Derivative Works; within the Source form or
113 | documentation, if provided along with the Derivative Works; or,
114 | within a display generated by the Derivative Works, if and
115 | wherever such third-party notices normally appear. The contents
116 | of the NOTICE file are for informational purposes only and
117 | do not modify the License. You may add Your own attribution
118 | notices within Derivative Works that You distribute, alongside
119 | or as an addendum to the NOTICE text from the Work, provided
120 | that such additional attribution notices cannot be construed
121 | as modifying the License.
122 |
123 | You may add Your own copyright statement to Your modifications and
124 | may provide additional or different license terms and conditions
125 | for use, reproduction, or distribution of Your modifications, or
126 | for any such Derivative Works as a whole, provided Your use,
127 | reproduction, and distribution of the Work otherwise complies with
128 | the conditions stated in this License.
129 |
130 | 5. Submission of Contributions. Unless You explicitly state otherwise,
131 | any Contribution intentionally submitted for inclusion in the Work
132 | by You to the Licensor shall be under the terms and conditions of
133 | this License, without any additional terms or conditions.
134 | Notwithstanding the above, nothing herein shall supersede or modify
135 | the terms of any separate license agreement you may have executed
136 | with Licensor regarding such Contributions.
137 |
138 | 6. Trademarks. This License does not grant permission to use the trade
139 | names, trademarks, service marks, or product names of the Licensor,
140 | except as required for reasonable and customary use in describing the
141 | origin of the Work and reproducing the content of the NOTICE file.
142 |
143 | 7. Disclaimer of Warranty. Unless required by applicable law or
144 | agreed to in writing, Licensor provides the Work (and each
145 | Contributor provides its Contributions) on an "AS IS" BASIS,
146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
147 | implied, including, without limitation, any warranties or conditions
148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
149 | PARTICULAR PURPOSE. You are solely responsible for determining the
150 | appropriateness of using or redistributing the Work and assume any
151 | risks associated with Your exercise of permissions under this License.
152 |
153 | 8. Limitation of Liability. In no event and under no legal theory,
154 | whether in tort (including negligence), contract, or otherwise,
155 | unless required by applicable law (such as deliberate and grossly
156 | negligent acts) or agreed to in writing, shall any Contributor be
157 | liable to You for damages, including any direct, indirect, special,
158 | incidental, or consequential damages of any character arising as a
159 | result of this License or out of the use or inability to use the
160 | Work (including but not limited to damages for loss of goodwill,
161 | work stoppage, computer failure or malfunction, or any and all
162 | other commercial damages or losses), even if such Contributor
163 | has been advised of the possibility of such damages.
164 |
165 | 9. Accepting Warranty or Additional Liability. While redistributing
166 | the Work or Derivative Works thereof, You may choose to offer,
167 | and charge a fee for, acceptance of support, warranty, indemnity,
168 | or other liability obligations and/or rights consistent with this
169 | License. However, in accepting such obligations, You may act only
170 | on Your own behalf and on Your sole responsibility, not on behalf
171 | of any other Contributor, and only if You agree to indemnify,
172 | defend, and hold each Contributor harmless for any liability
173 | incurred by, or claims asserted against, such Contributor by reason
174 | of your accepting any such warranty or additional liability.
175 |
176 | END OF TERMS AND CONDITIONS
177 |
178 | APPENDIX: How to apply the Apache License to your work.
179 |
180 | To apply the Apache License to your work, attach the following
181 | boilerplate notice, with the fields enclosed by brackets "{}"
182 | replaced with your own identifying information. (Don't include
183 | the brackets!) The text should be enclosed in the appropriate
184 | comment syntax for the file format. We also recommend that a
185 | file or class name and description of purpose be included on the
186 | same "printed page" as the copyright notice for easier
187 | identification within third-party archives.
188 |
189 | Copyright {yyyy} {name of copyright owner}
190 |
191 | Licensed under the Apache License, Version 2.0 (the "License");
192 | you may not use this file except in compliance with the License.
193 | You may obtain a copy of the License at
194 |
195 | http://www.apache.org/licenses/LICENSE-2.0
196 |
197 | Unless required by applicable law or agreed to in writing, software
198 | distributed under the License is distributed on an "AS IS" BASIS,
199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
200 | See the License for the specific language governing permissions and
201 | limitations under the License.
202 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Android Architecture Book
2 |
3 | Руководство по применению чистой архитектуры в Android проектах.
4 | [Вперед к знаниям](https://github.com/AndroidArchitecture/AndroidArchitectureBook/blob/master/Intro.md)
5 |
6 | ## Устройство репозитория
7 |
8 | * Книга состоит из глав.
9 | * Каждая глава представлена отдельной директорией, в которой лежит текстовый файл и необходимые вложения
10 | * Формат текстовых файлов **M**ark**d**own (.md)
11 |
12 | ## Правила для контрибьюторов
13 |
14 | * Написание каждой из глав происходит в отдельной feature ветке (см. [шпаргалку по Gitflow](https://danielkummer.github.io/git-flow-cheatsheet/index.ru_RU.html))
15 | * Изменения сливаются в develop посредством pull request
16 | * commit message осуществляются **строго на русском языке**
17 |
18 |
19 |
--------------------------------------------------------------------------------
/cases/Cases_article.md:
--------------------------------------------------------------------------------
1 | **Практические кейсы**:
2 | 1. [Аутентификация](https://github.com/AndroidArchitecture/AndroidArchitectureBook/blob/master/cases/auth/Auth_article.md)
3 | 2. [Визарды](https://github.com/AndroidArchitecture/AndroidArchitectureBook/blob/master/cases/wizards/Wizards_article.md)
4 |
--------------------------------------------------------------------------------
/cases/auth/Auth_article.md:
--------------------------------------------------------------------------------
1 | ## Аутентификация
2 | Думаю, что во многих приложениях, особенно в банковских, вы встречались со следующим поведением приложения: работаете, работаете, а потом вдруг появляется экран ввода пин-кода. Такое поведение обосновано мерами безопасности. Опишем данный процесс чуть более подробно с некоторыми техническими подробностями.
3 | При старте приложения вам показывается экран с вводом пин-кода. Вы посылаете запрос на сервер, и в случае успеха (верного пин-кода) вам возвращается токен, и стартует сессия. Далее часть запросов вы шлете с использованием данного токена. Токен прикрепляется либо к заголовку запроса, либо к телу. Подобные запросы еще также называются запросами авторизованной зоны. То есть сессия - это время, в течении которого данный токен действителен на стороне сервера.
4 | Через какое-то время сессия завершается, обычно по истечению какого-то конкретного промежутка времени, и тогда токен "протухает". Запросы с протухшим токеном возвращают ошибку. Тогда либо нужно просто обновить токен специальным запросом, либо нужно пользователя снова перебросить на экран ввода пин-кода, обновить токен, и продолжить слать запросы авторизованной зоны с обновившимся токеном.
5 | А теперь представим, что подобное поведение вам необходимо реализовать в своем приложении. И архитектура вашего приложения - Чистая архитектура.
6 | Поэтому возникает ряд интересных вопросов:
7 | 1. На каком слое должна производиться подстановка токена в запросы?
8 | 2. Кто должен отвечать за обновление токена? На каком уровне?
9 | 3. Как обновлять токен, если для этого еще нужно попросить пользователя ввести пин-код?
10 | 4. Кто должен отлавливать авторизованные ошибки и как?
11 | 5. Ну и как это в целом выглядит в рамках Чистой архитектуры?
12 |
13 | Давайте для начала определим стек технологий:
14 | 1. Java
15 | 2. RxJava 2
16 | 3. Retrofit 2
17 |
18 | Думаю, подобным стеком пользуются многие, поэтому примеры будут на основании него. Но примеры нужны для понимания концепции. Как только станет понятна концепция, набор инструментов (RxJava и Retrofit) и язык - это все-таки дело вторичное и больше о деталях.
19 | Сразу скажу, примеры - это просто примеры, поэтому там нет обработок ошибок, отсутствия сети и вот этого всего.
20 |
21 | Рассмотрим [первый пример (ветка - sample_1)](https://github.com/AndroidArchitecture/AuthCase/tree/sample_1). Суть его заключается в том, что для обновления токена нам не нужно просить пользователя ввести пин-код, и при протухании токена возвращается 401 ошибка.
22 | Собственно, первый вопрос. А где же должна производиться подстановка токена.
23 | Вообще подстановка токена, добавление какой-то служебной информации в запросы и прочее не относятся ни к UI, ни к бизнес-логике. Это детали реализации вашей серверной части и не более. Собственно и находиться они должны в слое **Data**.
24 | Для хранения токена лучше использовать отдельную сущность - **AuthHolder**.
25 | Поэтому примерная схема взаимодействия слоев будет такой:
26 | 
27 |
28 | **AuthRepository** хочет осуществить запрос. Для этого он использует классы из **AuthNetwork**. **AuthNetwork** включает в себя все необходимые для осуществления запроса классы, т.е. в нашем случае это Retrofit со всеми вспомогательными классами (OkHttp, Interceptor, Authenticator). В [примере](https://github.com/AndroidArchitecture/AuthCase/tree/sample_1) все они объединены в **AuthNetworkModule**.
29 | Для осуществления запроса в авторизованную зону **AuthNetwork** берет с **AuthHolder** токен и прикрепляет его, скажем, к заголовку запроса через **Interceptor**.
30 | Давайте посмотрим на **Interceptor**:
31 | ```java
32 | public class MainInterceptor implements Interceptor {
33 |
34 | private AuthHolder authHolder;
35 | private static final String ACCESS_TOKEN_HEADER = "Access-Token";
36 |
37 | public MainInterceptor(AuthHolder authHolder) {
38 | this.authHolder = authHolder;
39 | }
40 |
41 | @Override
42 | public Response intercept(Chain chain) throws IOException {
43 |
44 | Request.Builder requestBuilder = chain.request().newBuilder();
45 | if (chain.request().header(ACCESS_TOKEN_HEADER) == null) {
46 | requestBuilder.addHeader(ACCESS_TOKEN_HEADER, authHolder.getToken());
47 | }
48 |
49 | return chain.proceed(requestBuilder.build());
50 | }
51 |
52 | }
53 | ```
54 | Допустим, что если токен протухает, то сервер возвращает нам 401 ошибку. В этом случае мы можем воспользоваться **Authenticator**, специальным механизмом OkHttp для обработки подобных ситуаций. И в **Authenticator** мы должны у **AuthHolder** запустить процесс обновления токена:
55 | ```java
56 | public class MainAuthenticator implements Authenticator {
57 |
58 | private static final String ACCESS_TOKEN_HEADER = "Access-Token";
59 |
60 | private AuthHolder authHolder;
61 |
62 | public MainAuthenticator(AuthHolder authHolder) {
63 | this.authHolder = authHolder;
64 | }
65 |
66 | @Nullable
67 | @Override
68 | public synchronized Request authenticate(Route route, Response response) throws IOException {
69 | String storedToken = authHolder.getToken();
70 | String requestToken = response.request().header(ACCESS_TOKEN_HEADER);
71 |
72 | Request.Builder requestBuilder = response.request().newBuilder();
73 |
74 | if (storedToken.equals(requestToken)) {
75 | authHolder.refresh();
76 | }
77 |
78 | return buildRequest(requestBuilder);
79 | }
80 |
81 | private Request buildRequest(Request.Builder requestBuilder) {
82 | return requestBuilder.header(ACCESS_TOKEN_HEADER, authHolder.getToken()).build();
83 | }
84 |
85 | }
86 | ```
87 | Благодаря добавлению ```synchronized``` к методу ```authenticate``` и блокирующему методу ```authHolder.refresh()``` мы добиваемся того, что при возникновении 401 ошибки мы первым делом идем обновлять токен. Все остальные запросы, которые возвращают 401 ошибку, тоже ждут обновления токена, и только после этого идут повторные запросы с обновленным токеном. Очень удобно!
88 | Логичный вопрос. А как должен обновляться **AuthHolder**, через что он организует свой запрос обновления токена. Так как опять-таки это внутренняя кухня организации работы с сервером, то Repositories и другие слои про это не знают. Это внутреннее дело **Data**.
89 | Хорошо, а через что тогда лучше осуществлять запрос? Через **CommonNetwork**, который будет включать классы для осуществления запросов неавторизованной зоны (запросов, не требующих токена). В [примере](https://github.com/AndroidArchitecture/AuthCase/tree/sample_1) эти классы объединены в **CommonNetworkModule**.
90 | Обновленная схема приобретет вид:
91 | 
92 |
93 | А теперь еще посмотрим на **AuthHolder**:
94 | ```java
95 | public class AuthHolder {
96 |
97 | private CommonApi commonApi;
98 |
99 | @NonNull
100 | private volatile String token = "StartToken";
101 |
102 | public AuthHolder(CommonApi commonApi) {
103 | this.commonApi = commonApi;
104 | }
105 |
106 | @NonNull
107 | public String getToken() {
108 | return token;
109 | }
110 |
111 | public void refresh() {
112 | updateToken().blockingGet();
113 | }
114 |
115 | private Single updateToken() {
116 | return commonApi.updateToken()
117 | .singleOrError()
118 | .doOnSuccess(newToken -> token = newToken);
119 | }
120 |
121 | }
122 | ```
123 | На всякий случай напомню, что у **CommonNetwork** и **AuthNetwork** должны быть **разные** пулы потоков.
124 | А что делать, если сервер при подобной ошибке возвращает не 401 ошибку, а, допустим, успех, но в теле ответа содержится инфа, что нет авторизации. Это уже по сути особенности реализации, но вообще подобную ситуацию вы можете обработать с помощью **Interceptor**. Посмотрите реализацию **okhttp3.internal.http.RetryAndFollowUpInterceptor**, в котором, кстати говоря, и дергается наш **Authenticator**.
125 |
126 | Теперь рассмотрим более сложный случай. Когда токен протухает, то нам необходимо попросить пользователя ввести пин-код еще раз, и в случае правильного пин-кода обновить токен.
127 | Как можно увидеть, здесь уже задействуется UI. То есть будут задействоваться все слои. Таким образом нам нужно как-то отследить, что необходимо запросить пин-код и вызвать соответствующий экран. Отследить в принципе несложно. Добавляем листенер в **AuthHolder** и слушаем его в **AuthRepositoryImpl**:
128 | ```java
129 | public class AuthRepositoryImpl implements AuthRepository {
130 |
131 | private AuthApi authApi;
132 | private AuthHolder authHolder;
133 | //...
134 |
135 | public AuthRepositoryImpl(AuthApi authApi, AuthHolder authHolder) {
136 | this.authApi = authApi;
137 | this.authHolder = authHolder;
138 | subscribeToAuthHolder();
139 | }
140 |
141 | private void subscribeToAuthHolder() {
142 | authHolder.subscribeToSessionExpired(() -> {
143 | // listen AuthHolder
144 | });
145 | }
146 |
147 | //...
148 |
149 | }
150 | ```
151 | Но данное событие нам нужно пробрасывать далее, так как Репозиторий не может принимать решения по бизнес-логики. Поэтому создаем **PinInteractor**, который будет теперь слушать **AuthRepository**:
152 | ```java
153 | public class PinInteractorImpl implements PinInteractor {
154 |
155 | // Context or Router
156 | private Context context;
157 | private AuthRepository authRepository;
158 |
159 | public PinInteractorImpl(Context context, AuthRepository authRepository) {
160 | this.context = context;
161 | this.authRepository = authRepository;
162 | subscribeToAuthRepos();
163 | }
164 |
165 | private void subscribeToAuthRepos() {
166 | authRepository.subscribePinCodeNeedUpdate(() -> {
167 | // some logic
168 | });
169 | }
170 |
171 | //...
172 |
173 | }
174 | ```
175 | А вот уже Интерактор у нас уполномочен принимать решения. В данном случае решение заключается в том, чтобы показать экран ввода Пин-кода. Перед нами один из тех немногих случаев, когда Роутер находится в Интеракторе, а не в Презентере. Давайте взглянем на получающуюся у нас схему:
176 | 
177 |
178 | Отмечу, что время жизни **PinInteractor** также скорее всего равняется времени жизни приложения, как и у **AuthRepository** и **AuthHolder**.
179 | Ну и метод ```subscribeToAuthRepos()``` у ```PinInteractorImpl``` чуть изменится:
180 | ```java
181 | private void subscribeToAuthRepos() {
182 | authRepository.subscribePinCodeNeedUpdate(() -> {
183 | router.navigateTo(GlobalNavigator.PIN_SCREEN);
184 | });
185 | }
186 | ```
187 | Весь код вы кстати можете найти в [примере, ветка - sample_2](https://github.com/AndroidArchitecture/AuthCase/tree/sample_2). Так как это пример, то некоторые вещи там упрощена, типа Presentation слоя, либо вечно живущего **PinPresenter**.
188 | Хорошо, как доставить событие о необходимости ввода пин-кода, и как это все организовать со слоями, мы разобрались. Собственно когда пользователь вводит пин-код, то мы его спускаем по слоям до **AuthHolder**. Схема немного преобразится:
189 | 
190 |
191 | Ну и чтобы допрояснить картину, вспомним, как выглядит наш **MainAuthenticator**:
192 | ```java
193 | public class MainAuthenticator implements Authenticator {
194 |
195 | private static final String ACCESS_TOKEN_HEADER = "Access-Token";
196 |
197 | private AuthHolder authHolder;
198 |
199 | public MainAuthenticator(AuthHolder authHolder) {
200 | this.authHolder = authHolder;
201 | }
202 |
203 | @Nullable
204 | @Override
205 | public synchronized Request authenticate(Route route, Response response) throws IOException {
206 | String storedToken = authHolder.getToken();
207 | String requestToken = response.request().header(ACCESS_TOKEN_HEADER);
208 |
209 | Request.Builder requestBuilder = response.request().newBuilder();
210 |
211 | if (storedToken.equals(requestToken)) {
212 | authHolder.refresh();
213 | }
214 |
215 | return buildRequest(requestBuilder);
216 | }
217 |
218 | private Request buildRequest(Request.Builder requestBuilder) {
219 | return requestBuilder.header(ACCESS_TOKEN_HEADER, authHolder.getToken()).build();
220 | }
221 |
222 | }
223 | ```
224 | Как только у одного запроса приходит 401 ошибка, то мы идем обновлять токен. Строчка:
225 | ```java
226 | authHolder.refresh();
227 | ```
228 | В это время остальные запросы, вернувшие 401 ошибку, ждут, так как мы вошли в блок ```synchronized``` у метода ```authenticate```.
229 | А вот **AuthHolder** выглядит интереснее:
230 | ```java
231 | public class AuthHolder {
232 |
233 | private CommonApi commonApi;
234 | private SessionListener sessionListener;
235 | private volatile CountDownLatch countDownLatch;
236 |
237 | @NonNull
238 | private volatile String token = "StartToken";
239 | @Nullable
240 | private volatile String pinCode;
241 |
242 | public AuthHolder(CommonApi commonApi) {
243 | this.commonApi = commonApi;
244 | }
245 |
246 | @NonNull
247 | public String getToken() {
248 | return token;
249 | }
250 |
251 | public void refresh() {
252 | pinCode = null;
253 | if (sessionListener != null) {
254 | sessionListener.sessionExpired();
255 | }
256 | countDownLatch = new CountDownLatch(1);
257 | try {
258 | countDownLatch.await();
259 | } catch (InterruptedException e) {
260 | e.printStackTrace();
261 | }
262 | updateToken().blockingGet();
263 | }
264 |
265 | private Single updateToken() {
266 | return commonApi.updateToken(new RequestTokenModel(pinCode))
267 | .singleOrError()
268 | .doOnSuccess(newToken -> token = newToken);
269 | }
270 |
271 | public void updatePinCode(@NonNull String pinCode) {
272 | this.pinCode = pinCode;
273 | countDownLatch.countDown();
274 | }
275 |
276 | public void subscribeToSessionExpired(SessionListener sessionListener) {
277 | this.sessionListener = sessionListener;
278 | }
279 |
280 | }
281 | ```
282 | Обратим внимание на метод ```public void refresh()```. В нем мы обнуляем пинкод, сообщаем подписчику об истечении сессии, в данном случае сообщаем **AuthRepository**. Затем через обычный ```CountDownLatch``` мы блокируем поток до тех пор пока не будет вызван метод ```public void updatePinCode(@NonNull String pinCode)```. В данном методе приходит введенный пользователем пин-код (**синие стрелочки** на рисунке выше).
283 | На всякий случай отмечу следующий момент. В данном случае обновление пин-кода - синхронная операция и выполняется она в главном потоке, поэтому с главного потока мы без проблем освобождаем поток, задержанный ```CountDownLatch```. Но если обновление пин-кода была бы асинхронной операцией, и выполнялась бы в другом потоке, то поток этот должен был браться не из ```Executors``` в **AuthNetwork**, иначе теоретически могло получиться, что все потоки были бы в режиме ожидания, и обновить пин-код было бы некому.
284 | После того как пришел пин-код, поток, вызвавший ```refresh```, разблокируется и запускает запрос по обновлению токена (метод ```private Single updateToken()```). В случае успешного обновления, остальные запросы с 401 ошибкой также перестартуются.
285 | Конечно же, механизм по обновлению токена с ожиданиями через ```CountDownLatch``` вы можете переделать по своему усмотрению. В этом решении также могут быть не учтены некоторые крайние случаи. Тут важна опять-таки - концепция.
286 | Вот собственно и все манипуляции =)
287 |
--------------------------------------------------------------------------------
/cases/wizards/Wizards_article.md:
--------------------------------------------------------------------------------
1 | ## Wizards в Чистой архитектуре
2 |
3 | Подходов в построении приложений и экранов довольно много.
4 | Один из распространенных подходов в организации экранов - это Wizards. Wizards - это, по сути, набор довольно простых экранов, которые в совокупности решают какую-то общую задачу, при этом набор и порядок данных экранов может меняться.
5 |
6 | Типичный пример - это процесс регистрации пользователя. Пользователь может выбрать способ регистрации, например, сам ввести данные о себе, либо залогиниться через FB и еще что-то. Затем пользователь может выбрать более подходящий ему способ верификации: через почту, смс и т.д. В итоге получаем большое количество экранов, разветвленную логику переходов на экрана, и все это ради одной цели - регистрация пользователя.
7 | Второй пример - это подготовка платежки в банковском приложении. Вы выбираете тип платежа и заполняете поля. Обычно дизайнеры в этом случае разбивают заполнение платежки на несколько экранов для удобства, ну и плюс какие-то данные могут подтянуться и автозаполниться для одних пользователей, а вот другим придется заполнять. То есть мы снова получаем большое количество экранов, разветвленную логику переходов, и все это тоже ради одной цели - создание платежки.
8 | Если следовать классической Чистой архитектуре, то получается, что каждый экран (а точнее, скорее всего, Презентер) будет ответственен за переход на следующий и предыдущий шаг. Но тогда мы теряем переиспользуемость экранов, так как следующий и предыдущие шаги могут меняться, и каждый раз нам придется менять соответствующие Презентера. Кроме того логика принятия решения о следующем шаге размазывается между экранами. Да и протестировать данную логику довольно не просто будет.
9 | Как же лучше организовать визарды в Чистой архитектуре, чтобы мы могли достигнуть следующих целей:
10 |
11 | - максимальная переиспользуемость экранов без внесения изменений в соответствующие классы (Презентеры, Интеракторы и т.д.),
12 | - независимость экранов, то есть чтобы экраны не знали друг о друге,
13 | - сосредоточение логики переходов в одном месте,
14 | - тестируемость данной логики.
15 |
16 | Что же, давайте начнем с [простого примера, ветка sample_1](https://github.com/AndroidArchitecture/WizardCase/tree/sample_1). Нам необходимо написать Визард регистрации пользователя. Состоять он будет из трех экранов:
17 |
18 | 
19 |
20 | На первом экране мы ознакамливаемся со стартовой информацией. Затем попадаем на экран принятия лицензии. И в конце вводим свои логин/пароль или же выбираем free-режим. Стрелками обозначены данные переходы.
21 | Отмечу, что с каждого экрана пользователь может вернуться на предыдущий, либо уже выйти с приложения. Вот и вся логика по нажатию на кнопку Back для упрощения. Поэтому данные действия я не буду отображать на схеме, но они будут действенны для абсолютно всех схем.
22 |
23 | Итак, начнем с простого. Каждый экран должен быть независим. И каждый экран представляет собой классический архитектурный слоеный пирог. Например, экран принятия лицензии внешне будет выглядеть вот так:
24 | 
25 |
26 | А архитектурно вот так:
27 |
28 | 
29 |
30 | И так для каждого экрана.
31 | Ок, теперь нам нужно как-то связать экраны с Визардами. Давайте рассуждать логически. Возьмем все тот же экран принятия лицензии. Что данный экран может сообщить чему-то внешнему, что отвечает за Визард. А по сути данный экран может сообщить только это:
32 |
33 | - пользователь принял лицензию,
34 | - пользователь вышел с данного экрана.
35 |
36 | Таким образом напрашивается интерфейс, через который наш экран будет общаться с Визардом:
37 | ```java
38 | public interface LicenseWizardPart {
39 | void licenseWizardAccept();
40 | void licenseWizardBack();
41 | }
42 | ```
43 | Данный интерфейс будет передаваться внешней зависимостью в Презентер, и из Презентера мы будем Визарду сообщать о соответствующих действиях:
44 | ```java
45 | @InjectViewState
46 | public class LicensePresenter extends MvpPresenter {
47 |
48 | private LicenseWizardPart licenseWizardPart;
49 | private LicenseInteractor licenseInteractor;
50 |
51 | private Disposable disposable;
52 |
53 | public LicensePresenter(LicenseWizardPart licenseWizardPart, LicenseInteractor licenseInteractor) {
54 | this.licenseWizardPart = licenseWizardPart;
55 | this.licenseInteractor = licenseInteractor;
56 | }
57 |
58 | public void acceptLicense() {
59 | if (disposable != null && !disposable.isDisposed()) {
60 | return;
61 | }
62 | disposable = licenseInteractor.acceptLicense()
63 | .doOnSubscribe(disposable -> getViewState().showProgress())
64 | .observeOn(AndroidSchedulers.mainThread())
65 | .subscribe(aBoolean -> {
66 | getViewState().hideProgress();
67 | licenseWizardPart.licenseWizardAccept();
68 | }, throwable -> {});
69 | }
70 |
71 | public void clickBack() {
72 | licenseWizardPart.licenseWizardBack();
73 | }
74 |
75 | @Override
76 | public void onDestroy() {
77 | if (disposable != null) {
78 | disposable.dispose();
79 | }
80 | super.onDestroy();
81 | }
82 |
83 | }
84 | ```
85 |
86 | Таким образом мы выделили интерфейс, по которому данный экран будет общаться с Визардом. Причем он может общаться с абсолютно любым визардом, который поддерживает данный интерфейс. Получаем переиспользуемость экрана плюс гибкость в подключении к любому Визарду.
87 | Так мы для каждого экрана готовим подобный интерфейс:
88 | 
89 |
90 | И теперь мы подходим к главному вопросу. Какая сущность должна связывать все эти экраны и каким-то образом управлять ими?
91 | В нашей Чистой архитектуре такой сущности, к сожалению, нет.
92 | Презентер? Но Презентер в нашем представлении отвечает за конкретную вьюшку, а не за несколько. Плюс Презентеру необходимо будет еще динамически как-то подключать новые вьюшки. В общем, это не его работа.
93 | Интерактор? Интерактор отвечает за бизнес-логику, но ничего не знает о вьюшках, способах их расположения и т.д. Поэтому тоже нет.
94 | Роутер? Роутер отвечает на навигацию и только. Принятие решения о том, куда нам идти дальше, не его прерогатива.
95 |
96 | Поэтому введем новую сущность под названием **SmartRouter**:
97 | 
98 | **SmartRouter** ответственен за навигацию между экранами, содержит некоторую логику, на основании которой принимает решение о следующем шаге, и содержит некоторые состояния (обычно одно состояние - текущий шаг).
99 | Давайте посмотрим, как выглядит `MainWizardSmartRouter` вживую:
100 | ```java
101 | public class MainWizardSmartRouter {
102 |
103 | private final Router router;
104 | private WizardStep currentWizardStep = NONE;
105 |
106 | private final InfoWizardPart infoWizardPart = new InfoWizardPart() {
107 |
108 | @Override
109 | public void infoWizardNext() {
110 | currentWizardStep = LICENSE;
111 | router.navigateTo(LICENSE_SCREEN);
112 | }
113 |
114 | @Override
115 | public void infoWizardBack() {
116 | router.finishChain();
117 | }
118 |
119 | };
120 |
121 | private final LicenseWizardPart licenseWizardPart = new LicenseWizardPart() {
122 |
123 | @Override
124 | public void licenseWizardAccept() {
125 | currentWizardStep = ACTIVATION;
126 | router.navigateTo(ACTIVATION_SCREEN);
127 | }
128 |
129 | @Override
130 | public void licenseWizardBack() {
131 | currentWizardStep = WizardStep.START_INFO;
132 | router.backTo(INFO_SCREEN);
133 | }
134 |
135 | };
136 |
137 | private final ActivationWizardPart activationWizardPart = new ActivationWizardPart() {
138 |
139 | @Override
140 | public void activationWizardFreeNext() {
141 | currentWizardStep = FINISH_INFO;
142 | router.finishChain();
143 | }
144 |
145 | @Override
146 | public void activationLoginWizardSuccess() {
147 | currentWizardStep = FINISH_INFO;
148 | router.finishChain();
149 | }
150 |
151 | @Override
152 | public void activationWizardBack() {
153 | currentWizardStep = WizardStep.LICENSE;
154 | router.backTo(LICENSE_SCREEN);
155 | }
156 | };
157 |
158 | public WizardSmartRouter(Router router) {
159 | this.router = router;
160 | }
161 |
162 | public void startWizard() {
163 | if (currentWizardStep != NONE) {
164 | return;
165 | }
166 | currentWizardStep = START_INFO;
167 | router.navigateTo(INFO_SCREEN);
168 | }
169 |
170 | public InfoWizardPart getInfoWizardPart() {
171 | return infoWizardPart;
172 | }
173 |
174 | public LicenseWizardPart getLicenseWizardPart() {
175 | return licenseWizardPart;
176 | }
177 |
178 | public ActivationWizardPart getActivationWizardPart() {
179 | return activationWizardPart;
180 | }
181 |
182 | }
183 | ```
184 |
185 | Вы можете заметить имплементации известных нам уже `InfoWizardPart`, `LicenseWizardPart` и `ActivationWizardPart`. `currentWizardStep` - это состояние текущего шага Визарда. Ну а вопросы непосредственной навигации делегируются через также известный нам `Router`. Если количество используемых в Визарде экранов большое, то имплементации интерфейсов можно вынести в отдельные классы.
186 | Таким образом мы получаем единую сущность, ответственную за организацию Визарда, сущность, которая объединяет все, по сути, независимые экраны.
187 |
188 | Детали реализации вы можете посмотреть в [примере](https://github.com/AndroidArchitecture/WizardCase/tree/sample_1) и как там это все выглядит вместе с Dagger2 и Moxy. Обязательно просмотрите код, прежде чем продолжать читать дальше.
189 | Что еще хочу добавить к деталям реализации: визард реализован по канонам Андроида, то есть одна Активити для всего Визарда (`MainActivity`) с тремя в данном случае фрагментами (`InfoFragment`, `LicenseFragment`, `ActivationFragment`). Поэтому в `MainActivity` реализован `NavigatorHolder` для роутинга, и также стартуется Визард (вызов `wizardSmartRouter.startWizard()` в `onResume()`).
190 | С точки зрения Даггера мы имеем два модуля (`WizardModule` и `WizardNavigationModule`), соединенных вместе в `WizardComponent`. В общем-то и все особенности.
191 |
192 | Начнем усложнять нашу жизнь. Представим, что нам необходимо реализовать такой Визард:
193 | 
194 |
195 | То есть в Визарде нам необходимо показать целых два информационных экрана, которые будут отличаться только выводимой информацией. Можно, конечно же, сделать просто копи-паст, но это не "true way". Плюс хочется переиспользуемости. Тогда в этом случае мы можем выделить абстрактную вьюшку, а конкретные реализации будут просто пробрасывать нужные Репозитории и интерфейсы взаимодействия с Визардом.
196 | Как это будет выглядеть с учетом Dagger2 и Moxy.
197 | Вот наша абстрактная вьюшка:
198 | ```java
199 | public abstract class InfoFragment extends MvpAppCompatFragment implements InfoView, BackButtonListener {
200 |
201 | private TextView infoText;
202 |
203 | @Nullable
204 | @Override
205 | public View onCreateView(LayoutInflater inflater, @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
206 | View view = inflater.inflate(R.layout.fmt_info, container, false);
207 | //
208 | infoText = (TextView)view.findViewById(R.id.info_text);
209 | Button nextButton = (Button) view.findViewById(R.id.btn_next);
210 | nextButton.setOnClickListener(v -> getPresenter().clickNext());
211 | //
212 | return view;
213 | }
214 |
215 | @Override
216 | public void showText(TextType textType) {
217 | if (textType == TextType.START) {
218 | infoText.setText(getString(R.string.fmt_info_text_start));
219 | } else if (textType == TextType.FINISH) {
220 | infoText.setText(getString(R.string.fmt_info_text_finish));
221 | } else if (textType == TextType.LOGIN) {
222 | infoText.setText(getString(R.string.fmt_info_text_login));
223 | }
224 |
225 | }
226 |
227 | @Override
228 | public boolean onBackPressed() {
229 | getPresenter().clickBack();
230 | return true;
231 | }
232 |
233 | protected abstract InfoPresenter getPresenter();
234 |
235 | }
236 | ```
237 |
238 | А вот ее наследники:
239 | ```java
240 | public class InfoStartFragment extends InfoFragment {
241 |
242 | @Inject
243 | @Named(INFO_START_ANNOTATION)
244 | InfoWizardPart infoWizardPart;
245 |
246 | @ProvidePresenter
247 | InfoPresenter provideInfoPresenter() {
248 | return new InfoPresenter(infoWizardPart, TextType.START);
249 | }
250 |
251 | @InjectPresenter
252 | InfoPresenter infoPresenter;
253 |
254 | @Override
255 | public void onCreate(Bundle savedInstanceState) {
256 | ComponentManager.getInstance().getMainComponent().inject(this);
257 | super.onCreate(savedInstanceState);
258 | }
259 |
260 | @Override
261 | protected InfoPresenter getPresenter() {
262 | return infoPresenter;
263 | }
264 |
265 | }
266 |
267 | public class InfoFinishFragment extends InfoFragment {
268 |
269 | @Inject
270 | @Named(INFO_FINISH_ANNOTATION)
271 | InfoWizardPart infoWizardPart;
272 |
273 | @ProvidePresenter
274 | InfoPresenter provideInfoPresenter() {
275 | return new InfoPresenter(infoWizardPart, TextType.FINISH);
276 | }
277 |
278 | @InjectPresenter
279 | InfoPresenter infoPresenter;
280 |
281 | @Override
282 | public void onCreate(Bundle savedInstanceState) {
283 | ComponentManager.getInstance().getMainComponent().inject(this);
284 | super.onCreate(savedInstanceState);
285 | }
286 |
287 | @Override
288 | protected InfoPresenter getPresenter() {
289 | return infoPresenter;
290 | }
291 |
292 | }
293 | ```
294 |
295 | В итоге получаем максимально простую переиспользуемость одного и того же экрана в рамках одного Визарда. Более подробно код [здесь (ветка sample_2)](https://github.com/AndroidArchitecture/WizardCase/tree/sample_2).
296 |
297 | А теперь представим такой пример:
298 |
299 | 
300 |
301 | Активация немного усложнилась =) Рассмотрим поподробнее, что происходит.
302 | Допустим, что сейчас мы на экране Активации (**Activation screen**):
303 |
304 | 
305 |
306 | По нажатию на кнопку "To personal account" пользователь попадает на экраны логина/регистрации.
307 | Сначала нас ждет снова информационный экран (нижний в схеме **Information screen**):
308 |
309 | 
310 |
311 | Далее экран Логина (**Login screen**):
312 |
313 | 
314 |
315 | На этом экране мы можем ввести свои креды и попасть на финальный экран Визарда, либо же зарегистрировать новый аккаунт (**Registration screen**):
316 |
317 | 
318 |
319 | И если регистрация проходит успешно, то мы также попадем на финальный экран Визарда.
320 | А теперь еще такая вводная: у нас есть несколько визардов, и в любом из них может понадобиться логин/регистрация. Получается, что во всех визардах нам придется вводить эти три экрана, логика взаимодействия которых между друг другом везде одинаковая.
321 | Разве никак нельзя как-то избежать этого безжалостного дублирования кода? На самом деле можно. Давайте еще раз взглянем на схему:
322 | 
323 |
324 | На самом деле ее можно трансформировать до такой схемы:
325 | 
326 |
327 | То есть последовательность экранов InformationScreen, LoginScreen и RegistrationScreen и логику их взаимодействия мы выделяем в новый **AccountWizard**. Этот **AccountWizard** может сообщить внешнему Визарду, допустим, только две вещи:
328 | - пользователь вошел в нашу систему (залогинился или зарегистрировался, неважно),
329 | - пользователь не вошел в нашу систему (будем полагать, что просто вышел с данных экранов, ошибки логина/регистрации вовне не выносим).
330 |
331 | Таким образом получаем интерфейс:
332 | ```java
333 | public interface AccountWizardPart {
334 | void onSuccess();
335 | void onBack();
336 | }
337 | ```
338 | Теперь взглянем на получившийся ```AccountWizardSmartRouter``` :
339 | ```java
340 | public class AccountWizardSmartRouter {
341 |
342 | private final Router router;
343 | private final AccountWizardPart accountWizardPart;
344 | private AccountWizardStep accountWizardStep = NONE;
345 |
346 | private final InfoWizardPart infoWizardPart = new InfoWizardPart() {
347 |
348 | @Override
349 | public void infoWizardNext() {
350 | accountWizardStep = LOGIN;
351 | router.navigateTo(LOGIN_SCREEN);
352 | }
353 |
354 | @Override
355 | public void infoWizardBack() {
356 | router.finishChain();
357 | }
358 | };
359 |
360 | private final LoginWizardPart loginWizardPart = new LoginWizardPart() {
361 |
362 | @Override
363 | public void loginWizardSuccess() {
364 | router.finishChain();
365 | accountWizardPart.onSuccess();
366 | }
367 |
368 | @Override
369 | public void loginWizardBack() {
370 | router.finishChain();
371 | accountWizardPart.onBack();
372 | }
373 |
374 | @Override
375 | public void loginWizardNewAccount() {
376 | accountWizardStep = REGISTRATION;
377 | router.navigateTo(REGISTRATION_SCREEN);
378 | }
379 | };
380 |
381 | private final RegistrationWizardPart registrationWizardPart = new RegistrationWizardPart() {
382 |
383 | @Override
384 | public void registrationWizardSuccess() {
385 | router.finishChain();
386 | accountWizardPart.onSuccess();
387 | }
388 |
389 | @Override
390 | public void registrationWizardBack() {
391 | accountWizardStep = LOGIN;
392 | router.backTo(LOGIN_SCREEN);
393 | }
394 | };
395 |
396 | public AccountWizardSmartRouter(Router router,
397 | AccountWizardPart accountWizardPart) {
398 | this.router = router;
399 | this.accountWizardPart = accountWizardPart;
400 | }
401 |
402 | public void startWizard() {
403 | if (accountWizardStep != NONE) {
404 | return;
405 | }
406 | accountWizardStep = INFO;
407 | router.navigateTo(INFO_ACCOUNT_SCREEN);
408 | }
409 |
410 | public InfoWizardPart getInfoWizardPart() {
411 | return infoWizardPart;
412 | }
413 |
414 | public LoginWizardPart getLoginWizardPart() {
415 | return loginWizardPart;
416 | }
417 |
418 | public RegistrationWizardPart getRegistrationWizardPart() {
419 | return registrationWizardPart;
420 | }
421 |
422 | }
423 | ```
424 |
425 | Особо ничего нового за исключением того, что в необходимых местах дергается ```AccountWizardPart```.
426 | Данный визард с технической точки зрения реализован точно также, как мы до этого реализовывали ```MainWizardSmartRouter```. То есть это:
427 | - android: отдельная активити (```AccountActivity```) с тремя фрагментами (```InfoAccountFragment```, ```LicenseFragment```, ```RegistrationFragment```),
428 | - dagger2: два модуля (```AccountWizardModule```, ```AccountNavigationModule```), замыкающихся в одном компоненте (```AccountWizardComponent```) со своим скоупом (```AccountWizardScope```). ```AccountWizardComponent``` является сабкомпонентом от ```WizardComponent```.
429 |
430 | Все подробности вы можете самостоятельно просмотреть в [примере, ветка sample_3](https://github.com/AndroidArchitecture/WizardCase/tree/sample_3).
431 | А что же поменялось для ```MainWizardSmartRouter```? Давайте посмотрим на код:
432 | ```java
433 | public class MainWizardSmartRouter {
434 |
435 | private final Router router;
436 | private MainWizardStep currentMainWizardStep = MainWizardStep.NONE;
437 |
438 | private final InfoWizardPart infoStartWizardPart = new InfoWizardPart() {
439 |
440 | @Override
441 | public void infoWizardNext() {
442 | currentMainWizardStep = MainWizardStep.LICENSE;
443 | router.navigateTo(LICENSE_SCREEN);
444 | }
445 |
446 | @Override
447 | public void infoWizardBack() {
448 | router.finishChain();
449 | }
450 |
451 | };
452 |
453 | private final LicenseWizardPart licenseWizardPart = new LicenseWizardPart() {
454 |
455 | @Override
456 | public void licenseWizardAccept() {
457 | currentMainWizardStep = MainWizardStep.ACTIVATION;
458 | router.navigateTo(ACTIVATION_SCREEN);
459 | }
460 |
461 | @Override
462 | public void licenseWizardBack() {
463 | currentMainWizardStep = MainWizardStep.START_INFO;
464 | router.backTo(INFO_START_SCREEN);
465 | }
466 |
467 | };
468 |
469 | private final ActivationWizardPart activationWizardPart = new ActivationWizardPart() {
470 |
471 | @Override
472 | public void activationWizardPersonalAccountNext() {
473 | router.navigateTo(ACCOUNT_SCREEN);
474 | }
475 |
476 | @Override
477 | public void activationWizardFreeNext() {
478 | currentMainWizardStep = MainWizardStep.FINISH_INFO;
479 | router.navigateTo(INFO_FINISH_SCREEN);
480 | }
481 |
482 | @Override
483 | public void activationWizardBack() {
484 | currentMainWizardStep = MainWizardStep.LICENSE;
485 | router.backTo(LICENSE_SCREEN);
486 | }
487 |
488 | };
489 |
490 | private final AccountWizardPart accountWizardPart = new AccountWizardPart() {
491 |
492 | @Override
493 | public void onSuccess() {
494 | currentMainWizardStep = MainWizardStep.FINISH_INFO;
495 | router.navigateTo(INFO_FINISH_SCREEN);
496 | }
497 |
498 | @Override
499 | public void onBack() {
500 | currentMainWizardStep = MainWizardStep.ACTIVATION;
501 | router.backTo(ACTIVATION_SCREEN);
502 | }
503 |
504 | };
505 |
506 | private final InfoWizardPart infoFinishWizardPart = new InfoWizardPart() {
507 |
508 | @Override
509 | public void infoWizardNext() {
510 | router.finishChain();
511 | }
512 |
513 | @Override
514 | public void infoWizardBack() {
515 | router.finishChain();
516 | }
517 |
518 | };
519 |
520 | public MainWizardSmartRouter(Router router) {
521 | this.router = router;
522 | }
523 |
524 | public void startWizard() {
525 | if (currentMainWizardStep != MainWizardStep.NONE) {
526 | return;
527 | }
528 | currentMainWizardStep = MainWizardStep.START_INFO;
529 | router.navigateTo(INFO_START_SCREEN);
530 | }
531 |
532 | public InfoWizardPart getInfoStartWizardPart() {
533 | return infoStartWizardPart;
534 | }
535 |
536 | public LicenseWizardPart getLicenseWizardPart() {
537 | return licenseWizardPart;
538 | }
539 |
540 | public ActivationWizardPart getActivationWizardPart() {
541 | return activationWizardPart;
542 | }
543 |
544 | public InfoWizardPart getInfoFinishWizardPart() {
545 | return infoFinishWizardPart;
546 | }
547 |
548 | public AccountWizardPart getAccountWizardPart() {
549 | return accountWizardPart;
550 | }
551 |
552 | }
553 | ```
554 |
555 | По сути добавился еще один ```...wizardPart``` интерфейс и все. А то, что под этим ```AccountWizardPart``` скрывается отдельный Визард, ```MainWizardSmartRouter``` не знает. И в этом основная красота построения Визардов через **SmartRouter** и интерфейсы **...wizardPart**.
556 | В итоге подобное построение Визардов позволяет достигнуть обозначенных выше целей.
557 |
--------------------------------------------------------------------------------
/ebook/Android Architecture Book.epub:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/AndroidArchitecture/AndroidArchitectureBook/4efbb9eb3665969b166a3123f3579a692dd8a270/ebook/Android Architecture Book.epub
--------------------------------------------------------------------------------
/practice/Practice_article.md:
--------------------------------------------------------------------------------
1 | Раунд практических вопросов в виде "Проблема-Решение".
2 | Некоторые вопросы перекликаются с теми, что были рассмотрены в Теории.
3 |
4 | ----------
5 |
6 | **Проблема**
7 | Организация DI в проекте. Какая сущность ответственна за создание и удаление компонента?
8 |
9 | **Решение**
10 | Ответ от одного из участников чата, на примере популярного фреймворка Dagger 2.
11 | В Application хранится ссылка на ComponentManager. Его задача инициализировать и отдавать компоненты по запросу. Есть AppComponent, который предоставляет базовые зависимости, которые нужны везде. Его мы обычно Singleton скопом помечаем. Далее используем subComponent с другими скоупами, жизненным циклом которых мы управляем сами через componentManager. SubComponent продумываем таким образом, чтобы он использовался для конкретных задач логически связанных.
12 | Например, нам нужен компонент, который будет предоставлять зависимости только для работы с новостройками (это из нашего проекта). Т.е этот компонент предоставляет нам все необходимые классы для работы с новостройками/конкретной новостройкой, фильтрами и т.д. (Презентер, Интерактор, Репозиторий и прочие вспомогательные классы). Соответственно нам нужен компонент, и вот тут идет в ход componentManager и subComponent. Мы открываем активити или фрагмент, отвечающая за новостройки, и в методе onCreate просим componentManager предоставить нужный компонент. Пусть будет BuildingsComponent. Чтобы память не текла нужно сабкомпоненты занулять когда активити финиширует (это делает все тот же componentManager, т.к ссылки на компоненты хранятся в нем). В данном активити/фрагменте инжектим Презентер, а далее происходит уже инициализация всего дерева зависимостей BuildingsComponent.
13 | **Главная мысль:** компоненты Даггера должны храниться в специальном контейнере синглтоне, например, ComponentManager.
14 |
15 | #DI #Dagger2
16 |
17 |
18 | ----------
19 |
20 | **Проблема**
21 | Детальный пример, показывающий, как писать с использованием Чистой архитектуры. Как создаются слои, и за что каждый класс отвечает?
22 |
23 | **Решение**
24 | Рекомендуем серию статей:
25 |
26 | [Android Architecture: Part 1 - every new beginning is hard](http://five.agency/android-architecture-part-1-every-new-beginning-is-hard/)
27 | [Android Architecture: Part 2 - the clean architecture](http://five.agency/android-architecture-part-2-clean-architecture/)
28 | [Android Architecture: Part 3 - Applying clean architecture on Android](http://five.agency/android-architecture-part-3-applying-clean-architecture-android/)
29 | [Android Architecture: Part 4 - Applying Clean Architecture on Android, Hands on (source code included)](http://five.agency/android-architecture-part-4-applying-clean-architecture-on-android-hands-on/)
30 | [Android Architecture: Part 5 - How to Test Clean Architecture](http://five.agency/android-architecture-part-5-how-to-test-clean-architecture/)
31 |
32 | Очень грамотное теоретическое описание трансформации классической Clean Architecture от дядюшки Боба в Clean Architecture для Android.
33 | Единственное, вторая статья как-то немного запутала с этими input/output портами для UseCase и решением проблемы флоу данных через наследование и композицию. Немного оторвано от практики, как мне показалось. Лучше сразу к третьей части приступить, если вы также не совсем поняли.
34 | Еще есть моменты, над которыми можно похоливарить.
35 |
36 | #пример #статьи
37 |
38 | ----------
39 |
40 | **Проблема**
41 | Как проектировать? Сверху вниз или снизу вверх?
42 |
43 | **Решение**
44 | Лучше первый вариант, так как он быстрее позволяет получить первый результат в виде работающего приложения, пускай и с моками.
45 |
46 | #проектирование
47 |
48 |
49 | ----------
50 |
51 |
52 | **Проблема**
53 |
54 | Как организовать поведение схожее с Инстаграмом. То есть ты ставишь лайк, и на UI сразу же все отображается. При этом параллельно идет запрос, прочая логика. И в конце концов запрос может провалиться.
55 |
56 | **Решение**
57 |
58 | Варианты решения.
59 |
60 | 1. Локальное состояние как single source of truth. UI мониторит локальное состояние - подписывается на Subject/Flow. Это может быть кэш в памяти или база данных. Room так вообще из коробки может выдавать Observable/Flow для SQL-запросов.
61 | Пользователь жмакает like. Локальное состояние немедленно обновляется и UI получает update (он же подписан, значит автоматом прилетит обновление).
62 | В этот момент асинхронно идёт запрос на сервер. Если он ок, то всё, ничего не трогаем. Если не ок, то откатываем локальное состояние, UI получает update - откат, и можем пользователю показать сообщение об ошибке (toast, например).
63 | Тут получится так, что лайк мигнёт, но это ок. Многие соцсети так и делают.
64 |
65 | 2. Вариант с откатом состояния UI можно сделать и без локального состояния. Просто сразу обновляем UI и откатываем в случае фэйла запроса. Тут может быть проблема если одно и то же состояние отображается в разных местах. Например, лайки могут быть в ленте, при открытии поста, так же есть счётчик лайков. И все эти отображения надо не забыть обновлять и откатывать в случае ошибки. Поэтому вариант с единым состоянием и мониторингом его выглядит предпочтительнее.
66 |
67 | 3. Можно складывать запросы в очередь в базу и синхронизировать по возможности. Этот вариант сложен в реализации. И пользователь может долго не узнать, что у него проблемы с соединением. Поэтому его стоит рассматривать если пользователь реально должен что-то делать в оффлайне и понимает, что синхронизация может произойти не сразу.
68 |
69 | 4. Так же iOS кидали в сторону CQRS
70 | http://blog.softmemes.com/2016/11/12/using-cqrs-with-event-sourcing/
71 | https://martinfowler.com/bliki/CQRS.html
72 |
73 | #CQRS
74 |
75 |
76 | ----------
77 |
78 | **Проблема**
79 |
80 | Структура пакетов и размещение файлов. Должны ли интерфейсы быть отделены от имплементаций, или они могут находиться в одном пакете?
81 |
82 | **Решение**
83 |
84 | В проектах с чистой архитектурой, чаще всего пакеты формируют по фичам или слоям. Примеры есть в статье http://www.javapractices.com/topic/TopicAction.do?Id=205.
85 | Примерная структура проекта может быть такой:
86 | ```
87 | project
88 | ├─ di
89 | │ ├─ app
90 | │ ├─ payments
91 | │ └─ operation
92 | ├─ presentation
93 | │ ├─ view
94 | │ │ ├─ payments
95 | │ │ │ ├─ PaymentsView
96 | │ │ │ └─ PaymentsFragment
97 | │ │ └─ operations
98 | │ │ ├─ OperationsView
99 | │ │ └─ OperationsFragment
100 | │ └─ presenter
101 | │ ├─ payments
102 | │ │ └─ PaymantsPresenter
103 | │ └─ operations
104 | │ └─ OperationsPresenter
105 | ├─ domain (он же business)
106 | │ ├─ payments
107 | │ │ ├─ PaymentsInteractor
108 | │ │ ├─ PaymentsInteractorImpl
109 | │ │ └─ CurrencyHandler (вспомогательный класс для PaymentsInteractor)
110 | │ └─ operations
111 | │ ├─ OperationsInteractor
112 | │ ├─ rubs
113 | │ │ ├─ OperationsInteractorRubs
114 | │ │ └─ RubsManager (вспомогательный класс для OperationsInteractorRubs)
115 | │ └─ currency
116 | │ ├─ OperationsInteractorCurr
117 | │ └─ CurrencyManager (вспомогательный класс для OperationsInteractorCurr)
118 | ├─ repositories
119 | │ ├─ payments
120 | │ │ ├─ PaymentsRepository
121 | │ │ └─ PaymentsRepositoryImpl
122 | │ └─ operations
123 | │ ├─ OperationsRepository
124 | │ └─ OperationsRepositoryImpl
125 | ├─ data
126 | │ ├─ network
127 | │ └─ db
128 | └─ models (по сути хранилище всех dto)
129 | ├─ payments
130 | │ ├─ PaymentsModel
131 | └─ operations
132 | ├─ presentation
133 | │ └─ OperationUIModel
134 | ├─ domain
135 | │ ├─ OperationsRubModel
136 | │ └─ OperationCurrModel
137 | └─ data
138 | ├─ OperationsRubNetworkModel
139 | └─ OperationCurrNetworkModel
140 | ```
141 |
142 | Разбивать только по слоям или фичам не всегда бывает удобно, поэтому гибридный вариант, когда внутри одного пакета слоя могут быть пакеты с фичами, вполне приемлем.
143 |
144 | Иногда проект разбивают на модули, чаще всего делаю отдельный модуль для каждого слоя приложения.
145 |
146 | Подробнее в нашей Теории.
147 |
148 | #структура #общиепрактики
149 |
150 | ----------
151 |
152 | **Проблема**
153 |
154 | Нужен ли Dagger 2 для реализации DI? В чем профит данной библиотеки?
155 |
156 | **Решение**
157 |
158 | Dagger 2 не является необходимым условием для реализации DI. Но многие специалисты (например, Марк Симан в книге Dependency Injection in .NET) настоятельно рекомендуют использовать готовое решение для реализации DI. Реализацию DI без использования библиотеки называют "DI для бедных".
159 | Dagger 2 имеет следующие преимущества перед "ручной" реализации:
160 |
161 | - Управление жизненным циклом зависимостей
162 | - Генерация кода для создания зависимостей
163 |
164 | Еще поговаривают про [toothpick](https://github.com/stephanenicolas/toothpick), как альтернативу Даггера.
165 |
166 | #DI #библиотеки #Dagger2
167 |
168 | ----------
169 |
170 | **Проблема**
171 |
172 | Что делать, если клиент для работы с БД или сетью может поменяться?
173 |
174 | **Решение**
175 |
176 | Если мы знаем, что работа с бд у нас может поменяться, то можем ввести специальный DbFacade, скажем. У него будет единый интерфейс, но две разные реализации. Получается, что DbFacade будет посредине между репозиторием и непосредственно работой с БД. Таким образом, Репозиторий просто дергает этот DBFacade, а как именно идут в БД запросы, его не волнует. Кроме того Фасад будет отдавать в Репозиторий какую-то единую модель. То есть у каждого клиента могут быть свои модели для запросов и ответов, но наружу отдается какая-то единая. Это все для того, чтобы внедрение нового клиента проходило максимально безболезненно.
177 |
178 | #repository #designpatterns
179 |
180 | ----------
181 |
182 | **Проблема**
183 |
184 | Репозиторий и его место?
185 |
186 | **Решение**
187 | Начнем с того, что понятие "Репозиторий" несколько трансформировалось в Андроиде. Более подробно лучше почитать [здесь ](http://hannesdorfmann.com/android/evolution-of-the-repository-pattern).
188 | В чистой архитектуре дядюшки Боба интерфейсы репозиториев принадлежат слою бизнес-логики. А реализация интерфейсов к слою Дата. Бизнес-логика ничего не знает о моделях Даты, она получает уже готовые бизнес-модели. Репозиторий отвечает за маппинг данных, выбор источников данных, а также за кеширование. Интерактору выдается просто готовые модели.
189 | Есть возражения, что если осуществлять еще и кеширование, то как-то много всего будет в Репозитории. Ну тут остается только посоветовать - делегируйте во вспомогательные классы. У Фернандо показан хороший пример делегирования через Фабрику и DataStore (в [статье Ханнеса](http://hannesdorfmann.com/android/evolution-of-the-repository-pattern), раздел Evolution of the Repository Pattern term). Там фабрика решает, какой DataStore задействовать для конкретного id.
190 | Если для принятия решения о кешировании нужна информация с другого Репозитория, то пускай Интерактор передаст через аргумент метода нужную инфу в Репозиторий. Вообщем тут Интерактор отвечает за взаимодействием и необходимый обмен информацией между Репозиториями. Например у одного репозитория запросил, какой режим сейчас (пользовательский или демо), а в другой репозиторий передал эти данные для получения корректного списка операций.
191 |
192 | ``` java
193 | modeRepository.getMode()
194 | .flatMap(mode -> operationsRepository.getOperations(mode))
195 | ```
196 |
197 | Исходя из вышесказанного, Репозиторий должен тестироваться.
198 | Если вам нужно сделать приложение быстро, можно, конечно, не заморачиваться с маппингом, а передавать модель, полученную с запроса. Но если приложение чуть более серьезное и долгое, то лучше маппить. Так как по опыту, в Дата-уровне или в логике получения данных всегда что-то может поменяться. Бизнес-логика про это вообще не должна знать.
199 |
200 | #repository #designpatterns
201 |
202 | ----------
203 |
204 | **Проблема**
205 |
206 | Работа с кешом и со списком. Как данные получать, где хранить список (презентер, репозиторий), как обрабатывать ЖЦ?
207 |
208 | **Решение**
209 |
210 | Любые данные, которые хранятся во View могут быть потеряны, если не предпринять мер для их сохранения. Сохранение данных, которые находятся во View является настолько частым кейсом для Android, что из коробки предоставляются некоторые инструменты для сохранения и восстановления данных. Однако по ряду причин, такие инструменты не всегда удобны.
211 |
212 | 1. Возможные утечки памяти
213 | 2. Необходимость реализации Parcelable
214 | 3. Такие инструменты, как Loader навязывают противоречивые подходы
215 |
216 | На наш взгляд, эффективнее решения, которые основаны на том, что данные, сетевые и локальные запросы будут хранится в компонентах, которые переживают View. Например, на таком подходе основана MVP библиотека [Moxy](https://github.com/Arello-Mobile/Moxy).
217 |
218 | #lifecycle #design-patterns
219 |
220 | ----------
221 |
222 | **Проблема**
223 |
224 | Где должны располагаться Android не UI классы (ContactProvider, CallendarProvider, GoogleApiClient, Service)?
225 |
226 | **Решение**
227 |
228 | Мы думаем, что такие классы должны использоваться в Data слое на уровне с той же сетью или БД. Этим мы добиваемся того, что в бизнес-логике не будет Android классов. Ну и плюс получается вполне корректное разделение по слоям.
229 | Причем пользователи Репозитория не должны догадываться, что для получения данных, под капотом используется, например Сервис.
230 | Как это примерно выглядит.
231 | Есть интерфейс Репозитория. Скажем, IAppRepository
232 | У него есть метод :
233 |
234 | ```java
235 | public Observable getLocation()
236 | ```
237 |
238 | В конкретной реализации интерфейса - AppRepository будет такой код примерно:
239 |
240 | ```java
241 | public Observable getLocation() {
242 | return geoApiProvider.getLocation()
243 | }
244 | ```
245 |
246 | geoApiProvider - это специальный класс, которому мы делегируем работу с сервисом и т.д. Внутри у этого класса будет работа с сервисом и Subject, через который будут отдаваться данные. Заметим, что наружу мы выдаем не Subject, а Observable - ни к чему пользователям знать большее.
247 | Могут быть вопросы по тому, а как потом убить сервис, если он стартующий, например.
248 | Желательно, конечно, спроектировать так, чтобы убийство происходило автоматом, например, при отписке последнего подписчика. Все зависит от задачи.
249 |
250 | #service #repository #designpatterns
251 |
252 | ----------
253 |
254 | **Проблема**
255 |
256 | Хранение данных в рантайме. Если нужно хранить какие-то состояния, но класть их в БД или SP нет необходимости. А где мне следует хранить данные, которые должны жить только в рантайме? Т.е. допустим, у меня приложение не кэширует что-то в бд. Получает данные и хранит пока приложение живо. У меня есть репозиторий, в нем по сути ретрофит, который берет данные из сети. Репозиторий сделал на случай если бд в дальнейшем понадобится, то будет удобно делать выборку из бд или сети в репозитории. А данные которые, хранятся в рантайме я тоже в репозитории хранить должен или какой-то манагер данных должен быть, в которого складываются данные из сети?
257 |
258 | **Решение**
259 |
260 | Persistence данные должны быть всегда сокрыты под Репозиторием.
261 | Если есть данные, которые вы пока храните Runtime, но потом скорее всего потом будете Persistence, то эти данные можно сокрыть под Репозиторием и хранить их, например, в HeapStorage.
262 |
263 | #repository #designpatterns
264 |
265 | ----------
266 |
267 | **Проблема**
268 |
269 | Большой интерактор (Интерактор в понимании UseCase feature facade). Куда выносить код из интеракторов? У меня в одном уже 1000 строк кода, и это еще Rx + Retrolambda. Методы только те, которые выполняют какие-либо операции на экране.
270 |
271 | **Решение**
272 |
273 | Можно реализовать интерактор по паттерну Фасад. Данный интерактор будет уже дергать соответствующие вспомогательные классы. И интерфейс бизнес-логики у нас будет единым, что очень удобно при дальнейшем сопровождении.
274 | По опыту одного из админов. Была задача встроить чат в одно банковское приложение. И там было очень много логики. Но так как это одна бизнес-фича, то был сделан один Интерактор по Фасаду. В имплементации он по сути просто дергал вспомогательные классы. Написаны были ещё некоторые функциональные тесты. И вот спустя 9 месяцев руководство для реализации чата решило использовать не стороннюю либу, а свою. А это другой интерфейс и вообще другая логика отправки сообщений и прослушки входящих. Поэтому просто подменой data уровня было не спастись. Но ui тот же остаётся.
275 | И вот тогда действительно сыграло на руку такое решение с интерактором. Была просто произведена подмена Интерактора без затрагивания View и Presenters, где было тоже немало всего. И оно заработало с первого раза =)
276 |
277 | #facade #interactor #designpatterns
278 |
279 | ----------
280 |
281 | **Проблема**
282 |
283 | Презентер и Интерактор. Могут ли быть в Презентере сразу несколько Интеракторов?
284 |
285 | **Решение**
286 |
287 | Зависит от ситуации. Если для обработки ЖЦ вы используете специальные библиотеки типа Moxy, и вам ничего не нужно кешировать и как-то обрабатывать возможные нестыковки при переориентации экрана, то жизнь заметно упрощается, и тогда в Презентере можно стыковать несколько Интеракторов.
288 | Но опять-таки, только стыковать. Если необходимо добавлять какую-то бизнес-логику, выносите это в Интеракторы.
289 |
290 | #presenter #interactor
291 |
292 | ----------
293 |
294 | **Проблема**
295 |
296 | One direction flow. Частая ошибка - презентер становится хелпером для вью.
297 |
298 | **Решение**
299 | На наш взгляд, правильное применение MVP заключается в следующем (только о взаимодействии верхних слоев - Presenter и View):
300 | 1) One direction data flow, методы в интерфейсе View должны иметь только методы, которые возвращают void)
301 | 2) Распределение ответственности: View - представление и никакой логики. Presenter - обработка событий View
302 | 3) Чувство меры: как и в любой технологии тут важно уметь остановиться. Прокидывание абсолютно всего через презентер создают метод-хелл.
303 | Часто встречается в Презентере код типа view.getSearchString. Презентер ничего не должен возвращать в своих методах, так как вьюха должна быть глупой, и не ей решать когда и что получать. Нужно будет - презентер сам ей данные передаст, и скажет что с ними делать.
304 | View ничего не возвращает, потому что:
305 | а) View может и не быть
306 | б) Иногда View может быть несколько, с какой брать?
307 | в) Самое главное - View с презентером работает по событийной модели: если презентер должен реагировать на изменение в EditText, то View должна сказать что текст поменялся, и передать текущий текст. Это как в армии - есть караульный (View), есть начальник караула (презентер). Начальник караула не должен постоянно опрашивать караульных, что у тех происходит. Наоборот, это караульный, если что-то произошло, должен доложить начальнику.
308 | #onedirectionflow #mvp
309 | ----------
310 |
311 |
312 | **Проблема**
313 | Есть следующая задача: перед каждым 4-ым вызовом некоторого апи нужно показывать рекламный блок. Как правильно сделать?
314 |
315 | **Решение**
316 | Проверка на уровне интерактора. То есть у репозитория два метода: getData и getAds.
317 | А интерактор считает когда нужно показывать данные, а когда рекламу, в нём логика.
318 |
319 | #бизнес-логика
320 |
321 | ----------
322 |
323 | **Проблема**
324 | Есть RecyclerView с различными разнообразными ViewHolder. В одном item списка может быть семь EditText, в другом - другие компоненты. У каждого item своя логика валидации и прочее. Возникает риск распухания ViewHolder'ов и намешивания в них бизнес-логики.
325 |
326 | **Решение**
327 | Советуем посмотреть в сторону [решения](http://hannesdorfmann.com/android/adapter-delegates), описанного у Дорфмана.
328 | Библиотека позволяет создавать классы - делегаты для вашего адаптера. Для отображения элемента списка библиотека умеет находить нужный делегат, зарегистрированный в DelegatesManager. Таким образом в коде адаптера отсутствуют конструкции switch или else if для выбора типа элемента, а добавление новых типов элементов становится очень простым.
329 | В делегаты вы можете инжектить Презентеры, через которые провайдите действия пользователя. Однако бывают случаи, когда один item переиспользуется во многих местах, и этот item отвечает, например, за "like". Инжектить Презентер бывает не очень удобно, так как тогда возникает дублирование кода и протягивание лишних зависимостей, чтобы в конце концов выполнить нужный UseCase.
330 | Поэтому можно заинжектить в данный делегат специальный Интерактор, который как раз и выполняет нажатия.
331 |
332 | #библиотеки #adapter-delegates #recyclerview
333 |
334 |
335 | ----------
336 |
337 |
338 | **Проблема**
339 | А как правильно реализовывать логику выбора данных из кэша или из сети? Что если иногда надо брать из кэша, а иногда из сети? Правильно ли делать в репозитории методы типа getfromnetwork и getfromcache? Например в случае если pull-to-refresh ту рефреш, то это обязательно из сети, а в каких-то других случаях можно и из кэша взять. Или например есть ситуация: есть объект, мне сначала нужно сделать бизнес-операцию над ним, далее показать, паралельно отправить запрос в облако, для обновления данных об объекте, и когда запрос выполнится, отобразить актуальные данные из сети. По сути мне нужно знать о существовании разных источников данных на уровне бизнес логики. Тогда какая часть должна быть в репозиторие?
340 |
341 | **Решение**
342 | Логика получения данных, в общем случае, хранится в специальном классе на уровне модели. Далее возможно иметь 2 кейса:
343 | 1) Менеджер источников данных (например, SmthDataStoreFactory) инжектится в SmthRepository и сам решает, как вытаскивать данные - из сети или кэша.
344 | 2) В случае, когда бизнес логике важно, чтобы данные пришли свежими, отправляется специальный флаг типа "needFreshData", его получает менеджер и понимает, что кэш в данном случае не прокатит, делает запрос на сервер. Если нужна более гибкая настройка, можно использовать различные стратегии для выборки данных, FirstCache, NoCache и т.д.. В репозитории будут методы с сигнатурой, getUser(int id, boolean needFreshData) или getUser(int id, CachePolicy policy).
345 |
346 | Методы, вроде getfromnetwork и getfromcache использовать можно, у такого подхода есть плюс, по сравнению с подходом, когда используется менеджер источников данных (SmthDatatStoreFactory) - не будет заглушек вроде UnsupportedOperationException на методы, которые актуальны для одних источников, но не поддерживаются в других. Из минусов, не получится, поменять источник данных, не затронув при этом реализации зависящих классов.
347 |
348 | #repository #design-patterns #бизнес-логика
349 |
350 | ----------
351 |
352 | **Проблема**
353 | Мне необходимо загрузить список (есть local и remote data source). Т.е. сначала необходимо отобразить данные из local, и потом делать запрос к серверу. Является ли это бизнес-логикой, или эту логику необходимо вынести в Repository?
354 |
355 | **Решение**
356 | Зависит от требований к приложению, глобально есть два подхода:
357 | 1) умный кэш (тогда это на уровне репозитория, а интерактор только просит данные);
358 | 2) глупый репозиторий (репозиторий только знает как достать данные, а интерактор сам говорит откуда и когда);
359 |
360 | #repository #design-patterns #бизнес-логика
361 |
362 | ----------
363 |
364 | **Проблема**
365 | После некоторого действия пользователя показывается SnackBar с кнопкой Отмена. Если успеть ее нажать, то действие надо отменить. Как лучше это сделать.
366 |
367 | **Решение**
368 | Презентер сообщает действие интерактору только по событию: "SnackBar скрылся", то есть только после того как пользователь решил не отменять действие. Важно: надо заранее учесть, что пользователь может сразу после действия выйти с экрана или приложения. Тогда надо принять решение - либо также передать действие интерактору при деттаче вью, либо считать такое поведение пользователя тоже отменой действия.
369 |
370 | #бизнес-логика
371 |
372 | ----------
373 |
374 | **Проблема**
375 | Есть список элементов. По клику открывается информация о конкретном элементе. Можно ли передавать элемент через параметры нового экрана или надо в параметры класть только Id?
376 |
377 | **Решение**
378 | Правильнее передавать параметром только Id, а сами элементы будут закэшированы в репозитории.
379 | Так как в этом случае мы сможем получить всегда актуальную информацию из репозитория, а не устаревшую из параметров.
380 |
381 | #общие-практики
382 |
383 |
384 | ----------
385 |
386 | **Проблема**
387 | Может ли Presenter обращаться к Interactor за некоторыми константами (Interactor.ROOT_FOLDER_ID)?
388 |
389 | **Решение**
390 | Лучше чтобы презентер не знал о каких-то константах бизнес логики.
391 | Если эта константа дальше нужна для получения данных, то лучше сделать явный метод getRootFolderInfo() или что-то в этом роде.
392 |
393 | #бизнес-логика
394 |
395 |
396 | ----------
397 |
398 | **Проблема**
399 | Необходимо в тексте подсветить некоторые части с помощью спанов.
400 | Это бизнес логика, как лучше поступить?
401 |
402 | **Решение**
403 | Передавать из презентера массив пар строка-цвет и отрисовывать во вью.
404 | Или передавать всю строку, и массив из выделений (индекс начала, индекс конца, цвет)
405 |
406 | #бизнес-логика
407 |
408 | ----------
409 |
410 | **Проблема**
411 | Использовать контекст в Презентере и Интеракторе или нет?
412 |
413 | **Решение**
414 | Мы рекомендуем не использовать контекст в классах с бизнес-логикой. Так как, используя контекст в классах с бизнес-логикой мы нарушаем правило зависимостей (зависимости направлены в одну стороны, от внешних слоев ко внутренним). Если есть необходимость в платформозависимых классах в презентере или интеракторе, то можно воспользоваться инверсией зависимостей и передать в класс интерфейс для доступа к платформозависимому классу, а реализацию оставить в слое дата или представления.
415 | Приведем пример, нам нужно локализованную строку из Презентера передать во View. Без контекста вроде никак. И тут мы добавляем зависимость. И это только для получения строчки, не более. Но проблема в том, что последователи могут начать использовать контекст в Презентере не по назначению. А если контекст будет в Интеракторе, то теоретически наша бизнес-логика будет завязана на конкретную платформу, что делает ее не переиспользуемой (кейс переиспользования бизнес-логики где-то в другом месте, конечно, очень редкий в нашем мобильном мире, но все же).
416 | На самом деле есть способы избежать использования контекста в том же Презентере.
417 | Для доступа к ресурсам надо создать отдельную сущность, которая будет работать с контекстом только ради ресурсов, типа ResourceManager, и все.
418 | Проблема решаема, причем довольно малой кровью. Но зато наш код чистый и независимый.
419 |
420 | #context #dependency-inversion #resource-manager
421 |
422 | ----------
423 |
424 | **Проблема**
425 |
426 | В каких классах делать выбор Scheduler'ов?
427 |
428 | **Решение**
429 |
430 | Если посмотреть лекции дядюшки Боба, интерактор отвечает за бизнес логику и ничего не знает о внешних фреймворках, ui, db.
431 | То, что Андроид обязан работать с View только в главном потоке, знает только сам Андроид фреймворк. Соответственно, обязанность предоставить шедулер Android.mainThread() должна лежать снаружи от интерактора.
432 | Обязанность презентера - координировать вью и модель. Если вью необходимо, чтобы данные обрабатывались в главном потоке - мы явно указываем observeOn(AndroidSchedulers.mainThread()).
433 | SubscriveOn() происходит уже в интеракторе, или репозитории, которые владеют необходимой информацией о том, стоит ли выделить новый поток (который будет уже Андроид-независимым, как Schedulers.Io() или Schedulers.computation()).
434 |
435 | Пример:
436 |
437 | Презентер:
438 |
439 | ```java
440 | userInteractor.downloadUserInfo()
441 | .map(mapper::entityToView);
442 | .observeOn(AndroidSchedulers.mainThread())
443 | .subscribe(view::showUserInfo);
444 | ```
445 |
446 | Интерактор:
447 |
448 | ```java
449 | repository.downloadUserInfo();
450 | ```
451 |
452 | Репозиторий (в более сложном кейсе, Schedulers зависи от источника данных, тут упрощённый пример с нетворком):
453 |
454 | ```java
455 | api.downloadUserInfo()
456 | .subscribeOn(Schedulers.io)
457 | .map(mapper::networkToEntity);
458 | ```
459 |
460 | Переключение потоков может быть как частью бизнес-логики, так и частью слоя данных. Зависит от того, какой класс имеет необходимую информацию для принятия решения.
461 | При передаче между слоями можно всегда прокидывать данные через главный поток - таким образом, при получении observable в новом слое мы знаем, на каком потоке он выполнится. Минус подхода - зачастую, будут излишние переключения.
462 |
463 | #rxjava
464 |
465 | ----------
466 |
467 | **Проблема**
468 | От сервера в Repository приходит флаг, по которому необходимо разлогинить пользователя. Но перед этим мне необходимо почистить все данные пользователя (SharedPreferences, Database).
469 | Этот флаг может придти в любом запросе.
470 | Получается, что необходимо в каждый Repository Inject-ить LogoutResolver или реализовать эту логику на уровне BaseRepository?
471 |
472 | **Решение**
473 |
474 | Вариант 1:
475 | Ввести декоратор для репозитория, в который инжектится все необходимое для очистки данных. Однако, если у декоратора нет полной информации о том, как должны очищаться остальные репозитории (они могут хранить что-то в других преференсах, бд, файлах), то по-прежнему остаётся проблема того, что эти репозитории нужно как-то уведомить о необходимости очистки.
476 | Один из вариантов - создать список слушателей в декораторе, куда подключать все репозитории. В дальнейшем, если один репозиторий поймал событие о разлогине, уведомляются все репозитории-слушатели и выполняют свою логику по очистке.
477 | Недостаток: многовато кода и недостаточно легко масштабируемо.
478 |
479 | Вариант 2:
480 | Можно ввести специальную новую сущность, например, DataCleaner.
481 | Он будет инжектиться в интерсептор OkHttpClient, но при этом будет иметь доступ в БД и Преференсам, чтобы почистить их.
482 | То есть все будет разруливаться в дата слое без Репозитория и прочего.
483 | При этом, если есть, допустим, несколько файлов Преференсов, и их нужно все почистить, то для большего удобства можно ввести что-то вроде PreferencesFacade, который бы предоставлял унифицированный доступ ко всем файлам нужным. И собственно из Репозиториев тоже можно работать с преференсами через него. Тогда точно ничего не забудется.
484 |
485 | #decorator #facade #design-patterns
486 |
487 |
488 | ----------
489 |
490 | **Проблема**
491 | Есть активити с тулбаром, внутри которой переключаются фрагменты. Как из вьюшки (фрагмента) взаимодействовать с тулбаром (например поменять тайтл)?
492 |
493 | **Решение**
494 | Вариант 1:
495 | Тулбар в данном случае будет независимой вьюшкой, со своим собственным презентером. Презентер тулбара подписывается на модель (интерактор-репозиторий), которая хранит состояние тулбара. Эта модель является глобальной для всех презентеров внутри этой активити. Остальные презентеры при надобности имеют право писать в модель, а презентер тулбара должен соответственно реагировать на ее изменения.
496 |
497 | Вариант 2:
498 | Зачастую надобности в глобальном тулбаре нет. Тогда у каждого фрагмента можно сделать собственный тулбар. Поскольку в данном случае он будет являться частью текущей вьюшки, то презентер сможет обращаться к нему напрямую (например через метод во вью setTitle).
499 |
500 | #practices
501 |
502 | ----------
503 |
504 | **Проблема**
505 | Действительно ли в Чистой архитектуре нельзя в разных слоях использовать одни и те же модели данных, и их нужно перемапить, прежде чем отдать на слой выше? Не напряжно ли поддерживать такое количество классов, и не пахнет ли оно бойлерплейтом?
506 |
507 | **Решение**
508 | Чистая архитектура призывает иметь зависимости, направленные только во внутрь, а значит никто не мешает использовать Entity (бизнес сущности) в наружных слоях (например, Presentation или Data). Таким образом, в чистой архитектуре, достаточно иметь только Entities. Например, если сервер присылает данные в таком же формате, как и бизнес сущности, то особого смысла создавать новые модели данных нет, можно использовать Entitiy в качестве модели данных для сервера. Реальная надобность в мапперах возникает тогда, когда структура данных на разных слоях должна быть разной или в моделе данных необходимо иметь платформо(фреймворк) - специфическую зависимость, например, реализовать интерфейс RealmModel. Другой пример, в Presentation слое можно использовать бизнес сущности, но когда потребуется добавить в сущности дополнительные поля, специфические для UI (например, Color и т.д.), то имеет смысл сделать отдельную модель для слоя представления.
509 | Итого, строго по Чистой архитектуре, достаточно иметь только Entities (бизнес сущности), которые по правилу зависимостей, можно использовать во всех наружних слоях.
510 |
511 | #общие #чистая-архитектура
512 |
513 | ----------
514 |
515 | **Проблема**
516 | Обработка результата отдельного сценария
517 |
518 | 1) Имеется экран "Список карт лояльности"
519 | 2) На экране есть кнопка "Добавить новую карту"
520 | 3) При нажатии кнопки открывается визард, который состоит из цепочки активити
521 | 4) При прохождении сценария, нужно:
522 | - закрыть все экраны сценария
523 | - отобразить обновленный список карт
524 | - показать snack уведомление, что карта добавлена
525 |
526 | **Решение**
527 | Вариант 1.
528 | Дефолтными средствами Android SDK.
529 | Реализуем старт активити с помощью startActivityForResult и в onActivityResult при необходимости делаем finish()
530 |
531 | Вариант 2.
532 | На основе Cicerone
533 | Подробности можно посмотреть в @Cicerone_RUS
534 |
535 | Вариант 3.
536 | С использованием общего интерактора
537 | - Создаем интерактор, который доступен на экране списка карт лояльности и финальном экране визарда.
538 | - Всем активити визарда в манифесте устанавливаем значение taskAffinity как AddLoyaltyCardWizard
539 | - При добавлении карты на финальном экране происходит два действия:
540 | 1) Интерактор оповещается о добавлении карты. По этому действию он может инициировать обновление списка и отображение оповещения
541 | 2) Вызывается finishAffinity
542 |
543 | В данной реализации нужно обратить внимание на потенциальную возможность убийства активити системой.
544 |
545 | Как работает taskAffinity можно прочитать в https://developer.android.com/guide/topics/manifest/activity-element.html#aff
546 |
547 | #навигация #библиотеки
548 |
549 |
550 | ----------
551 |
552 | **Проблема**
553 | Модели данных
554 |
555 | **Решение**
556 | Репозиторий отдает уже готовые бизнес-модели. В Дате для работы с сетью, БД и т.д. используются свои модели данных. Интерактор преобразует полученные от Репозитория бизнес-модели в другие бизнес-модели (все зависит от кейсов). То есть Презентеру отдаются преобразованные бизнес-модели. Презентер же может создать свои UI-модели или просто использовать полученные. Интерактор ничего не знает о моделях данных Data или UI.
557 | Также по моделям. Чтобы уменьшить boilerplate код, можно использовать модели-обертки. Например, есть бизнес-модель, но для UI нужны дополнительные атрибуты. Тогда можно создать UI модель, в которой будет сама бизнес-модель и необходимые UI атрибуты.
558 |
559 | #repository #design-patterns #layers-architecture
560 |
561 | ----------
562 |
563 |
564 | **Проблема**
565 | Имеется репозиторий, который сливает поток сообщений из БД (приходят мгновенно) и из сети (с задержкой), презентер подписан на эти изменения (Rx). Проблема в том, что если репозиторий возвращает обсервабл с сообщениями, я не могу узнать, что произошла проблема с получением данных из сети. Если я кину exception в момент получения данных с сети, у меня могут не сработать onNext для сообщений с базы и они не отобразятся. Если же я просто поглощу ошибку в момент получения данных из сети, у пользователя отобразятся только закешированные данные и я не увижу, что что-то пошло не так, чтобы предупредить пользователя.
566 |
567 | **Решение**
568 | Можно сделать враппер-модель и в него записывать данные + информация о провайдере данных + ошибка, если такая была.
569 |
570 | #rx #design-patterns #error-handling
571 |
572 | ----------
573 |
574 | **Навигация**
575 | Как лучше строить навигацию в MVP приложении? При этом если еще хотелось бы и вьюшки шарить (которые андроидовские) для использования в shared view анимации? Как реализовать навигацию, как в Инстаграм?
576 |
577 | **Решение**
578 | Как основное решение, которое подходит для большенства приложений, мы рекомендуем библиотеку [Cicerone](https://github.com/terrakok/Cicerone). Подробно с подходами, которые предложены в библиотеке можно ознамоиться на странице библиотеки на github.
579 | Также возможен вариант для простого приложения с маленьким количеством экранов. Презентер вызывает метод во View "navigateToScreen()", а в методе navigateToScreen код перехода.
580 |
581 |
582 |
583 | **Проблема**
584 | При любом запросе нам может вернуться ошибка - истекла сессия. Как это вписать в Чистую архитектуру?
585 |
586 | **Решение**
587 | Подробное решение предложено [здесь](https://github.com/AndroidArchitecture/AndroidArchitectureBook/blob/master/cases/auth/Auth_article.md)
588 |
589 | #clean-architecture #практики
590 |
591 | ----------
592 |
593 | **Проблема**
594 | Кейс. Реализация поведения в зависимости от типа устройства.
595 |
596 | **Решение**
597 | Пускай за получение состояния - телефон или планшет, отвечает специальный репозиторий, например AppRepository, отвечающий за хранения таких вот глобальных вещей. Ну и собственно Интерактор будет дергать данный репозиторий и решать, что делать дальше, а презентеру и вьюшке будет все равно .
598 |
599 | #repositories #практики
600 |
601 | ----------
602 |
603 | **Проблема**
604 | Типичная корзина в мобильном магазине. С корзиной приходится работать практически со всех концов приложения.
605 |
606 | **Решение**
607 | Создайте компонент BasketComponent с модулем BasketModule.
608 | В этом компоненте будет BasketInteractor и BasketRepository.
609 | Собственно эти классы будут отвечать за все расчеты и походы в сеть.
610 | Те экраны, которые будут производить манипуляцию с корзиной, будут иметь свои компоненты, дочерние по отношению к BasketComponent.
611 | Собственно в этих дочерних компонентах внутри их Интеракторов и будут дергаться нужные методы BasketInteractor.
612 | То есть логика управления корзиной будет сокрыта в BasketInteractor, а BasketInteractor будет дергаться из соответствующих интеракторов.
613 |
614 | #clean-architecture #практики #design-patterns
615 |
616 | ----------
617 |
618 | **Проблема**
619 | Всегда ли нужен Интерактор? Можно ли в Презентере использовать сразу Репозиторий, если логика предельна проста, и Интерактор в данном случае выступает просто провайдером запросов в Репозиторий?
620 |
621 | **Решение**
622 | Интерактор нужен всегда. Большое количество мобильных приложений не имеют сложной бизнес-логики и интерактор в них будет только вызывать методы репозитория. Но есть несколько моментов в пользу подхода всегда делать интеракторы.
623 | Первый момент. Иметь отдельный класс, который инкапсулирует в себе логику получения данных очень полезно.
624 | Пример, во многих частях приложения нам необходимо получать из репозитория выбранную локаль. Мы во всех презентерах использовали напрямую репозиторий. Теперь задача поменялась, если в репозитории нет выбранной локали (пользователь еще не выбрал, почистили данные приложения и т.д.), тогда мы должны вернуть локаль по умолчанию, например Москва. Чтобы не делать это во всех презентерах, мы идем в наш репозиторий и дописываем туда код для дефолтной локали. При этом забываем, что где-то еще метод репозитория использовал другой интерактор, которому было важно знать, что пользователь еще не выбрал локаль, а теперь он этого не узнает, так как будет думать, что пользователь выбрал Москву. Если бы мы имели отдельный интерактор для получения выбранной локали, даже с одним вызовом репозитория, то такой проблемы не было бы.
625 | Второй момент, это удобство для тех людей, которые будут работать с проектом.
626 | Представьте, у вас есть презентер, в который инжектится StoreRepository, в котором пара десятков методов. Легко сказать, что происходит в этом презентере? А если в него инжектится GetStoresByMyLocationInteractor? Во втором варианте разобраться проще, что происходит в презентере, даже несмотря на его код. И ничего страшного, что в GetStoresByMyLocationInteractor всего пара строчек кода.
627 | Третий момент, это единообразие. Мы привыкаем всегда писать отдельный класс для работы с репозиторием и вся команда использует один подход. А не два подхода, когда можно инжектить интерактор или репозиторий.
628 | Можно еще найти плюсы. А из минусов только, то что нам придется создать еще один класс, который на фоне сгенерированных даггером фабрик роли не сыграет.
629 |
630 | #CleanArchitecture #Interactor
631 |
632 |
--------------------------------------------------------------------------------
/theory/Theory_article.md:
--------------------------------------------------------------------------------
1 | С точки зрения теории в интернетах гуляет очень много материала. Но есть источники, которые заслуживают отдельного упоминания, и которые мы рекомендуем прежде всего.
2 |
3 | Первое, это серия статей от Five:
4 | [Android Architecture: Part 1 - every new beginning is hard](http://five.agency/android-architecture-part-1-every-new-beginning-is-hard/)
5 | [Android Architecture: Part 2 - the clean architecture](http://five.agency/android-architecture-part-2-clean-architecture/)
6 | [Android Architecture: Part 3 - Applying clean architecture on Android](http://five.agency/android-architecture-part-3-applying-clean-architecture-android/)
7 | [Android Architecture: Part 4 - Applying Clean Architecture on Android, Hands on (source code included)](http://five.agency/android-architecture-part-4-applying-clean-architecture-on-android-hands-on/)
8 | [Android Architecture: Part 5 - How to Test Clean Architecture](https://five.agency/android-architecture-part-5-test-clean-architecture/)
9 |
10 | Очень грамотное теоретическое описание трансформации классической Clean Architecture от дядюшки Боба в Clean Architecture для Android.
11 | Единственное, вторая статья как-то немного запутала с этими input/output портами для UseCase и решением проблемы флоу данных через наследование и композицию. Немного оторвано от практики, как нам показалось. Лучше сразу к третьей части приступить, если вы также не совсем поняли.
12 | Еще есть моменты, над которыми можно похоливарить.
13 |
14 | Второе, это [видео 2016 года](https://www.youtube.com/watch?v=AlxMGxs2QnM&t=2509s&list=PLb1A91j1236pH1yoUvq5YDZUWAJz1T4DF&index=4) и [2017 года](https://www.youtube.com/watch?v=pmlGgIOlz9w&t=15114s) о Чистой архитектуре от Евгения Мацюка и Александра Блинова.
15 | Однако, с течением времени некоторые вещи, упомянутые в видео, уточняются и переосмысливаются. И в этом нужно сказать спасибо всем участникам архитектурного чатика. Поэтому мы настоятельно советуем пересмотреть доклады и прочитать дополнения.
16 |
17 | Итак дополнения:
18 |
19 | 1. Проектировать фичу лучше начинать сверху вниз, а не наоборот, так как вы прежде всего отталкиваетесь от того, что видит конечный пользователь.
20 |
21 | 2. Общая структура. Итоговый вид структуры пакетов соответствует классическим канонам Чистой архитектуры
22 |
23 | Структура пакетов:
24 | ```
25 | project
26 | ├─ di
27 | │ ├─ app
28 | │ ├─ payments
29 | │ └─ operation
30 | ├─ presentation
31 | │ ├─ view
32 | │ │ ├─ payments
33 | │ │ │ ├─ PaymentsView
34 | │ │ │ └─ PaymentsFragment
35 | │ │ └─ operations
36 | │ │ ├─ OperationsView
37 | │ │ ├─ OperationsFragment
38 | │ │ └─ models
39 | │ │ └─ OperationUIModel
40 | │ └─ presenter
41 | │ ├─ payments
42 | │ │ └─ PaymantsPresenter
43 | │ └─ operations
44 | │ └─ OperationsPresenter
45 | ├─ domain (он же business)
46 | │ ├─ payments
47 | │ │ ├─ PaymentsInteractor
48 | │ │ ├─ PaymentsInteractorImpl
49 | │ │ ├─ CurrencyHandler (вспомогательный класс для PaymentsInteractor)
50 | | | ├─ PaymentsRepository
51 | | | └─ models
52 | | | └─PaymentsModel
53 | │ └─ operations
54 | │ ├─ OperationsInteractor
55 | │ ├─ rubs
56 | │ │ ├─ OperationsInteractorRubs
57 | │ │ └─ RubsManager (вспомогательный класс для OperationsInteractorRubs)
58 | │ ├─ currency
59 | │ │ ├─ OperationsInteractorCurr
60 | │ │ └─ CurrencyManager (вспомогательный класс для OperationsInteractorCurr)
61 | │ ├─ OperationsRepository
62 | │ └─ models
63 | │ ├─ OperationsRubModel
64 | │ └─ OperationCurrModel
65 | ├─ data
66 | │ ├─ repositories
67 | │ │ ├─ payments
68 | │ │ │ └─ PaymentsRepositoryImpl
69 | │ │ └─ operations
70 | │ │ ├─ OperationsRepositoryImpl
71 | │ │ └─ models
72 | │ │ ├─ OperationsRubNetworkModel
73 | │ │ └─ OperationCurrNetworkModel
74 | │ ├─ network
75 | │ └─ db
76 | ```
77 |
78 | 3. Есть несколько вариантов трактования понятия "Репозиторий". Подробно можно почитать, например, [здесь](http://hannesdorfmann.com/android/evolution-of-the-repository-pattern). В Андроид-мире "Репозиторий" - это абстракция для получения данных, то есть она скрывает, с какого именно источника получены те или иные данные.
79 | Кроме того Репозиторий может внутри себя реализовывать логику кэширования данных и соответственно выдачи либо закэшированных данных, либо данных с сети.
80 |
81 | 4. Дядюшка Боб говорит, что *Interactor*- это объект, реализующий *Use Case*. Более того, предлагается создавать их с помощью паттерна [Команда](https://refactoring.guru/ru/design-patterns/command). У нас же сложилась тенденция объединять различные пользовательские сценарии, связанные с одним функционалом, в отдельные классы - Use case feature facade. Вдобавок многие использует в своих проектах RxJava, и мы получаем довольно лаконичный способ описания основного функционала. Были некоторые споры о том, должны ли такие классы называться в стиле "FeatureInteractor", или "FeatureInteractors" (во множественном числе), но больше прижился первый способ наименования.
82 |
83 | 5. Domain ничего не знает о других слоях. По классике к domain относятся Интеракторы и интерфейсы Репозиториев. Поэтому Интерактор не может являться маппером моделей. Мапперами моделей будут выступать Репозитории (из моделей data в модели domain и наоборот) и Презентеры (из моделей domain в модели View и наоборот).
84 | Когда мы проектируем фичу и разрабатываем ее по слоям, то в отношении моделей нужно исходить все-таки из принципа минимализма. Если вы знаете, что для вашей фичи вам достаточно будет просто сходить в сеть и полученный результат отобразить на экране и ничего более, и такое поведение вряд ли когда-нибудь изменится, то на все слои вашей фичи лучше держать одну модель.
85 | Чаще бывает, когда полученный результат с сервера нам нужно немного подкорректировать, и уже можно отображать на экране. Тогда на фичу будет две модели (data и domain).
86 | Ну и бывает, что по сути на каждый слой необходима своя модель (presentation, domain, data).
87 |
88 | 6. Activity, Service, BroadcastReceivers относятся ко внешнему кругу Чистой архитектуры, так как они являются частью платформы. Роли же у них могут быть разные: они могут быть и точками входа в приложение, и являться частью view, и работать в качестве источника данных. Соответственно, так как они относятся ко внешнему кругу, вы при необходимости можете внедрить туда и Интерактор, и Репозиторий, и другие классы из внутренних кругов.
89 |
90 | 7. В [видео 2016 года](https://www.youtube.com/watch?v=AlxMGxs2QnM&t=2509s&list=PLb1A91j1236pH1yoUvq5YDZUWAJz1T4DF&index=4) для Интерфейса Вьюшки много методов (setName, setAccountNumber, setCardNumber, setNearestDepartments). На самом деле все эти методы можно заменить на один типа setData, и в аргументы передавать какую-то специальную модельку.
91 |
92 | 9. Взаимодействие между вьюшкой и презентером и решение вопроса с ЖЦ лучше делегировать какой-то специальной библиотеке. Например, Moxy. Тогда вы избавитесь от большой части довольно нудной работы - обработка ЖЦ.
93 |
94 | Кроме того про распространенные заблуждения с отсылом в первоисточники хорошо описано в [статье Василия](https://habrahabr.ru/company/mobileup/blog/335382/).
95 |
96 | Вот кратко и вся теория, которую мы рекомендуем изучить в первую очередь. Остальные материалы на базе приобретенных вами знаний станут более понятными и логичными. У вас составится определенная картина, определенная база, от которой уже можно отталкиваться.
97 |
98 |
99 |
--------------------------------------------------------------------------------