search

enpassio / Databinding

Various examples on databinding which can help not only understand how to get started with it but it also shows how this can be used in complex and real use cases
Apache License 2.0
26 stars 14 forks source link

newsapi kotlin: refactor: move connectivity check to view model #33

Closed OyaCanli closed 5 years ago

OyaCanli commented 5 years ago

I moved the connectivity check to viewmodel as you proposed

OyaCanli commented 5 years ago

Hey @rajtheinnovator. If this one seems fine to you, I'll make the java version accordingly as well. There was a point I was confused (and I am still) while doing this. I recognized that whwn user quits the app with back button, activity and all the fragments and viewmodels associated with that are killed. But singleton repository survives. So, if user quits the app, and then return hours later or the day later, the data is still there. Unless user kills the app explicitly by x button or by swiping off, data waits there in the background. I'm not sure if this is the expected behaviour. Besides, in its initial state, if internet turned off in the meanwhile, when user returns to the app it was showing a snack for warning about network, although it was also showing the data it kept. I was again not sure it that is the expected behaviour. I made an arrangement so that it checks connection only in the absence of data. But I'm really not sure what is the ideal behaviour.

OyaCanli commented 5 years ago

@rajtheinnovator You know what.. I think it is fine to show a no network snack even if old data is there and visible. And I think I made an unnecessary optimization by preventing downliad when there is data, which prevent refreshing of data. And I'm probably unnecessarily concerned about all these details for this sample. 😀

rajtheinnovator commented 5 years ago

@OyaCanli I've tried observing patterns in some apps so that I could know how they handle similar situation. I couldn't come to a single conclusion as it seems like different apps use different strategy based on what purpose they serve. I noticed that, in apps where data is stored like maintaining a record, day by day, they'll always fetch for data of current date/today whenever the user refreshes the data, and other data, they will try showing from local storage if it's already there.

In news feed kind of app like LinkedIn, by default they'll show data from local storage on loading but as soon as they retrieve the latest data, it'll shown to user via the option of new posts available floating kind of button or on loading itself, the screen will be blank unless new data is retrieved.

In apps where there is chat involved, they're always fetching new data, probably by running some background service. And so even if you don't refresh the chat and if they find new data which for some reason was posted by you yourself but not shown as sent. Or an old received messages, which is not being shown for some reason, in these cases, they'll simply refresh the UI on receiving the new data.

All in all, the behavior is varying on what use case the app is being used, but generally, for current data, they generally make a new network request even if data is available on local storage.

In the current app however, we can definitely keep it simple as you said and the more customized behavior can be implemented in some other complete version.

OyaCanli commented 5 years ago

@rajtheinnovator Hey! Thanks for these sharing these observations! Indeed, I think it is better to persist some data and check again for new data and sync when new data is available. Though, I guess for the purpose of this sample it is not necessary to deal with data persistence and background services. I think I found a reasonable solution. I'll make a new PR.