-
-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clean up separation between app/database/network layers. #654
Conversation
Test results (test) 85 files + 2 85 suites +2 10s ⏱️ -1s Results for commit 96214ab. ± Comparison against base commit a1bbad1. This pull request removes 6 and adds 33 tests. Note that renamed tests count towards both.
♻️ This comment has been updated with latest results. |
d65f817
to
55d5153
Compare
@cketti If you have the energy to look into this as well - then you are welcome. No pressure! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think using the names SessionAppModel
, SessionDatabaseModel
, and SessionNetworkModel
is a good (first) step. However, I wish you renamed the classes instead of only using import aliases.
Having different names clearly shows there's a lot of conversions going on between the different model classes. I think this could be avoided and the code would be simplified by having a single Session
class in an API module. Then instead of calling it the "network" module, you think of it as a data provider module where the network access and source data format are just implementation details. The data provider module would parse and convert the source data to Session
instances internally and only pass those to the app.
Similarly, the database module could use that Session
class for communication with the app and do all necessary conversions internally.
UI code probably shouldn't use this class, but have specialized UI models that contain exactly the data that is necessary for a particular screen.
app/src/main/java/nerd/tuxmobil/fahrplan/congress/dataconverters/SessionExtensions.kt
Show resolved
Hide resolved
app/src/test/java/nerd/tuxmobil/fahrplan/congress/models/SessionTest.kt
Outdated
Show resolved
Hide resolved
55d5153
to
13fd9f2
Compare
Thank you for your feedback! In my understanding is that the In its function of loading and converting data I try to keep the I am happy to brainstorm ideas to improve the architecture. This probably works better in a synchronous conversation. Let's continue apart from this merge request. |
13fd9f2
to
f2378bb
Compare
@cketti Are you fine with resolving the remaining review comments? |
f2378bb
to
70110dc
Compare
+ Left-over from: ac5cba5.
…odel classes. + Network models are only used in the context of fetching data from the network and parsing it. + Database models are only used in the context of loading data from the database. + Both network and database models are only used in AppRepository which acts as central junction for converting models between the layers. + For the app layer AppRepository only exposes data as app models.
+ AppRepository#readHighlights is only invoked within the scope of database models in AppRepository#loadSessionsForDayIndex. Hence, there is no reason to convert the returned :database:Highlight to :app:Highlight.
70110dc
to
96214ab
Compare
Description
app
/database
/network
layers forSession
andMeta
model classes.network
models are only used in the context of fetching data from the network and parsing it.database
models are only used in the context of loading data from the database.network
anddatabase
models are only used inAppRepository
which acts as central junction for converting models between the layers.AppRepository
only exposes data asapp
models.:app:Highlight
model class.Session#sanitize
extension function.speakers
string.Successfully tested on
with
ccc37c3
flavor,debug
build