My customer came to me with the latest idea from his organisation: They needed 3 identical tablet apps for the 3 major platforms: iOS, Android, Windows8. For certain reasons the apps should really be identical and he was fully aware of the fact that the price to pay for doing so, would be reduced user experience on at least 2 platforms, but more likely on all of them.
So here I was, what more could I ask for. Being a mobile app developer, it was finally time to test a cross-platform technology. For too long, we (or at least I) had refused to go in that direction for the most obvious reasons: that it will reduce the overall user experience and maintenance costs will increase. But now I had a project, where platform variations were already set aside to some degree.
The perfect app for testing a cross-platform framework.
Okay, here is the project: My customer needs a tablet app to help him register his products. With the app, he creates a “client”. The client has a location and a number of sub-locations, and in each of the sub-locations, he finds a number of products.
Example: The “client” may be “Coca Cola, Hamburg”, the sub-locations may be “Left wing, 1st floor” and “Storage building 4”, and the products are…well, the products.
By registering the products, old and new, he may offer his clients replacement products, service agreements and much more.
So using the app, he creates a client entity with 15-20 pieces of information like name, address, zip code, some SAP info, preferred language and more. Then, he creates the sub-locations with exactly 3 pieces of information on each one, and then finally adds the products to the sub-locations. A product has around 20 pieces of information.
The customer may attach pictures to the observations, and all the registrations are assembled in a json-structure and uploaded to a server for further analysis.
So bottom line is that we need an app which allows us to enter different text one-liners, select from predefined lists and take a couple of pictures. A large list of known products exists and for entering the specific type/name of the product, we will implement a type ahead functionality.
So we need roughly 3 screens with a number of input forms and a database to support the type ahead feature.
This really calls for a web application or for web technology, but the truth is that I am so not a web developer, so how do we attack this? I decide to use some higher level abstractions, and in order to realise and implement the project, I decide to use Sencha Touch with the Cordova (formerly Phonegap) library to give me access to the camera and to build it into the required platform specific applications.
From Wikipedia I get that this is indeed the right frame work:
Being mobile app developers, we are used to XCode, Visual Studio, Eclipse + Android SDK. All of these IDEs/packages are self contained environments for building apps.
For my project, I need two machines, my Mac and a Windows 8.1 PC. On my Mac, I already have XCode. To – eventually – build the iOS version of the app, I need to install Java, Ruby, Sencha Touch, Sencha Cmd, Cordova, NodeJS + make a couple of modifications to my PATH. I slowly get an unpleasant feeling in my stomach that this is definitely not the state of development, year 2014. But hey, the cool thing is I only have to add Android SDK to the list and I can also build the Android version.
I decide to build the app before I prepare the Windows laptop for building the Win8.1 version of the app, so I start out…
With some help I manage to set up the basic app MVC-framework and I am good to go.
By now, 3-4 days have passed and although I could have built the entire app for iOS natively by now, I accept the learning process entailed. However, I get some painful flashbacks of JSF and web development as it was 10 years ago: Sencha Touch is a component abstraction on top of the underlying DOM, and GUIs are built programmatically with all styling going through CSS. Is this really how far we have come in the past many years?
Well, Sencha Cmd comes with a built in (Jetty) web server which is very convenient for developing: I press save in my editor and reload the page in my browser – there we go!
But unfortunately, I am now at a point where the nightmare starts: When I package and run it on my iPad everything breaks down. Controlling keyboard and focus of text fields seems more or less random. Scrolling the screen to prevent the keyboard form hiding the text fields is close to impossible. Sencha Touch cannot properly paint forms in a scroll view in a panel which does not cover the entire screen (ie. a popup like window), black shadows and shades appear around the text fields.
Googling for help does not help much, and using my Chrome JS debugger I can see that the “object” hierarchy of my components does not match the online documentation; notions of ‘scrollable’, ‘scroller’, ‘vertical scroll’ are different. And there is no useful way to get to the underlying DOM. myTextField.focus() seems to work in the desktop browser, but not with an embedded Safari (it has been disabled by Apple to prevent the keyboard from appearing and disappearing when you scroll in a web page with auto focus fields).
I end up spending day after day trying to control these things and to give the app a decent behaviour. After way too long, I finally start having an app which acts more or less consistent and works kind of okay on the iPad, even with type ahead functionality using a WebSql database.
The user experience is far from what you would expect from an iPad app – it may look like the native thing but it definitely does not feel like it.
When scrolling the screen while editing a text field, the cursor stays on the same spot on the screen, so you can ‘scroll away from the cursor’, see the following screen shot:
By now, I could have had a way better native app on both iOS and Android, but I am learning, and once I get to know Sencha Touch, I will be much better off!
The time has then come to compile and build the Android version. Now the nightmares start again. The same things are wrong, controlling focus, keyboard, scrolling, selection from lists. Everything just acts differently and it seems that small timing issues as ie. when you request focus just break things down. Fixing it for the Android, then sends me back to the iOS, where things start to fall apart again. The app/framework does not maintain a proper navigation stack so the back button on Android simply quits the app. The turn around time is hopeless. Everything works somewhat okay in Safari and Chrome on my desktop, but built into an app and run in the mobile browsers, it simply fails.
But again after too many days, I finally have something that works okay on an iPad and almost okay on the Android.
I give the app to my customer for initial testing. I am not happy doing so, and he is not happy with the feel of the app but from a pure functional perspective it kind of works, so he accepts it, or he accepts the fact that at least it is on its way – until he tries it on his Android device which is not the same model as mine. Same issues: Strange keyboard and scrolling behaviour.
Without doing much more about it, I buy a Surface tablet to try it here. Time has come to install all of those frameworks on a Windows PC. Everything installs quite easily but the project cannot compile. After some searching, it seems that ‘something’ requires Ruby 1.9 and not 2.0. Okay, quick fix – but the compilation now fails at another spot with no useful error message. An entire day is spent googling, searching, trying, until a colleague of mine by pure coincidence does a cordova update project command. And then it compiles.
So,finally it is time to build it to a real app with Visual Studio…and this is then where the next challenge sets in: The embedded database, WebSql, is not supported by the newest Internet Explorer! The alternative is called IndexedDb and is not a database but an object store. So I need to introduce some platform specific extensions to deal with it. Only to face the next limitations: IndexedDb cannot do a ‘like %’, it can do ‘and’ and ‘or’ but it cannot combine them – so doing even the simplest ‘where’ clauses is effectively impossible. Working around it is to introduce a couple of shadow columns in the object store and to be creative with uppercase/lowercase conversions.
But it still does not work okay. The good old issues appear again, keyboard, focus, scrolling – text fields are even drawn differently and wrong on this platform and once again, the behaviour is not the same in a vanilla Internet Explorer and the built-in embedded browser. And it gets even worse: When bringing up the type ahead/auto suggestion or even just a plain popup, all the fields in the main window underneath are cleared out for some strange reason, so in my case it means that I start typing a name and after 3 characters, the auto suggestion popup shows me the possible suggestions, but the textfield in which I am doing my typing is cleared!
And it seems that the Windows tablet caches resources in the app bundle so the turn around on my trial-and-error path includes changing code, command line compiling, deleting the app from the tablet, build and reinstall from Visual Studio.
Too many weeks have gone by and at least 80% of the time spent has been spent on not doing business logic or real app work, but merely dealing with platform misbehaviour and differences, errors in Sencha Touch and the incomplete nature of the frame work.
A small PDF manual must be included and brought up by the press of a button, but the embedded IE can not link to a bundled PDF, the text “Not supported” is printed in the log. The cure here is to convert the PDF to a series of PNGs to show – on the Windows platform.
And though it may sound like the app was somewhat finished, this is not the case. Even showing the app to the customer is below all decency.
So let us conclude one thing: When you test these kinds of frameworks, do yourself a favour and build a real app for real users. Making HelloWorlds is too far away from reality. If I had done only test examples and tutorials I would have ended up with the wrong assumption that it actually works!
Based on what I have seen, it is hard to see where Sencha Touch fits in. You could claim that it is not fair to state that it is useless, based on just one example. Maybe my app, 3 screens with simple input fields, was just too much?
But if you want to code an app for just one platform, it definitely yields an overhead in time spent, and the bad thing is that when doing an app for multiple platforms, the development overhead just seems to explode. On top of that, add the price of poor user experience.
And I can not imagine how future maintenance will be…
Btw., how did it all end? Well, driven by respect of ourselves, our customer and the end users we gave up and rewrote everything natively, spending less than 1/4 of the time doing all 3 platforms.
Interested in our iOS training? Check this out!