The first thing I hit was Sencha Architect (2.2.1) quirks. Most friendly IDEs make it hard for noobs to make mistakes, but SA seems to let you shoot yourself in the foot easily. Things I hit on the first day when playing with it:
- added a JSON-P datastore and didn't load it and previewing the site on the browser showed nothing.....only after looking at the Javascript console did I see a cryptic "Uncaught TypeError: Cannot call method 'substring' of undefined" message
- after telling the datastore to autoload, the javascript console gave a cryptic "Uncaught TypeError: Cannot call method 'indexOf' of null" error because I didn't specify a URL to load the data store from
- SA sometimes gets into funky states where it generates object IDs properly and you'll get weird errors like "Cannot create an instance of unrecognized alias: widget.JrXTx" in the console; fiddling w/ the object id and itemId and displayName or recreating the affected object in the IDE fixes this
- you can put in values that are all wrong for selectfields values; you can put in 'a', 'b' when the syntax should be {name:'a', value:'a'},{name:'b', value:'b'}
- you can put in values are are invalid for your application icon; you can put in multiple values w/o the curly braces to indicate it's an array
That said, after I realized it was just a thin UI layer over Ext.js and Sencha Touch. When I realized this the next day, it was easy to develop with by watching it generate code and verifying the resulting Javascript code made sense; it's actually an opinionated view of how Ext.js and Sencha Touch should be used in an MVC pattern w/ an automated code generator for portions of it, much like Spring Roo in the Java world. I also realized the published application was just a regular HTML web site, so I could substitute in sencha-all-touch-debug.js for sencha-all-touch.js and get reasonable errors and stack traces. It took less than a day to rewrite a simple Android app using Sencha Architect, though admittedly, it doesn't look very polished. A few tips to help others:
- you can enable debug versions of the Sencha Touch JS file by clicking the Debug checkbox on the Library icon in the Resources (would have been more obvious to make it a publish option):
- trying to get a backgrounds on a form is painful...the HTML DIV level of nesting of a form panel where you have to apply a background is scary:
and that also means that specifying a class (cls attribute) on your form panel in SA will put it at the wrong level and it'll be ignored. For a background graphic to be visible you have to do a more complicated CSS selector to attach the image to the child scrolling element:
.TxPanel .x-scroll-container {
background: url('img/txbackground.png');
}
- in your panels, if you are using device specific toggle controls, do *not* enable scrolling if you can. The reason is that these controls are not native to web browsers like checkboxes are, so the style sheet replaces them with a few overlayed graphics, but when scrolling, these graphics are repainted so they don't light up with each other when you scroll the panel. It's amusing looking, but users will hate it.
- don't use "id" to reference an object. Use the itemId property. You can get the container with an id since it's a singleton. Then you can use ".down" to reach any fields inside the container:
Ext.getCmp('myLayout').down('#field1').show()
- you also need to provide multiple profiles and layouts/views and graphics/icons for all the different device types/sizes but they only provide simple examples of phone/tablet layouts w/o taking into account multiple resolutions. Just because it's an HTML5 app underneath doesn't mean it'll autoscale for your devices like when you view a website on a device browser because layouts are different.
- handling orientation changes can be done by using Application/Viewport and adding an orientationchange event handler to switch to the appropriate card in a cardlayout:
Ext.getCmp('HiresLayouts').getLayout().setActiveItem('view1Portrait');
Unfortunately, Sencha Architect doesn't support Ext.js' profiles which is how you'd normally select cardlayout containers for a specific resolution, so if you want to use SA, you'll have to put all your resolutions in a single CardLayout container. It's actually pretty odd that there's almost zero documentation on how to handle different orientations/resolutions in the SA 2.2 docs, so the above is just a workaround until whenever they add support for it.
Next we get to the Blackberry packaging tools which were the most annoying things I've ever used. The bbwp command line tool creates an infinitely recursive directory structure if you run it on a non-empty directory. It shouldn't be possible, but somehow the directory structure created can't be deleted by Windows Explorer or the command line. Then if you tell it use an empty directory to output to, you get an out of memory error. And the bbwp command line tool tries to copy sources even if you only give a "-v" command line parameter to it to find out which version it is; bbwp executed by itself is missing other parameters so it shouldn't even run. If you need to delete the infinite recursion directory tree, I don't recommend trying to rename each subpath to a single character as some sites mention...use robocopy or the deepremove tool instead; when this happened to me, it created 45 *thousand* nested subfolders which took robocopy 20min to delete.
Their alternative Ripple packaging system which is a Chrome Extension also can't be installed by drag/dropping to a Chrome extension window as documented and if you install the version in the Chrome Extension store, it doesn't include the build services that are needed for packaging. The workaround I had to do was download Blackberry's ripple-ui.crx file, then unzip it into a directory, then in Chrome's Extension page, turn on developer mode and use the Load Unpacked Extension button to install it.
Another alternative that's not documented on Blackberry's official web pages is a contributed Ant build script. There's one for their Webworks SDK as well as one for Cordova/Phonegap. For Android developers, this makes the most sense instead of using their weird bbwp batch script from hell that fires up a Node.js server to run their build script and creates infinitely recursive directories. Be sure to point it to your Sencha Architect publish directory and exclude the "*.xds .architect .sencha/ metadata/" files in buildTasks.xml. Be aware that Sencha has its own build.xml so you can't put your own build.xml script in the publish directory, which is why you have to point the build.xml at this directory. Then it's a simple matter of doing "ant build.bb10.prod" for publishing, "ant build.bb10.test" for debugging, and "ant build.clean" to clean out the directories. There are no horrible infinite recursive folders to clean up either :-)
The initial run in the BB10 simulator was nearly uneventful except for not being able to load any JS/CSS files until adding the following to the config.xml file:
<access uri="http://cdn.sencha.com" subdomains="true"/>
<access uri="https://cdn.sencha.com" subdomains="true"/>
Or you can also use this:
<access uri="*" subdomains="true" />
Surprisingly, this does *NOT* work, even though it should disable all web security features:
<feature id="blackberry.app">
<param name="websecurity" value="disable" />
</feature>
This is because the default in Sencha Architect is to use the CDN to load the Sencha Touch files. You can tell it to use local files by doing Package/SetupProject and pointing it at a downloaded version of Sencha Touch, but remember to also go to your Library for your project and change the Base URL property (something that Sencha Architect should have done) or it will still reference the CDN.
As for final build size, hybrid web apps will always be larger than native apps. You can trim the size down by including less of the Sencha Touch library, but you still have to have the extra libraries to talk to the extra features you get on mobile (location, NFC, wifi, etc.). My Android application APK file is 1.8MB with the Airpush SDK linked in and only .8MB without. The Sencha/BB version w/ sencha-touch-all included and only the phone layout (more layouts = more resolutions = more graphics) is 8.7MB, so it's 10X bigger than the native Android version; adding ad support would require minimal space since it'll just be an extra HTML layout. You can use Sencha's CDN to load Sencha Touch to shrink the app down to 6.7MB, but if the CDN does go down (and it did for nearly a day when I was testing my app), your application will not work.
Overall development time wasn't bad. One day to learn the tool enough, one day to rewrite it entirely w/ Ext.js (never used it before since I mostly use jQuery), one day fighting w/ the BB10 Webworks build tools, one day to polish it enough that it doesn't look too ugly, and one day to package it properly w/o CDN access for BB World (most of that time was checking for app rejections). That's compared to roughly the same amount of time to do the Android version where I also had to create all the graphics assets.
I found the multi-resolution/orientation support clunky at best w/ Sencha Architect however; Android's Fragment system is much better thought out. If you're planning on using Sencha Touch, I'd recommend using Sencha Touch and Ext.js with a regular JS editor (and avoiding scrolling and non-native HTML controls). IMHO, Sencha Architect is not ready for prime time :-(
1. ken08/29/2013 20:50:43
Thanks, Mike. I was debating whether or not to post a link to this in the product forums.
Hope Sencha Architect 3.x addresses some of these issues...I'd say the orientation/screen size profiles is the biggest one. E.g., the app I wrote worked fine on the BB10 Z10 but not the Q10 because the screen got truncated (I disabled scrolling because the toggle buttons would separate during scrolling because they're two images sitting on top of each other).
2. Michael Mullany08/29/2013 18:02:26
Homepage: http://www.sencha.com
Thanks for checking out Sencha Architect! You found some of the product corners! We're working on improvements all the time: I've forwarded the blog to the product team.
Su | Mo | Tu | We | Th | Fr | Sa |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |