/taste toggles taste count when hit with the same device_guid param.

[benlachman]

It should simple ignore any duplicates vs. toggling. Same goes for favoriting.

[pagan8]

Are you sure? I think Ricky deliberately put this behavior in so that when someone hit the like or tastes button again it would undo their request.... I guess this isn't needed though if the iOS app doesn't track state of the button (eg. liked / not liked).... I can change it but Ricky should chime in first :)

[benlachman]

My feeling is that that logic should be in the client and only validation logic (eg no tastes by the same person twice) be in the backend. Thoughts @rickychilcott ?

[rickychilcott]

So... what happens if they want to "undo" their favorite or like? Do we still ignore or provide another mechanism? That's why we implemented the toggle

[pagan8]

I agree with Ricky, and the current implementation prevents someone from liking or tasting something twice. By keeping the logic on the backend, you also eliminate the problem of someone clearing the app's cache / data or uninstalling / reinstalling the app to like something multiple times ;)

[rickychilcott]

👍 and it's done, so we don't have to spend more time on it :)

@benlachman would it be helpful if we passed back the status for a given device_guid (i.e. status would equal 0 for not tasted and 1 for tasted).

The problem with the current implementation is that it's possible for the app state to get out of sync with the toggl mechanism

[benlachman]

Well it's done the opposite way on the app side. So it's a change either way. My feeling that if we meant to build a mechanism for syncing state to the backend we're a bit behind. The client's state isn't reflected in the backend, it functions more as a data source currently. Based on my memory of the original discussion we just wanted to avoid duplicates in the taste count metadata.

[buswellj]

Change the app then.. Never going to be dups the way the back end is setup
:)

On Thu, Jun 25, 2015, 18:42 Ben Lachman [email protected] wrote:

Well it's done the opposite way on the app side. So it's a change either
way. My feeling that if we meant to build a mechanism for syncing state to
the backend we're a bit behind. The client's state isn't reflected in the
backend, it functions more as a data source currently. Based on my memory
of the original discussion we just wanted to avoid duplicates in the taste
count metadata.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[benlachman]

Not going to happen. There's no reason to muddy the fact that we're not and have never planned to store app state on the service side in this version of the app. Plus, I'm the only code contributor on the app side, there are too many more important issues to make happen.

[pagan8]

So can we close this as working as designed? :)

[benlachman]

Ha.