i am trying to figure out how to count a “view” every time a user views a post. i know how to count a click on a post, but i want the views to count as well, similar to twitter. you dont have to click on a post to view it, and it somehow still counts views, rather than clicks.
how would i do this?
i am thinking about adding something in the workflow where when the post is centered on the screen, it is considered a view, or when a user scrolls to a post in a repeating group, and the post is near the center of the screen, then that counts as a view.
so far i have:
Workflow: Do every time>repeating group’s post is…
Hmmm, yeah, in the stuff I’m doing, the only limitation I haven’t found a way around is that I can’t get information out of repeating groups. There’s just no way to find out what’s going on inside them automatically. I’ve got some good work done as long as the user can do it visually and manually. I don’t know of a way to get the data invisibly and automatically.
You can get data out of repeating groups so long as the action is fired each time something changes in that repeating group.
In other words, I don’t think there’s a way to get data out from multiple cells at once. However, if you have, say, an input field in a RG then you can save that cell’s value anytime the value is changed.
In theory, this will store the data in your database correctly. In practice, it means you’re firing a whole lot of workflows and sometimes they don’t get stored properly, based on my experience with RGs anyway.
One method I’ve experimented with but not yet implemented in a live app to test for performance:
Install the Toolbox plugin -> add JavascripttoBubble element on same screen with the RG
Insert dynamic data (Some_text_string_Current cell’s Unique ID or index) to create a custom HTML ID on each cell in the RG element (#Some_text_string_1,#Some_text_string_2,#Some_text_string_3,etc)
Using the JavascripttoBubble workflow+element options you can fire events based on if the current cell is visible within the viewport/window (based on the HTML ID) – this would be driven by custom JavaScript code
I can’t stop to add all the details right this second, does this help a little? The Toolbox plugin is very powerful once you get comfortable integrating it with default Bubble functionality. In my own experience the JavascripttoBubble method tends to work well when dealing with large numbers of unique elements, especially RG cells.
If firing events that write to the DB too rapidly is a problem, maybe you can store these ‘viewed’ events in a custom state, then every x minutes or upon some kind of user action you take this custom state list and write it to the DB.
