Fix instances count on main menu #6535
Conversation
seadowg
force-pushed
the
instances-count
branch
3 times, most recently
from
2620b99 to
4c0bce3
Compare
seadowg
force-pushed
the
instances-count
branch
from
1466411 to
bdd450c
Compare
seadowg
force-pushed
the
instances-count
branch
from
bdd450c to
d5b2c23
Compare
seadowg
force-pushed
the
instances-count
branch
from
d5b2c23 to
ca7a50d
Compare
seadowg
force-pushed
the
instances-count
branch
from
a28945a to
9a54180
Compare
| private val currentProjectViewModel = CurrentProjectViewModel( | ||
| projectsDataService | ||
| ) | ||
| private val currentProjectViewModel by lazy { CurrentProjectViewModel(projectsDataService) } |
There was a problem hiding this comment.
Does it make any sense to use by lazy in tests?
There was a problem hiding this comment.
You can't construct a CurrentProjectViewModel until after the JUnit rules have run (so that InstantTaskExecutorRule has done its job). I agree that the lazy is a bit weird though, so I'll just replace it with construction in the tests themselves.
| return DataDelegate(data) | ||
| } | ||
|
|
||
| protected fun <T> data(key: String, default: T, updater: () -> T): DataDelegate<T> { |
There was a problem hiding this comment.
It's used just in one place I think we can get rid of it and use qualifiedData instead. Then we could also remove attachData and move the code directly to qualifiedData.
There was a problem hiding this comment.
Right this is a little weird. The reason for the two is so that the updater type can be more accurate: for data we don't want there to be a qualifier passed to it. This kind of falls apart though because you could still then pass a qualifier to Data#flow. It feels like it's half done. I'll have a quick go at making the types stricter throughout.
|
Tested with Success! Verified on a device with Android 10 Verified Cases:
|
|
Tested with Success! Verified on a device with Android 15 and Android 12 by Szymon |
Closes #6531
Why is this the best possible solution? Were any other approaches considered?
The biggest change I had to make here was to modify
InstancesDataServicesso that the instances counts were qualified by project. As part of this, I ended up introducing a more formalized way to create/work with data services in the form of aDataServiceabstract class (inData.kt).How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
The changes made are pretty widespread, so I think a general check of downloading, updating, saving and sending forms would be good here.
Before submitting this PR, please make sure you have:
./gradlew connectedAndroidTest(or./gradlew testLab) and confirmed all checks still passDateFormatsTest