6 Replies Latest reply on Nov 5, 2014 11:46 AM by Jon Tara

    JQueryMobile swipe on Android KitKat is unreliable due to WebView behaviour. Anyone got a fix/workaround?

    Andrew Haigh

      Hi,

      We were working on a nice swipe-to-navigate UI on RhoMobile 5, but ran into an Android WebView problem on KitKat which prevents swipe touch events being processed:

       

      Details are as noted here, but essentially it means only 5% of touch swipe events register on KitKat devices (iOS and older droids are fine):

      https://github.com/jquery/jquery-mobile/issues/5534#issuecomment-41387998

       

      Does anyone know of a convenient workaround for KitKat devices? (Yes I know jqm or android communities is probably a better place to ask, but this is a long shot, and I am using Rho5 after all )

       

      Thanks,

      Andrew Haigh

        • Re: JQueryMobile swipe on Android KitKat is unreliable due to WebView behaviour. Anyone got a fix/workaround?
          Robert Galvin

          What about just building for API 18 instead of API 19, so you don't get the new WebView Control?

           

          Here is some info on the new control that may be helpful:

           

          Migrating to WebView in Android 4.4 | Android Developers

          1 of 1 people found this helpful
          • Re: JQueryMobile swipe on Android KitKat is unreliable due to WebView behaviour. Anyone got a fix/workaround?
            Jon Tara

            Browsers are a moving target. They are constantly being updated. It is difficult to impossible for libraries to support browsers that have not yet been released.

             

            This is a particular problem for cross-browserJavascript UI libraries, like jQuery Mobile. They quickly go out of date. It's the opposite of a server, where software that works will (generally) continue to work, and so we are used to creating stable platforms that we don't rush to update.

             

            The version of jQuery Mobile packaged with Rhodes is now quite out of date, and should not be expected to always work correctly with new browsers.

             

            You can check jQuery Mobile Issues on GitHub for specific issues (search Issues and checkin comments), and take a look at release notes to see if there is anything specific for KitKat. But each release has many fixes for many browsers and support for many new browser versions.

             

            In any case, you will have better luck supporting newer browsers with the latest jQuery Mobile, 1.4.4. However, it is a large change from 1.3 and so may not be very practical for an existing project. jQuery update policy is normally to provide incremental updates for the previous version, but I note that the last 1.4 incremental update (not sure, perhaps the past 2 updates) was NOT followed by a new 1.3 increment, so perhaps that policy is no longer being followed.

             

            Unfortunately, this is the nature of the ever-changing world of browsers, and you will need to plan for this. If you have control of user devices, then this may impact device selection or selection of OS version.

             

            I see in the link above, there is a "quirks" mode available, and so you may be able to build for API 19 while still retaining previous WebView behavior. See the article.

            1 of 1 people found this helpful
              • Re: JQueryMobile swipe on Android KitKat is unreliable due to WebView behaviour. Anyone got a fix/workaround?
                Andrew Haigh

                Hi,

                Thanks for the replies, and sorry for not providing an update sooner. We had already updated to jQuery 1.4.3 and we thought we had tried the quirks mode by changing our build.yml to point to an earlier Android SDK, but it seems not to make any difference - swipe events are still very unreliable on KitKat.

                 

                Has anyone got any hard experience to offer on this? If you read the original linked jQuery thread, it appears the jQuery developers themselves didnt believe there was any fix as such, only that it would be working again in Android 5.0. Which doesnt help KitKat users unless/until they upgrade their devices

                 

                Cheers,

                Andrew Haigh

                  • Re: JQueryMobile swipe on Android KitKat is unreliable due to WebView behaviour. Anyone got a fix/workaround?
                    Jon Tara

                    JQM 1.4.5 was released on Oct. 31. I noticed that it had at least one bug fix for iOS 8.1. I did not check for KitKat fixes, you might want to check the release notes.

                     

                    As well, I note there was no update to jQuery Mobile 1.3.x. It does appear that there's been an unannounced change of policy, and so I would consider that 1.3 is not likely to receive any further updates despite jQuery Foundation's "one version back" support policy. It would probably have to be majorly broken to receive an update, IMO.

                      • Re: JQueryMobile swipe on Android KitKat is unreliable due to WebView behaviour. Anyone got a fix/workaround?
                        Andrew Haigh

                        Hi,

                        Just looked at the Changelog but nothing mentioned and given prior discussion found it to be a design choice problem in KitKat I wasnt expecting any kind of fix:

                        http://jquerymobile.com/changelog/1.4.5/

                         

                        Thanks,

                        Andrew Haigh

                          • Re: JQueryMobile swipe on Android KitKat is unreliable due to WebView behaviour. Anyone got a fix/workaround?
                            Jon Tara

                            That Issue is a bit unfocused, (it started as an issue about swiping on a panel) but I see it's homed-in on a specific Chrome swipe issue. It does look like some fix is forthcoming in a future JQM release.

                             

                            What kind of swipes are you doing, though? It seems to be a conflict between swipe and scroll. If you aren't doing both in the same direction it seems it's not a problem? (But I'm not sure why one would do swipe and scroll on the same axis, and how you would distinguish them...)

                             

                            If your project is new or relatively new, I would consider finding some alternative to jQuery Mobile. Do other libraries/plugins/scripts have this problem with swipe on KitKat?

                             

                            In any case, JQM is absolutely not necessary in a Rhodes project. Depending on your needs, you can use no framework at all, just jQuery, jQuery and Bootstrap, etc. You will get better performance with almost any other solution than JQM!

                             

                            For many of the types of apps written using Rhodes/RhoStudio "pretty" is not so important as "fast". Fancy transitions and effects are really not a priority with users. Not being slowed-down in data entry is. As well, many of the devices we work with have limited capabilities, because they are ruggedized devices with long life cycles and are at this point - ahem - "mature" products.

                             

                            I think the JQM project lost a lot of ground because of an early design decision to divorce itself from jQuery UI and now they reversed that decision and it is a very painful process back. They are trying to make the two libraries compatible. This has been a distraction, IMO, from keeping up with browser changes. They also made some major architectural changes with 1.4 and should have called to 2.0 just to make it clear how different it is from 1.3

                             

                            I work on a suite of apps that has been written over a period of 4 years, and to switch gears at this point for us would be very costly. If I were to start a new project of this magnitude today, my first priority would be to determine whether using JQM would be appropriate and if not choose an alternative. I suspect my choice would be the latter.