The Problem with Sencha Touch and PhoneGap

Posted on by Dan

(* We are almost a a year on from the original post so some of these things have improved – e.g. orientation is pretty much fixed in phonegap, but not sure if the Sencha issues are)

Firstly this post is not a rant and I remained convinced that Sencha Touch and PhoneGap are a great way to develop mobile – and I think that a cross device standard container to develop mobile apps is what we should all support.

There is almost nothing in the engineering of an html5 engine that could not be optimised for a native like experience – we are not their yet. Even the basics like scrolling a list, for example, are slower in a web view than native. Work like WebGL shows how close things are getting to native performance. The effort in creating that kind of standardised API – optimised per device is not easy; not least because it requires that competitors work with each other via w3c or OpenGL, webkit etc.

This post is about some of the trips and falls I took, and continue to take, whilst developing Money Toolkit with Sencha Touch and PhoneGap. I hope it can serve as a helpful alarm call for any others, like me, naively lured by the apparent silver bullet…

N.B. Some of what I have experienced is undoubtedly to my lack of knowledge; I’m sure the Sencha guys or Phonegap guys could put me straight. I’m not a stupid developer so it is likely that some of these issues, or my own mistakes, will be made by others, so even if the problems I write about are my own fault – detailing them here should still be helpful.

The title may present a slightly unfair impression. Not all of these issues have anything to do directly with the PhoneGap or Sencha Touch codebase, but are simply limitations of browsers, web-views and performance of mobile devices, though Sencha Touch / Phonegap framework does inherit those problems (and go to some lengths to work round the issues)

1. The native WebKit mobile safari browser behaves differently than the UIWebView version.

Things that work via the browser may break from in a UIWebView, which means they may work differently in phonegap (orientation is an example)

The side effect of this problem is that your queries in the Sencha Touch forums (see below) will often not get attention unless it is reproduceable outside of PhoneGap.
The issue below relates to how orientation is handled…

The first picture is after a couple of rotations in the simulator…
Simulator screenshot

and this is after a couple of rotations on the device (screenshot from device added to simulator background to show the shift up)…
screenshot from a physical device

notice the shift – where the sizing and offset is confused by the status bar.

2. Orientation awareness is broken

PhoneGap v 0.9.4 is broken (and despite an improvement so too is 0.9.5) but there are some patches and work arounds, there are sizing issues in Sencha Touch as well, see above.

First of all is the event ‘orientationchange’ or ‘orientationchanged’ ? There is some inconsistency in implementations – so be wary. Either way it does not get fired in the UIWebView.

Here is a good jumping off point to the solution… a thread on the Sencha Touch forum. If you look at some of the other solutions like I did you will end up with problems with resizing during orientation changes when the soft keyboards are displayed, amongst others.

Also the viewport sizing is suspect and inconsistent between the physical and simulated devices – see above.


3. Simulators != PhysicalDevices

Most differences are probably related to speed. See point 5 below – this can work in the simulator, but will fail on a device.

You can’t get away with just testing on a simulator.


4. Sencha touch modal behaviour is basic, and can catch you out.

The masks and boxes are not maintained in a managed stack – they are positioned in absolute layers (via css z-index) so a modal dialog box cant be shown on top of a loading mask.

If you mess with the z-orders in the default css (probably via compas compiling scss) then be aware of the knock on – for example the modal behaviour of the spinner selector can get hidden behind the mask.


5. Sencha Touch singleton Message Box can catch you out.

Due to the implementation of this singleton the message box retains the size from its first drawing – doLayout does not work, the only thing to do is to get it to destroy itself each time it is shown – so it is less of a persistent singleton…

Expect to put something like this somewhere early on in your code

        // this so that the messagebox is redrawn and resized on each showing
        resetMsgBox = function() {
            Ext.Msg = new Ext.MessageBox();
            Ext.Msg.on({
                hide: function(component) { component.destroy(); },
                destroy: function(component) { resetMsgBox(); }
            });
        };
        resetMsgBox();


6. Take care with Sencha Touch initComponent.

Adding async behaviour like loading a store to initComponent – creates intermittent null element errors in the sencha touch library, (after the fact, it is kind of obvious this might cause problems)

So if the component or panel that you are init-ing is dependant on the result of the asynchronous behaviour – like an ajax call or local storage, you could be in trouble.

This stuff does work on a simulator or web browser based – but it is probably good luck that the callback happens fast enough for the init to be ok.

I’ve just thought – what I have not tried is calling the base class init in the async callback – that might work.
What i have done is now move all set up action to happen before initComponent.


7. A trifle – using a Sencha Localstorage Store for name value pairs is overkill.

Sencha touch has to turn the name value pair system of the browsers local storage into a database row type model to mach its store design.

You then have to make this behave like a name value pair – which means struggling with the way rows are id’d
your own localstorage wrapper class will be better for storing app settings in local storage – the native locastorage api is easy to work with.

Having said that if you want to bind your settings to a single form you may well be better off defining a model and a single row store to take advantage of the built in form behaviour.


8. Worst of all…

You know fail early fail fast etc?, to which I add: fail visibly.

Sencha Touch in a browser is fine and will fail fast, your js console is perfect for showing exceptions, debugging, breakpoints etc..

wrapped up in PhoneGap you lose all of this – you have a console.log and console.error but all js exceptions are quietly swallowed – resulting in chunks of code not running after the exception with varying results, failing slowly.

To work round this you end up wrapping loads of your code in try catch blocks – a real pain – and still not the same as running in the browser. You may like me pepper the Sencha Touch library with console.log statements…

            try {
                 me.login.showform();
            } catch (ex) {
                if (ex.message && ex.name) {
                    console.log("someMethod caught an exception of type "  + ex.name + ": ", ex.message);
                    console.log(ex);
                } else {
                    console.log("someMethod caught a poorly-typed exception: " + ex);
                }
                console.log(ex.stack);
            }

Ugly, time consuming, hit and miss, but necessary!


9. Big lists suck

I mentioned lists briefly in the intro but scrolling long lists in Sencha really suck on the devices, on a decent pc it’s fine.

Check out this thread, for something that could help…

(I’ve even submitted a pull request to Lioarlan’s promising extension for when you bind the data source later)

*Update* – Even with medium sized lists there is a problem with a laggy animation. I hope Sencha gets this fixed. In the mean time I have plugged in iScroll4, just in case, but that will need more wiring..
Demonstrated here…


10. Support and Forums.

Ok it may be unfair and unrealistic for me to want free support from the Sencha Touch forums, and PhoneGap group – the reality is the ST forums are pretty good and if you dig, you will find answers, but don’t expect your question to get answered – or looked at by the ST staff. They have their hands full with the paid support customers I guess.

Sencha Touch is still pretty new and we are all learning – so the forums are pretty much take, take, take – I have tried to answer as many questions as I have asked and share what I have learned but a lot of people have given more than they have taken and have lost enthusiasm… for example….

Just a quick note letting people know I won’t be answering to any posts here anymore. It takes too much time, is not my job and I get little thanks for it either.

Sad!

My own defect report (which is not trivial to file accurately) has had no attention at all – it is a verifiable repeatable defect that is present in all their demos and my own app – they must have bigger priorities.

The PhoneGap google group is more responsive perhaps because there are still fewer users than Sencha Touch, but its still a hit and miss affair. they charge $250 for a basic support package , which does not appear to allow you any ‘support cases’ just a private forum and chat room with no guarantees, or a ‘pro’ package for $5,000 – holy shit – that’s most tiny startups out of the equation.

Sencha Touch support is based on an x-credits system and you appear to get a bit more for their introductory $299, like roughly 4 support calls with your x-credits.

There is a great blog post by Eric Boyer with some very useful advice regarding some more gotchas with Sencha Touch…
Sencha Touch Tips and Tricks

This entry was posted in code, mobile, techy, Web and tagged , , , . Bookmark the permalink.
  • Chris Donnelly

    What makes it really bad is that there is also this bug in mobile WebKit from four years ago that nobody has ever gotten around to fixing:

    http://blog.johnmckerrell.com/2007/03/07/problems-with-safari-and-innerhtml

    Basically if you are at or near 100% CPU, Safari’s HTML parser silently fails to parse your HTML.

  • http://savagelook.com/blog Tony Lukasavage

    #2 – orientation awareness isn’t broken, its just not set to handle multiple orientations by default in iOS. Apparently you need to edit the PhoneGap created plist file for your iOS project to allow all orientations you wish to support. Then your “orientationchange’ event will fire.

    #3 – well, this applies to any mobile development framework.

    #8 – Check out weinre (http://pmuellr.github.com/weinre/). It allows you to debug web pages remotely. So in the case of mobile development, you could debug a “native” web app running on a device if you so choose. Should help alleviate those swallowed up Javascript exceptions.

    #10 – Hit the PhoneGap guys up on twitter or their IRC (http://webchat.freenode.net/?channels=#phonegap). I get most of my questions answered there.

    You can find more details about some of this stuff in my recent post on PhoneGap: http://savagelook.com/blog/portfolio/8-things-to-know-about-phonegap

  • http://9-bits.com David Kaneda

    Hi there- Sencha guy here. First off, many thanks for posting your findings- this post will be quite useful to us as we start to work on Touch 2.0. Some fixes are minimal and may even already be underway. Others are a bit trickier, but hey, they don’t call it work for nothing :)

    The only point I want to hit directly is about the public forums. Yes, we offer premium support subscriptions, but we typically pride ourselves on our free forums/community, member engagement, and developer attention. I will only say that there may be some truth to your guess of “distraction,” Regretably, our secs have been pretty consumed with the recent release of Ext JS 4. Hopefully you’ll start seeing some improvement in this area very soon.

    Please don’t hesitate to contact with other questions/suggestions :)

    • admin

      Hi David. Sounds promising! Date for Touch 2 ? :D .
      I can’t fault your tutorials and James Pearce’s efforts, but Its hard when the days and money slip by because its close but not close enough! Anyway keep up the good work, I’m not abandoning this yet (like I did titanium a year ago) but thats another post.
      Btw. I have not even mentioned Android, as the lack of hardware acceleration is a killer imo!!

      Dan.

      • http://9-bits.com David Kaneda

        Re: Android, I agree: their delay on GPU integration has been awful. I will say the team has done a great job getting the framework to perform on Android, but shame on Google for not getting this in 3.0. From what I know, they’re aware that it’s a big missing piece. Still though, I’m sure (knock on wood) this will be there within the next year.

      • http://9-bits.com David Kaneda

        Oh, and no, I can’t give any release dates now :)

  • http://twitter.com/freddywang Freddy

    The most important of all, the droid support is suck. Look at how horrible those rounded buttons rendered on droid phones/tablets. Defeat all the purpose of being cross platform.

    • http://9-bits.com David Kaneda

      Freddy, as a designer, I definitely get the frustration. On the other hand, I think saying that some poor antialiasing defeats the purpose of writing cross platform apps is a bit of an overstatement. Also, we probably could have used images for certain things for better fidelity on Android (you could with CSS too), but we chose CSS3 because it’s dynamic (colors easily shifted in our themes) and way more lightweight. Sencha Touch is about the future of web apps. I have no doubt Android will get better rendering at some point soon (like GPU noted above).

      • http://twitter.com/freddywang Freddy

        David, I agreed. Sencha is still one of the best frameworks for web developers to jump into cross mobile platforms. CSS3 might be cool, but some platforms are simply not yet ready for that.

        I just couldn’t understand why the Android platform, touting their ‘Open’ system to lure developers in, still lacks behind Apple in terms of mobile supports. e.g. Their broken one line implementation of canvas toDataURI, fixed only on HoneyComb. Multitouch, it is obvious that my droid’s native apps support multi touches. When comes to webkit, those touch events stop whenever there were 2 finger or more touches detected (unless you compile the embedded webkit without scrollbars, still only one touched can be tracked).

        I believe within Sencha team, you guys have a difficult time with droid platform as well. Let’s hope there will be a lot future improvements on the next release of Droid especially on the web support.

  • Ramon Gonzalez

    Thank you so much for this post. It’s great to get this kind of insights.

    Extremely helpful.

  • http://www.appsmagnet.com/ Nirav Mehta

    Hi,

    Found this interesting as we are embarking on an important project with Sencha Touch and Titanium.. I want it to run on Desktop, Tablets and Mobile and hence this combination.

    You mentioned you left Titanium a year ago. Were you using it with Sencha or pure Titanium? Would love to get some notes about why you left it…

    :Nirav

    • admin

      Hi Nirav.

      I moved away form Titanium simply because of the performance limitations with Android, and partly because a year ago Android support was not quite good enough. You may be able to work round that, or it may be better now

      If you are simply using Titanium to wrap the Sencha Touch code then have a good look at PhoneGap.

      If I remember at the time the desktop version had not yet included webkit, so only allowed python or ruby afair.

  • Pingback: Article: The Problem with Sencha Touch and PhoneGap | Money Toolkit « Raw Material

  • Matt

    Excellent post. Very insightful!

    • Anonymous

      Thanks Matt :)

      Cheers
      Dan Mullineux
      Money Toolkit

    • Anonymous

      __________________________________

      Dan Mullineux | APR 24, 2012 07:44PM BST

      Hi Michael.

      No worries, hope it helps a bit. Sencha 2 is out, and there are still problems relating to the orientation changes, I have not properly looked at the scrolling performance, but it does appear to be a bit better.
      Devices are getting quicker which is helping, though Android still has problems that makes any HTML 5 framework a risky choice for more complex apps imo.

      ——————————————————

      Disqus | APR 24, 2012 06:06PM BST

      ======

    • Anonymous

      __________________________________

      Dan Mullineux | APR 24, 2012 07:44PM BST

      Hi Michael.

      No worries, hope it helps a bit. Sencha 2 is out, and there are still problems relating to the orientation changes, I have not properly looked at the scrolling performance, but it does appear to be a bit better.
      Devices are getting quicker which is helping, though Android still has problems that makes any HTML 5 framework a risky choice for more complex apps imo.

      ——————————————————

      Disqus | APR 24, 2012 06:06PM BST

      ======

    • Anonymous

      __________________________________

      Dan Mullineux | APR 24, 2012 07:44PM BST

      Hi Michael.

      No worries, hope it helps a bit. Sencha 2 is out, and there are still problems relating to the orientation changes, I have not properly looked at the scrolling performance, but it does appear to be a bit better.
      Devices are getting quicker which is helping, though Android still has problems that makes any HTML 5 framework a risky choice for more complex apps imo.

      ——————————————————

      Disqus | APR 24, 2012 06:06PM BST

      ======

    • Anonymous

      __________________________________

      Dan Mullineux | APR 24, 2012 07:44PM BST

      Hi Michael.

      No worries, hope it helps a bit. Sencha 2 is out, and there are still problems relating to the orientation changes, I have not properly looked at the scrolling performance, but it does appear to be a bit better.
      Devices are getting quicker which is helping, though Android still has problems that makes any HTML 5 framework a risky choice for more complex apps imo.

      ——————————————————

      Disqus | APR 24, 2012 06:06PM BST

      ======

  • Sasasas

    Excellent 

    Post

  • GlasgowKid

    About 8) Use weinre. It enables all my console features back on the device. 
    http://phonegap.github.com/weinre/

    • Anonymous

      True, weinre is awesome work from Patrick Mueller, but I found it pretty unstable when working with Sencha Touch.

      I’m not sure if it was a memory issue, but it would loose the connection, even just trying in a browser, and worse from within Phonegap.

      I guess you are finding it is stable enough to use, might it be worth us trying it out again?

    • Anonymous

      True, weinre is awesome work from Patrick Mueller, but I found it pretty unstable when working with Sencha Touch.

      I’m not sure if it was a memory issue, but it would loose the connection, even just trying in a browser, and worse from within Phonegap.

      I guess you are finding it is stable enough to use, might it be worth us trying it out again?

  • Michael O’Boyle

    Dan, Thanks for this.

    • Dan Mullineux

      Hi Michael.
      No worries, hope it helps a bit. Sencha 2 is out, and there are still problems relating to the orientation changes, I have not properly looked at the scrolling performance, but it does appear to be a bit better.Devices are getting quicker which is helping, though Android still has problems that makes any HTML 5 framework a risky choice for more complex apps imo.

  • dawesi

    2014 and the whole world is different… landed on this one via a google search. Good info for using older versions of St & Phonegap tho.

  • http://www.peratree.com/ Carlos Velasco

    3 years after, some of the points you raised here are still true. I’m exploring Sencha Touch 2.3.x for about a week now and hate to see how some bugs that should not be there are still creeping up. The worst thing is, I can get anything useful from the Support Forum. I’m not a premium subscriber.