The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Home Forums JavaScript Android trouble with asynchronous script

  • This topic is empty.
Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
  • #205258

    So I finally have a touch device at my disposal (yay). It’s not the youngest offspring though so it has Gingerbread 2.3.6 on it. But I noticed that it doesn’t like it a whole lot when using jQuery and combining a $(document).ready() with an immediately invoked function such as (function($) {$.fn.someplugin following it (basically how most extensions are constructed). Oddly even the mousewheel plugin does not break the script but that works a bit different :

    !function(a){"function"==typeof define&&define.amd?define(["jquery"],a):"object"==typeof *and so on*

    Anybody have an insight as to why this is happening? And are there any other operating systems that have this behaviour or is it only because of the relative age of Gingerbread? It can be solved by placing the plugins in a separate link but I’m still curious about the cause behind this.

    I can’t ROM it up to a more recent version but it’s actually quite interesting to do testing on. Seems it’s somewhat of the ‘early IE’ of mobile software. I think I’ll have to ‘retronise’ my own sites a bit so I can at least view them on the device (svg and viewport units for example). This has to be one of the neatest snippets on the web for that :


    This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Do not use it in old or new projects. Pages or Web apps using it may break at any time.

    That’s too bad…


    Edit – but this is alright too :

    Strangely enough the OS on this phone didn’t throw an error on a directly linked image, nor when trying to create an SVG element and getting it’s attribute. The above did work.


    Although I’m still curious about the original question, I think I’ll post some info here that I couldn’t find on the web. Make it somewhat of a nostalgic programmer’s topic…

    First off, here are the fallback checks for svg and viewport unit support – I noticed Modernizr doesn’t have a much more elegant approach than creating a test element and verifying dimensions to see if vh is in effect either :

    if (typeof SVGRect != 'undefined') var endorse = true;
    if (parseInt(muster.css('top'))) var sustain = true;

    The muster object is the loading gif, the CSS is set to 50vh (with a transform, centering it) and the variable will get the value of true if it’s position is not auto (which will happen if viewport units are not working).

    Apart from having to account for these fallbacks, I thought this Gingerbread OS was quite capable with supporting modern features. Just needs a webkit prefix here and there. Two major things though, weird behaviour with elements that have a fixed position (hard to address and not much of an issue on my current webdesign) and the fact that Android 2.3 doesn’t support tracking multiple touches through the browser (and JavaScript). For the latter I really couldn’t google a solution so here’s a simple bit of code that will at least keep track of how many fingers are currently touching the screen :

    var gate = $(window),
    digit = 0,
    release = 'touchend touchcancel';
    gate.on('touchstart', function() {
      gate.on(release, function() {

    This will keep track correctly, strangely enough this doesn’t (I’ll have to wreck my brain over that at a later point) :, function() {

    It’s nice to be able to do live testing. Much better than theory alone – the scripts I previously wrote weren’t correct by a mere smidge (but they are now).



    As interesting an exercise it was to investigate multi touch on this phone, unfortunately the above snippet has little practical value. Yes, a second finger can be detected (the maximum on this OS) but there are too many quirks for it to be useful – any subsequent event will only fire after the initial touchstart is released (a bug)…


    I think I figured out the original issue as well. This only works (at least on this OS) if the feature is actually present :

    if (requestAnimationFrame) // do something

    And it breaks the script when not. So changing it makes using both ‘doc ready’ and immediately invoked functions possible :

    if (window.requestAnimationFrame) // do something

    Checking support for prefixed versions is a bit too much for the small base that it would serve these days in my opinion.


    Nope, not solved after all. Kind of baffling. It not asynchronicity of loading at least but it seems to be related to accessing the default values of the newly created method from the ‘outside’. It’s not just my own plugin but special easing as well that breaks things (it accesses the $.easing object in the aforementioned way).

    Found my own topic again while looking for an answer.



    My bro just checked and it works on Jellybean so it must be a version 2 thing. I’m less bothered by it now, knowing it’s not a general Android issue.


    True enough. It’s the only touch enabled OS I have readily available though. But at least I know that if it works on there, other devices shouldn’t be much of an issue.

    Just to not break things I’ll do a try and catch for scripts that this would occur with so I can look at the pages I made.


    Just for completeness – this is the error it throws :

    ReferenceError: easing is not defined

Viewing 9 posts - 1 through 9 (of 9 total)
  • The forum ‘JavaScript’ is closed to new topics and replies.