Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I know that you can capture the event when a person clicks a “like” button from within a Facebook tab via the edge.create method, but what im wondering is if there is a way to capture when the Facebook like button at the top of a page is clicked, the purpose being to be able to find out which tab within my fan page is generating likes.
When the page reloads i will know that the page IS liked, but i dont know if the like was generated from one tab, or another tab on the same page.
The only solution I can think about which is sufficiently accurate is the following:
Start a session on server side with the first app request.
Remember the like state from the signed_request and the timestamp when it was issued.
Embed a javascript interval in your tab app(s), firing an AJAX request to your server every couple seconds. I think you have go with something between 2 and max 5 seconds.
The AJAX request refreshes only the timestamp in the session.
If the user clicks like on top of the page, now, the whole facebook page gets reloaded – so does your app and you get a new signed request which has the liked state now set to 1.
Have a look at your session > was the state 0 before? Yes? Is the timestamp max. 6-10 seconds old? Yes? Well, its most likely then that the user liked the page while being on the tab.
I hate the solution with the AJAX interval polluting the network (and on a big site with many users this will stress your server), but I can’t think of any other solution, because there is no other way to keep track if the user is still looking on your tab. If the interval is too high, the user would be able to navigate away to the wall or info section and like the page there. If he directly returns to your tab after this, you wouldn’t be able to track if he left the tab at all…
Another solution would be to listen for the body.unload event and fire a AJAX request to the server, telling you that the user has left the tab, but it is possible that the event never gets fired on certain browsers or the AJAX request is not fast enough to be processed before the tab page unloads. On the other hand would this solution take way less resources of both the users network and your servers performance.
This are just theoretically solutions and have to be tested, first!