We are using ZIGGEO to record video interviews in our new platform. I have noticed that sometimes it seems that the submitted event is fired more than once when the user submit the video. It doesn't happen all the time. Is it something that we can control?
ziggeo.ZiggeoApi.Events.on("submitted", (data: any) => {
this.addAnswer(data);
});
The addAnswer method is called multiple times, sometimes.
I saw that you send us a message to support as well Jordi, as mentioned there happy to help you with this here or there :)
For those that do not know I work at Ziggeo :)
In regards to the submitted event it would usually be called as:
ZiggeoApi.Events.on("submitted", function ( data ) {
//Your code goes here
});
I am not sure if the way you are using it currently could cause any issues, however what I presume to be happening is that there might be 2 embeddings on the page.
The reason why I say that is because v1's submitted event will fire each time some (any) Ziggeo embedding on your page raises the same.
If you want to make sure that events fire in more private manner, I would actually suggest using v2.
I consider v2 much better than v1 in a lot of different aspects, while both are great on its own (good to point out that these are 2 different systems if you will, v2 is not built on top of v1).
While v2 does not have submitted event it has a better one called verified which fires once the video is uploaded and before processing, requiring less time to tell you if the video would for some reason fail to be processed or not - you can read more about that on our forum
This would make it fire for specific video only, and could not be affected by multiple embeddings so I would suggest trying that one out.
You can see how to set it up:
The embedding
codes
Available
parameters
Events
on all of those pages you can change the version (v1 / v2) and on some even the revision to show you only relevant details for revision you are using.
PS: Might be good to see if this is specific to any browser maybe as well, causing the event to be called again for some reason.
Related
I am working on a robotics project where I control a robot using a joystick and the keys on my keyboard via a browser and a web server on the robot.
Right now the basic (browser side) implementation is a series of functional blocks that read the position of the joystick, the state of the joystick's buttons, and if certain keys have been pressed, sending this information to the server on the robot, using "requestAnimationFrame" as the looping mechanism.
The problem I am experiencing is that the connection between the browser and the robot is too "chatty" - there being updates almost continuously, even if nothing is happening.
Because of this, if I want to watch for a specific behavior on the server side, I cannot because the one useful message is swamped in (literally) thousands of "nothing happened!" messages.
The big problem here is the joystick itself as, as far as I know, there are two and only two events - connected and disconnected. Once the joystick status is "connected" the browser sends zillions of messages.
I tried using the timer object in the joystick API data structure as a way of creating a "something happened" event
Viz.:
function is_something_happening(jsdata, gopigo3_joystick) {
var old_time = gopigo3_joystick.time_stamp
while (old_time == Number.parseFloat(jsdata.timestamp).toFixed()) {
; // null statement so that this just spins. . . .
return;
}
}
What that does is cause the browser to freeze until the next joystick event happens.
Is there some way to program this so that nothing happens until I do something?
Something like a "you go do whatever you want, and when I need you I'll call you" kind of an interrupt or event driven thing - especially for the joystick?
Or, perhaps, there's a better way of debugging and/or trying to track specific events than the brute-force methods I'm using?
=================
Update:
Thanks for ALL the great ideas!
Let me clarify the problem now that I've gotten some feedback:
I am using an event listener for the keypresses and individual keypresses are sent to the robot to be acted upon, (or ignored), as the case may be. (i.e. Is this a key I'm interested in?) And the keyboard event routines work wonderfully - they only fire when I actually press a key. If the joystick isn't running, nothing happens until I press a key.
For the joystick, (i.e. "gamepad"), there are only two native events, one that fires if the gamepad is connected and one that fires when it is disconnected. Period, and that's it.
All, (and I do mean ALL), of the gamepad API demo's and examples assume that you're writing a game that will be played within the browser context so they all use requestAnimationFrame() as the driving element of their "game loop" and things happen at v_Sync speeds or whatever the browser allows.
Because of this, the gamepad object doesn't generate events after it's been started, it just runs and runs.
The only distinguishing factor is the gamepad's time_stamp attribute which increments whenever the gamepad is actually active, hence my use of gopigo3_joystick.time_stamp in my wait loop.
Obviously, I need to create a custom event that, somehow or other, can encapsulate the wait for the timer to increment, and only then allow the gamepad to send messages.
However, as far as I can tell, creating a custom event would simply move the spin-lock, (wink!), from the wait loop to the custom event as I read that customEvent()'s are synchronous - and I translate that to mean "blocking".
Is it possible to create an event that depends on a change in gopigo3_joystick.time_stamp, that will go off by itself and not block the rest of the browser's activity?
Allow me to apologize in advance - this is all virgin territory for me and I do appreciate all the advice and guidance you can give.
I hope that window.addEventListener works for you:
function doTheMovement(){
//your code
window.requestAnimationFram(doTheMovement)
}
window.addEventListener('keydown', function(event){
if(event.keyCode === "YOUR KEYCODE"){
//change direction of motion
}
})
window.addEventListener only goes 60 times per second, so it should be less damaging to your computer.
I have an app that was developed using Phonegap and JqueryMobile.
This app has been downloaded around 15.000 times total in iOS, Android and iPhone.
The code is exactly the same on all platforms.
Once in a while the backend server overloads and when I look at the logs I see that one user is sending hundreds of times the same call. (the users are real persons and I have talk to them about the issue, so its not bot or anything like that)
For me it seems that the either the click event is looping or the server call is looping but could not detect the reason why.
This has happen to 3 users out of 15.000 (as far as I know), and the users have used the app many times before the issue happened. The issue happened on Android and iOS so it seems to me that there is an issue on the jquerymobile/javascript side.
Any idea what could have cause this issue?
I'd say first watch out for design issues in your js/DOM generation.
When you bind an event that has already been bound, jquery will bind it again without checking if that event has already been bound. That is fine if you want to attach multiple
event functions to the same event.
Any way, there are several ways to solve this. One is to unbind the event before binding it, with $.off(), eg.
$("#myDiv").off("click").on("click", function(e) {
// ...
})
another is to check inside the event function if the event has already been fired, eg:
$("#myDiv").on("click",function(e) {
if(e.handled !== true) {
alert('Clicked');
e.handled = true;
}
})
You can find more solutions with their pros and cons here
I ended up disabling the button after the first touch and that fixed the issue.
It seems that the main problem was tapping the button twice, but for some reason I could not detect after that, it entered an infinite loop.
do you do event.preventDefault() and event.stopPropagation() in the onclick function? (without that, browsers behaviour may vary a lot)
Other thought, it may be usefull to hide or disable the buttons at the start of the onclick functions to avoid users from doing multiple clicks.
I'm sure you're already doing all this, but just in case...
Beatports new interface has solved a major problem I was looking for the solution too.
Namely, it keeps a "player" interface at the moment and you can browser to different parts of the site (also changing the url) without reloading or interrupting the player.
I cannot for the life of me understand how they have done this, can any of you guys figure it out?!
Many thanks for any replies I get
Looks like they are just using AJAX to load new content but have taken care to make it work and look pretty seamless. You can get better insight into what events are attached to what elements via the Visual Events bookmarklet. Once you find the code that triggers the event, you can run the obfuscated javascript through JSBeautifier to examine it more closely.
Specifically, it looks like they're adding click handlers to all anchor tags, passing off the event if it was triggered with a middle click or modified with a keyboard key, otherwise passing it to a dynamic loader which handles state and other specific conditions like multiple clicks. The seamlessness of it comes from the way they deal with URLs making every page bookmarkable and the browser history so the back and forward buttons work as you would expect on a "normal" site.
Examining our web logs we find a significant number of clicks are other double-clicks, or repeat-clicks (e.g. when the system is busy and has not reacted quickly enough).
Double-Clicking a SUBMIT button may cause a form to process twice (generally we program against this, but I'd like to avoid possibility of errors that we have not programmed against), but even double clicking a link means that the server has to process the response twice (usually the server will detect a "disconnect" on the first click and abort processing for that - but we still incur the server-time for the effort, which is compounded when the server is under heavy load).
Having said that, there are times when I never get a response to a click, and its only the re-click that works.
One action we do see is a mis-click - click on a link, realise that it was not the desired link, and then click on the correct, adjacent, link - clearly we still need to allow that.
How do you handle this / what do you suggest? and what is the best way to achieve this, generically, across the whole application?
1) We could disable the link/button after click (perhaps for a set period of time, then re-enable)
2) We could hide the "body" of the page - we have done this in the past, just leaving the "banner" pane (which looks the same on all pages) which gives the appearance of the next page loading (but does not play well with the BACK button in some browsers) - this also mucks up users who mis-clicked
You could do this with a combination of delegate and data:
$(document).delegate('a, :button', 'click', function(e) {
var lastClicked = $.data(this, 'lastClicked'),
now = new Date().getTime();
if (lastClicked && (now - lastClicked < 1000)) {
e.preventDefault();
} else {
$.data(this, 'lastClicked', now);
}
});
This will prevent constant rebinding, so should have decent performance.
You can set custom attribute once the element is clicked then check for that attribute: if exists, ignore the click.
This will not change the UI of the element, just ignore repetative clicks.
Rough example using pure JavaScript (as you didn't tag your question with jQuery) is available here: http://jsfiddle.net/248g8/
If this is a big concern for you (and if the obvious answer of "make sure your server always responds really fast" isn't possible ;-) I would suggest a modified version of your (2) is the way forward.
The critical thing here is to give the user sufficient feedback that they feel that something is happening - ideally without blocking off the possibility of the user clicking again in those few cases where something genuinely has gone wrong.
Using javascript to make a small swirly "loading..." graphic may be effective here - and it's easy to set this up so that browsers that don't support javascript (or have it disabled) fall back to the standard link behaviour. Though I would only do this for forms where there is an expectation of taking a long time (or where this might scare the user) - it will make the site rather distracting to use, and in any case (a) users are used to links occasionally being slow on the internet, and (b) your server should be powerful enough to cope with the occasional extra hit :-)
You can disable the link or submit button - but this is frustrating for the user in the case where the submission fails for some reason (my bank does this, and TBH it scares me that they don't realise they should instead "program round" the double-submit issue as you described it!).
I certainly wouldn't disable the link and then re-enable it after a timeout - this would be very confusing for the user...
If you're using jQuery, then maybe you can listen for double clicks across the <BODY> tag and then prevent propagation.
$("body").live('dblClick',function()
{
return false;
});
I would say either:
Just leave it. As long as you've programmed against double-submissions on forms, who cares about a few extra processes?
Disable the link for a few seconds, as you've suggested. That was my first thought before I got to that part of your question. With jQuery (alter for your library of choice):
$('a').live('click',function()
{
var returnFalse = function () { return false; };
$(this).click(returnFalse);
window.setTimeout(function () { $(this).unbind('click',returnFalse) }, 3000);
}
So I have looked through most of the facebook questions here and it has absolutely confirmed my thoughts. Facebook development may be among some of the worst I've ever used. I'll avoid my rant for now, but as a note to where I'm coming from: tried php sdk, worked decently out of the box, found out I need to put the functionality on a pages tab, can't iframe on pages tab, have to use FBML (which they are retiring in two months, yet I can't start testing the iframe approach yet)
Anyway, I run into FBJS at this point. It works "good enough" for most things, but for some reason I can't get an event registered to an object (a select box in particular interest) by adding a listener (as per FBJS documentation). I am able to add it directly to the html object and have it work, but this is not desirable and I would really like to know what I consider the proper way to do it, which involves seperation of logic and display.
What I want to happen: click on the select box, make a selection, display the text of the selection in an empty div (later on adding Ajax but one step at a time here)
Code:
<script>
var obj = document.getElementById('select-id');
obj.addEventListener('onchange',my_func);
function my_func(evt){
var inner = document.getElementById('div-id');
inner.setTextValue('hey'); // for testing purposes
}
</script>
The above code doesn't do anything when I make a change to the select box. However, this behaves as planned:
<select name="find_state" id="find_state" onchange="my_func();">
I will be grudgingly using this method as I develop, but would really love to know what I might be doing wrong or if anyone else has this issue? And if anyone has any opinions on the matter I would love to know of some form of facebook development recommendations as applications, pages, and tabs all appear to behave totally different from eachother, yet it seems that they all should be doing the same thing to me? Is there any unified way to develop across all three of these things, or am I missing something?
Thanks in advance, as well as for the past help!
I think it should be:
obj.addEventListener('change',my_func);
(instead of onchange)
Straight from Facebook documentation:
The third parameter [to addEventListener], boolean useCapture is required (it does not have a default value)
That means that you should have:
obj.addEventListener('change', my_func, false);
Use the following html and your events attached with .addEventListener() start to work. This seems to be undocumented "feature".
<select name="find_state" id="find_state" onmousedown="return true;">
This also enables the event to fire first time the user changes the value of select. Otherwise it would fire only on second onchange event.