It is common to app user explicitly put a flag of โLike itโ which will add โheart markโ to record you did so, and there is also feature to remove the same.
This shuld be simpliest workaround I believe to get the same features on Appsheet.
I prepard sample app for community.
https://www.appsheet.com/samples/Sample-App?appGuidString=a96866d4-af6f-48bc-b3d7-8d4cd0030a27
Thanks for sharing @tsuji_koichi. Very useful!
Yep, building the list.
I like this. You can also display the current number of โLikesโ by COUNT(SPLIT( โฆ ), delim)& " " on the summary column.
I think one thing that may be an adverse event to your list method on a single row, however, is if two users leave a โLikeโ at the exact same time. Would the simultaneous action override a like by 1 user over the other?
That makes me go to the route of adding rows to a separate referenced table. Since each action would create a separate row. It also allows me to keep track of the timestamp each like was administered.
Thank you for your comment, I donโt think the simultaneous action over the same row by different user on this case wonโt be an issue, because of
Each user is targeting the value of own useremail address text value in the field. If not exist, then add by action, else delete by action as well. Even if the action is triggered at the same time (in the mil sec world, i dont think it will happen thoughโฆ), it is nothing to do with action made by other user which is taking care of their own value (email address)
Counting the number LIKEIT sounds good. I will alter my sample accordingly.
Nice
I just updated sample app, to show the count of LIKE IT for each row.
https://www.appsheet.com/samples/Sample-App?appGuidString=a96866d4-af6f-48bc-b3d7-8d4cd0030a27
This is a very valuable technique, Iโve used it plenty in my time here with Appsheet. However, I really think that everyone should keep in mind the potential issues when considering a multi-tenant environment.
If someone opens the app, likes an item, closes the app before it fully syncsโฆ Then the next time they open the app, and it syncs that old change it WILL overwrite everyone elseโs likes/unlikes. Effectively, time walking the field to that prior point in time.
The risk you mention here is not particular to this trick alone, but it is general and common risk to use appsheet app.
And also trick i introduce here does not have such a concern.
As the actions will not overwrite the values of existing LIST values, but just add or remove the list item of the log in user, should not affect the other values (other values are useremail address for other users, which is nothing to do with actions.
Hi Tsuji, hope all is wellโฆ I was trying to see this sample, but it seems its already taken down?
https://www.appsheet.com/samples/Sample-App?appGuidString=a96866d4-af6f-48bc-b3d7-8d4cd0030a27
thanks,
As @Grant_Stead alluded to (and the reason I bring this up is because data overwriting with LIST() + โฆ and LIST() - โฆ has just happened to me), what gets written into your database will be only what 1 of the 2 user sees, not both. This problem arises when syncs are delayed and not immediate.
Thank you for sharing the posts, yes, it should be possible, now I got your concerns.
Yes, it could happen.
It is absolutely upto app creators decision if they take such a risk or not.
I appreciate for any decision not to implement such feature to avoid those things to happen, or take a card based on decision the chance should be slim.
the link is not working, can u pls share it ?