<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: setTimeout/setInterval Bug in Android 2.2 WebKit</title>
	<atom:link href="http://www.barneyb.com/barneyblog/2011/02/20/settimeout-bug-in-android-2-2/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.barneyb.com/barneyblog/2011/02/20/settimeout-bug-in-android-2-2/</link>
	<description>Thoughts, rants, and even some code from the mind of Barney Boisvert.</description>
	<lastBuildDate>Thu, 11 Sep 2014 09:58:12 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: barneyb</title>
		<link>https://www.barneyb.com/barneyblog/2011/02/20/settimeout-bug-in-android-2-2/comment-page-1/#comment-244552</link>
		<dc:creator>barneyb</dc:creator>
		<pubDate>Mon, 21 Feb 2011 18:30:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.barneyb.com/barneyblog/?p=1645#comment-244552</guid>
		<description>Dan,

The &#039;debounce&#039; mechanism is exactly what most autocompletes do by default: rolling multiple events which are temporally very close into a single &quot;reaction&quot;.  What I was proposing is removing the delay in execution and just doing invocation on the front side based on the assumption that you&#039;ll get at least two events (since the second event is what allows you to detect the inability of setTimeout to work).  It&#039;s really non-ideal, but it&#039;s the only way I&#039;ve figure out to get responsivity when setTimeout is unuable (the real problem).</description>
		<content:encoded><![CDATA[<p>Dan,</p>
<p>The 'debounce' mechanism is exactly what most autocompletes do by default: rolling multiple events which are temporally very close into a single "reaction".  What I was proposing is removing the delay in execution and just doing invocation on the front side based on the assumption that you'll get at least two events (since the second event is what allows you to detect the inability of setTimeout to work).  It's really non-ideal, but it's the only way I've figure out to get responsivity when setTimeout is unuable (the real problem).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan G. Switzer, II</title>
		<link>https://www.barneyb.com/barneyblog/2011/02/20/settimeout-bug-in-android-2-2/comment-page-1/#comment-244521</link>
		<dc:creator>Dan G. Switzer, II</dc:creator>
		<pubDate>Mon, 21 Feb 2011 15:04:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.barneyb.com/barneyblog/?p=1645#comment-244521</guid>
		<description>@Barney:

This seems like a perfect use case for debouncing a function (which is essentially the way you mention solving it.) If you haven&#039;t seen it, there&#039;s a great function to easily implementing deboucing:

http://blog.pengoworks.com/index.cfm/2009/3/24/Managing-JavaScript-eventsfunctions-using-debouncing

The concept I blog about is actually based on work by John Hann, but my blog has some examples his original article is lacking.

What&#039;s great, is you can easily add to any existing code w/very little effort:

Old (i&#039;m using jQuery syntax for simplicity/readability):

$(&quot;#id).click(function (){
  // do something
});

New, with debouce() prototype:

$(&quot;#id).click(function (){
  // do something
}.debounce(100));

Using the debounce technique above, any time a call is made to the function w/in 100ms, then the code is canceled.

Unfortunately, the debounce() itself is based upon the setTimeout() function, so it&#039;s going to add more to the queue--but the execution of the debouce calls is pretty lightweight and will at least reduce the heavy work such as an AJAX call.</description>
		<content:encoded><![CDATA[<p>@Barney:</p>
<p>This seems like a perfect use case for debouncing a function (which is essentially the way you mention solving it.) If you haven't seen it, there's a great function to easily implementing deboucing:</p>
<p><a href="http://blog.pengoworks.com/index.cfm/2009/3/24/Managing-JavaScript-eventsfunctions-using-debouncing" rel="nofollow">http://blog.pengoworks.com/index.cfm/2009/3/24/Managing-JavaScript-eventsfunctions-using-debouncing</a></p>
<p>The concept I blog about is actually based on work by John Hann, but my blog has some examples his original article is lacking.</p>
<p>What's great, is you can easily add to any existing code w/very little effort:</p>
<p>Old (i'm using jQuery syntax for simplicity/readability):</p>
<p>$("#id).click(function (){<br />
  // do something<br />
});</p>
<p>New, with debouce() prototype:</p>
<p>$("#id).click(function (){<br />
  // do something<br />
}.debounce(100));</p>
<p>Using the debounce technique above, any time a call is made to the function w/in 100ms, then the code is canceled.</p>
<p>Unfortunately, the debounce() itself is based upon the setTimeout() function, so it's going to add more to the queue&#8211;but the execution of the debouce calls is pretty lightweight and will at least reduce the heavy work such as an AJAX call.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
