This starts tracking the connectivity status before the repository is initiated; it fixes a problem with the repository not correctly executing actions in the init method.
This starts tracking the connectivity status before the repository is initiated; it fixes a problem with the repository not correctly executing actions in the init method.
Removing this forces the app to make 2 api calls (to the tags and sources routes) even if we have data in the database.
Not sure if we want to do this.
Removing this forces the app to make 2 api calls (to the tags and sources routes) even if we have data in the database.
Not sure if we want to do this.
There is a change in behaviour effectively.
If this is the behaviour we desire, it should be specified in the repository.
I'm not sure this is good, because doing this you will never update sources after you stored them once in the database.
There is a change in behaviour effectively.
If this is the behaviour we desire, it should be specified in the repository.
I'm not sure this is good, because doing this you will never update sources after you stored them once in the database.
The condition drawerData.sources?.isEmpty() == true || appSettingsService.isUpdateSourcesEnabled() was false if there was already data in the DB and isUpdateSourcesEnabled was false, thus not making an api call as I stated in my first comment.
The condition `drawerData.sources?.isEmpty() == true || appSettingsService.isUpdateSourcesEnabled()` was false if there was already data in the DB and `isUpdateSourcesEnabled` was false, thus not making an api call as I stated in my first comment.
As far as I can see this is not the case; the pull to refresh just calls handleDrawerData().
What I could do, is change the repository implementation of getTags() and getSources() so that they default to fetching from the database rather than the api unless a parameter to force using the api is set; then I could include a call to this method with the force flag in the pull to refresh.
I'm not sure this is the preferred behavior, I guess an user expects the application to have sources and tags up to date once they start it up. Moreover it's a very small amount of data being transferred when compared to the data downloaded for actual articles.
Also, I'm not sure about how this would work with the number of unread items in each tag; it would probably be out of date when you first start the application.
As far as I can see this is not the case; the pull to refresh just calls `handleDrawerData()`.
What I could do, is change the repository implementation of `getTags()` and `getSources()` so that they default to fetching from the database rather than the api unless a parameter to force using the api is set; then I could include a call to this method with the force flag in the pull to refresh.
I'm not sure this is the preferred behavior, I guess an user expects the application to have sources and tags up to date once they start it up. Moreover it's a very small amount of data being transferred when compared to the data downloaded for actual articles.
Also, I'm not sure about how this would work with the number of unread items in each tag; it would probably be out of date when you first start the application.
I guess this can be merged for now and some further optimization can be done in the future.
I can start working on #71 to make sure that everything works correctly with the new api for when selfoss 2.19 will be out.
I will work on the points that are not already addressed by #53.
I guess this can be merged for now and some further optimization can be done in the future.
I can start working on #71 to make sure that everything works correctly with the new api for when selfoss 2.19 will be out.
I will work on the points that are not already addressed by #53.
I can start working on #71 to make sure that everything works correctly with the new api for when selfoss 2.19 will be out.
I will work on the points that are not already addressed by #53.
> I can start working on #71 to make sure that everything works correctly with the new api for when selfoss 2.19 will be out.
I will work on the points that are not already addressed by #53.
@davidoskky #71 is not a priority. We should focus on [the next milestone](https://gitea.amine-louveau.fr/Louvorg/ReaderForSelfoss-multiplatform/milestone/5) first.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The objective is to remove direct database access from the home activity and delegate that logic to the repository.
@@ -75,6 +75,7 @@ class MyApp : MultiDexApplication(), DIAware {).show()}}connectivityStatus.start()Why was this added ?
This starts tracking the connectivity status before the repository is initiated; it fixes a problem with the repository not correctly executing actions in the init method.
@@ -352,28 +347,15 @@ class HomeActivity : AppCompatActivity(), SearchView.OnQueryTextListener, DIAwar)CoroutineScope(Dispatchers.IO).launch {val drawerData = DrawerData(repository.getDBTags().map { it.toView() },Removing this forces the app to make 2 api calls (to the tags and sources routes) even if we have data in the database.
Not sure if we want to do this.
There is a change in behaviour effectively.
If this is the behaviour we desire, it should be specified in the repository.
I'm not sure this is good, because doing this you will never update sources after you stored them once in the database.
The condition
drawerData.sources?.isEmpty() == true || appSettingsService.isUpdateSourcesEnabled()was false if there was already data in the DB andisUpdateSourcesEnabledwas false, thus not making an api call as I stated in my first comment.Yes, I made a mistake. You were right in the first comment. However this behavior never update sources once they've been stored in the database.
The pull to refresh was updating them, if I remember correctly
As far as I can see this is not the case; the pull to refresh just calls
handleDrawerData().What I could do, is change the repository implementation of
getTags()andgetSources()so that they default to fetching from the database rather than the api unless a parameter to force using the api is set; then I could include a call to this method with the force flag in the pull to refresh.I'm not sure this is the preferred behavior, I guess an user expects the application to have sources and tags up to date once they start it up. Moreover it's a very small amount of data being transferred when compared to the data downloaded for actual articles.
Also, I'm not sure about how this would work with the number of unread items in each tag; it would probably be out of date when you first start the application.
For now, we'll let this like you implemented it. We'll see later how to handle things.
@@ -63,6 +63,7 @@<string name="card_height_off">Card height will be fixed</string><string name="source_code">Source code</string><string name="drawer_error_loading_tags">Error loading tags…</string><string name="drawer_error_loading_sources">Error loading sources…</string>Adding this will make the build fail.
It should be added to all the translation files with the same value.
@@ -352,28 +347,15 @@ class HomeActivity : AppCompatActivity(), SearchView.OnQueryTextListener, DIAwar)This doesn't worked as expected since the itemAdapter is cleared immediately after.
I guess this can be merged for now and some further optimization can be done in the future.
I can start working on #71 to make sure that everything works correctly with the new api for when selfoss 2.19 will be out.
I will work on the points that are not already addressed by #53.
@davidoskky #71 is not a priority. We should focus on the next milestone first.