Skip to content
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

Store network requests in Realm #30

Closed
ranhsd opened this issue Oct 15, 2017 · 7 comments
Closed

Store network requests in Realm #30

ranhsd opened this issue Oct 15, 2017 · 7 comments

Comments

@ranhsd
Copy link
Contributor

ranhsd commented Oct 15, 2017

Hi,
I have a question related to architecture of view model.

Let's assume that I have a requirement to store network requests payload in Realm in order to be able to access data even if the user is offline. Currently in the example you show how to use Network or Realm or CoreData but not all together.

If i want to fulfill the requirement I need to do the following:

  1. Pass 2 use cases into my view model . One is the network use case and the other one is the realm use case
  2. Execute a call to the server via the Network use case and then use flat map to get the results and store them in Realm.
  3. If the user is offline i can simply fetch the data from realm use case instead of the network use case.

I think it can work but maybe there is a better way to achieve it. Maybe by creating an abstraction layer on top of it that will do the call (either to the server or to the offline database in case the user is online/offline)

What do you think ?

Thanks!

@sergdort
Copy link
Owner

sergdort commented Oct 18, 2017

Hi @ranhsd there is example of caching data inNetwork , but it uses NSCoding I think if you swap it with Realm or any other persistence framework it should work

@ranhsd
Copy link
Contributor Author

ranhsd commented Oct 19, 2017

Hi @sergdort
thank you !

@sergdort
Copy link
Owner

I'm gonna close it then, if you'll have any questions feel free to reopen :)

@ranhsd
Copy link
Contributor Author

ranhsd commented Oct 29, 2017

Hi @sergdort , In continue to this question...
I saw that you created the AbstractCache file inside the Network platform. Do you think that it's a good practice to use Realm inside the Network platform? I am asking because i think that the network should know only the domain and not the database layer. Maybe another solution can be to do it in the App layer there i can send 2 use cases to my view model:

  • One is the Network use case

  • The second is the Database (Realm/CoreData) use case

And then to do it on the app side. First i use the network to fetch items and then use Realm to store them, if the app is not connected then i can directly use the database use case.

What do you think? It is better to do it on the Network layer or on the App layer like i suggested?

Thanks.

@hunganh0403
Copy link

hunganh0403 commented Apr 22, 2018

I have exactly same question with @ranhsd
i start to think about create a new layer like Interactor in VIPER architecture since I want to separate network from database

@sergdort
Copy link
Owner

Hi, guys!

The only reason we have different platforms is the example app is to be able to have multiple concrete implementations of the same Domain. Typically in the real App we do not need to have multiple implementations for the same feature. So if it was a real app I would model it with only one Domain if it relatively small app or to have a domain per feature.

For example, if we have a UserProfile, Chat, NewsFeed features in our app we could model it something like

screen shot 2018-04-29 at 20 05 15

Where Core module (could be one or multiple) contain app agnostic implementation - meaning you should be able to use it "any" App.

@kylelol
Copy link

kylelol commented Jan 18, 2019

@sergdort If you model it with 1 domain per feature, how do you handle relationships? Can the domains know about each other?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants