You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+40-66Lines changed: 40 additions & 66 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -85,91 +85,62 @@ that should scale.
85
85
The 3 layered architectural approach is majorly guided by clean architecture which provides
86
86
a clear separation of concerns with its Abstraction Principle.
87
87
88
-
The `domain` and `data` layers are java module libraries as the business
89
-
logic does not rely on the Android frameworks concrete implementations.
90
-
91
88
#### Presentation
92
89
93
-
The application presentation layer contains the Activity,Fragments and
94
-
Viewmodels and handles Dependency Injection.
95
-
96
-
The UI layer `feature` package contains `character_detail` and
97
-
`character_search`which contain an activity and corresponding
98
-
viewmodel as well as other UI related classes.
99
-
100
-
The viewmodels are provided by the Koin that uses Kotlin's DSLs
101
-
to lazily resolve dependency graph at runtime
102
-
103
-
The ViewModel then receives data from the use case and updates the
104
-
LiveData being observed by the activity,the Activity then makes updates
105
-
to the UI as need be depending on the current view state.
106
-
107
-
The UI utilises a **State pattern** by representing expected view states using sealed classes.
108
-
This aids with delegating logic operations to the Viewmodel and makes testing in isolation
109
-
easier.
90
+
```app```contains the UI files and handles binding of DI components from other modules.
91
+
Binding of data is facilitated by jetpacks data binding by serving data from the viewmodel
92
+
to the UI.The data being received is part of a viewstate class that has properties contained in the
93
+
relevant state.
110
94
111
95
#### Domain
112
96
113
-
The domain layer contains domain model classes which represent the
97
+
The ```domain``` module contains domain model classes which represent the
114
98
data we will be handling across presentation and data layer.
115
99
116
100
Use cases are also provided in the domain layer and orchestrate the flow
117
101
of data from the data layer onto the presentation layer and a split into
118
102
modular pieces serving one particular purpose.
119
103
120
-
The UseCases use a ```BaseUseCase``` interface that defines the parameters its taking in and output
121
-
this helps in creating fakes using in testing.
104
+
The UseCases use a ```BaseUseCase``` interface that defines the parameters its taking in and
105
+
output this helps in creating fakes using in testing.
122
106
123
107
#### Data
124
108
125
-
The Data layer using the **Repository Pattern** will be able to
126
-
provide data to the defined use cases which in this case is searching
127
-
for characters and viewing details of selected characters.The use-cases
128
-
are based on the single responsibility rule.
129
-
130
-
This provides a more decoupled system,as it is isolated from changes to the
131
-
db by abstracting low level implementation details of data sources and
132
-
changes to the UI.
109
+
- ```data-remote```
133
110
134
-
The repository classes delegate access of data to the data source of
135
-
interest either local data source or a remote data source.
111
+
Handles data interacting with the network and is later serverd up to the presentation layer through
112
+
domain object
136
113
137
-
This layer also handles mapping of data entities to their domain
138
-
representations which when eventually passed to the presentation layer the
139
-
domain will be mapped to the presentation model.
114
+
- ```data-local```
140
115
141
-
## Testing
142
-
143
-
Testing has been done based on the architectural layers.
116
+
Handles persistence of object with Room ORM from.This module is responsible for handling all local related
117
+
logic and serves up data to and from the presentation layer through domain objects.
144
118
145
-
1.Domain
119
+
With this separation we can easily swap in new or replace the database being used without causeing
120
+
major ripples across the codebase.
146
121
147
-
Contains tests that encompass domain models and uses mockito to verify
148
-
use case behavior.
122
+
## Testing
149
123
150
-
2.Data
124
+
Each module has its own tests except for the ```domain``` module which is catered for since its
125
+
part of the behavior under test.
151
126
152
-
Tests in the data inherit from a base test that provides a mock web server
153
-
with the api interface to request paths the routing of paths to responses
154
-
is handled by a custom mock web server dispatcher.
127
+
All server responses in the tests are served by mock web server by appending relative urls to
128
+
the localhost and the connected port as the base url.
155
129
156
-
Json responses have also been provided in the test resource folder they
157
-
are similar to the response that will be received from the api
158
-
The repository tests serve as integration tests between the data sources
159
-
and mappers to the domain models.
160
-
Currently the data source tests serve as unit tests verifying the appropriate
161
-
responses are received from remote source.
130
+
In the ``data-remote`` module the responses are mocked using the mockwebserver and verified that they
131
+
are what we expect.
162
132
163
-
3.Presentation
133
+
In the ```data-local``` module an in memory database is being used to run the tests,this makes it a
134
+
little faster compared to an actual db.
164
135
165
-
The Presentation layer contains robolectric jvm tests on for menu items
166
-
and instrumentation tests checking on system behaviour as per user
167
-
expectation.
136
+
In the ```app``` module there are unit tests for the viewmodels and util classes
137
+
and connected tests for the UI Screens.
168
138
169
-
The UI tests display data served from a mock web server running from the
170
-
devices localhost,this removes flakiness compared to relying on actual
171
-
data from the real server aspects such as internet connection or
172
-
network service might bring up issues.
139
+
The test instrumentation app uses modules that have been swaped with fakes for
140
+
the network module so as to run requests on localhost with mockwebserver,this removes flakiness
141
+
compared to relying on actual data from the real server aspects such as internet connection or
142
+
network service might bring up issues and an in memory database for local data that also allows
143
+
main thread queries since tests should also be fast and we are just asserting stuff works.
173
144
174
145
View models testing on live data were guided by this [article](https://proandroiddev.com/how-to-easily-test-a-viewmodel-with-livedata-and-coroutines-230c74416047)
175
146
@@ -181,13 +152,13 @@ Libraries used in the whole application are:
181
152
- [Viewmodel](https://developer.android.com/topic/libraries/architecture/viewmodel) - Manage UI related data in a lifecycle conscious way
182
153
and act as a channel between use cases and ui
183
154
- [Data Binding](https://developer.android.com/topic/libraries/data-binding) - support library that allows binding of UI components in layouts to data sources,binds character details and search results to UI
155
+
- [Room](https://developer.android.com/training/data-storage/room) - Provides abstraction layer over SQLite
184
156
- [Retrofit](https://square.github.io/retrofit/) - type safe http client
185
157
and supports coroutines out of the box.
186
158
- [Moshi](https://github.com/square/moshi) - JSON Parser,used to parse
187
159
requests on the data layer for Entities and understands Kotlin non-nullable
188
160
and default parameters
189
161
- [okhttp-logging-interceptor](https://github.com/square/okhttp/blob/master/okhttp-logging-interceptor/README.md) - logs HTTP request and response data.
190
-
- [Mockito](https://site.mockito.org/) - Mocking framework used to provide mocks to verify behaviour in domain usecases tests.
191
162
- [kotlinx.coroutines](https://github.com/Kotlin/kotlinx.coroutines) - Library Support for coroutines,provides `runBlocking` coroutine builder used in tests
192
163
- [Truth](https://truth.dev/) - Assertions Library,provides readability as far as assertions are concerned
193
164
- [MockWebServer](https://github.com/square/okhttp/tree/master/mockwebserver) - web server for testing HTTP clients ,verify requests and responses on the star wars api with the retrofit client.
@@ -200,18 +171,23 @@ and default parameters
200
171
- [Espresso](https://developer.android.com/training/testing/espresso) - Test framework to write UI Tests
<a href='https://play.google.com/store/apps/details?id=com.k0d4black.theforce&pcampaignid=pcampaignidMKT-Other-global-all-co-prtnr-py-PartBadge-Mar2515-1'><img alt='Get it on Google Play' src='https://play.google.com/intl/en_us/badges/static/images/badges/en_badge_web_generic.png' width='170'/></a>
217
193
@@ -242,5 +218,3 @@ Star Wars and all associated names are copyright Lucasfilm ltd.
242
218
See the License for the specific language governing permissions and
0 commit comments