4 ms·
I was not surprised to see the word "Sencha" in this article, but I was surprised to read it took them 12 months to develop the app. Where I work we actually re
by marknutter 14y ago
I was not surprised to see the word "Sencha" in this article, but I was surprised to read it took them 12 months to develop the app. Where I work we actually replaced two in-development native apps with one cross platform Sencha app which only took about 4 months to develop. This was with only two developers, and like with most frameworks the first 80% went extremely fast but we ended up fighting against it for the last 20%. The performance, especially on older Androids, was unacceptable.
But instead of doing another complete 180 we decided to instead go with a hybrid approach like LinkedIn did - use native when performance is key, and HTML5 everywhere else. We just re-launched the app using all custom html5/js/css and native ui elements and animations where necessary and it was a complete success. Not only does the app perform really well on even very old Android phones, but it absolutely flies on newer devices. The best part, especially when compared to using Sencha, is that all of our code which was written in angular.js will be used on the web app and native desktop apps. We are very close to having the vast majority of our code being shared between every major platform our users may use.
I love when articles like these get popular because it scares people away from using HTML5 in any way and gives us a clear advantage. Keep fueling the FUD, we'll keep our productivity advantage :)
- nullspace 14y agoWould be great if you can share more details how you went about the hybrid html5 - native app route. For instance, did you scrap all the work you put in with Sencha and start from scratch? And how did you go about combining native elements and html/js/css, and how did angular js tie into this?
- marknutter 14y agoYes, we did scrap the Sencha app and start from scratch. Because Sencha Touch is really only designed for mobile devices with touch interfaces, you can't really re-use the code for web apps, so there wasn't much to salvage. We also were not very comfortable with Ext to begin with. For JS frameworks we decided between Backbone.js, Angular.js, and Can.js (because we had previously used JavascriptMVC on our web app). We fell in love with angular.js and went that route. The main reason to use native UI components is to allow smooth scrolling on older Android devices which don't support fixed elements like top and bottom nav bars very well. Both on iOS and Android the top navigation bar and bottom tab bars are done in native code as well as the Facebook-style drawers that reveal other sections of the app. In all, we use three Phonegap enabled webViews and three major native UI components (top bar, bottom bar, and a custom "quick add" control). We pass messages back and forth from the native app to the javascript app via phonegap's native bridge, like when a user taps a native button or the javascript app changes tabs and needs to inform the native app. We used grunt.js to help manage all our development and build workflows. It concatenates our files for us, creates separate builds for iOS and Android (and other platforms now, too), compiles and minifies our CSS, etc. It also runs our test suite which is another big advantage to using HTML5/JS instead of native. Most of our code has test coverage and it's very easy to automate using grunt.js and testacular.js. If you're interested you can check out the app on the Play and iTunes App stores; it's called Kona Mobile (it's the mobile app for our main offering, http://kona.com http://kona.com).
- nullspace 14y agoThanks for the explanation! Makes a lot of sense.
- deleted 14y ago[deleted]