https://kotlinlang.org logo
Join Slack
Powered by
Anyone familiar with <https://github.com/dropbox/S...
# android
o
Anyone familiar with https://github.com/dropbox/Store and willing to explain how it's meant to be used? I thought it was straight forward, until I couldn't find a way to get all the data? How should on do a 
getAll
on the data in the store?
n
@friendlymike might know a bit about it
o
He doesn't seem to be online at the moment unfortunately 😞
a
I think I can help you, you can consider the getAll thing as a request key. Something like
Copy code
sealed class RequestKey {
   object All : RequestKey()
}
and when you want to use the store 
store.stream(StoreRequest.fresh(RequestKey.All))
o
Ah ok, I thought about that indeed. So then you pass the fetcher with a when statement that makes the different api call based on the RequestKey, right? But what about the OutputType ? Sometimes I would want to get all the Users and sometime just one user by id. Would that be something like this?:
Copy code
sealed class  Response {
    data class AllUsers(val users: List<User>) : Response()
data class User(val user: User) : Response()
}
Which would give you the following Store: 
val userStore: Store<RequestKey, Response>
Would that be the correct, intended way of using the Store library?
a
That could be one way to use yes. But If I were you I'd just make the OutputType as 
List<User>
to make it simpler and handle it based on the request key that you've requested.
If you really want to keep the 
Response
as sealed class, then you can just do a 
filterIsInstance<Response.AllUsers>()
to handle the all users response.
o
Ah ok, and then when I use the requestKey.ById, I would know I get a list of users with a size of 1. That might be less verbose indeed. Is it intended that I create a Store for ever model? (So if my app existed of Users and Posts, I would have a UserStore and PostStore?)
a
Yes, theoretically you can use one Store for everything and use sealed classes to differentiate between input and outputs, but of course I'd advice against this practice, and keep different entities into different stores.
o
Ok, but won't the caching system fail with multiple request keys? For example, I request all users from the store (with the RequestKey.All), which it gets cached automatically by the Store. Now I ask from the same store: user by id=4 (so RequestKey.ById(4)). Correct me if I'm wrong, but won't the Store then make a network request to get user id=4, despite the fact that it already has all the users cached by the previous call?
a
AFAIR, If you assign a SourceOfTruth to Store, it will check first the key inside the DB, and if it's not there then it will get it from network. Since you already had the RequestKey.All cache stuff in the DB, once you do a ById(4), you will get the User from the DB without going through the network.
t
Chris Banes used it in his tivi app, maybe you can go through it
o
@Ahmed Ibrahim but when I am looking at the Source of Truth, the Key is clearly meant for keys for single entity: https://github.com/dropbox/Store/blob/b18db6f61f70dae431b4eb7d5f200523212a6f46/store/src/main/java/com/dropbox/android/external/store4/SourceOfTruth.kt#L83 . Otherwise the source of truth wouldn't have the deleteAll() method besides the delete(Key) method, would it?
20 Views
Open in Slack
PreviousNext
Powered by