Tuesday, October 21, 2014
Thursday, April 10, 2014
Frequently, the clients I build applications for request the ability to customize their sites for their own clients. In the past, this might be accomplished by selecting a different CSS stylesheet for each client. That has the unfortunate drawback of trying to maintain styles across multiple copies. Another approach would be to generate style information in the page itself, but this doesn't provide the benefit of caching style information on the client side.
The approach I'm using currently is parameterized XSL transforms that can generate a style sheet on the fly from a template via an MVC controller action.
After creating an empty MVC project and adding a HomeController and View/Home/Index.cs, I set up my layout as follows:
In this layout, I've split my stylesheets into two categories. Structure concerns itself with size and placement. Brand concerns itself with colors, but may also include typography.
The branding in this case isn't a CSS file, it's an XSLT file.
I've added parameters to the XSLT file that can be supplied at runtime to change the appearance. This content gets merged with the simple brand.xml in the controller.
The controller uses a customization class stored in the models folder. In this case, to simplify things, I'm hardcoding the values and basing the customization on host-headers. Feel free to pull the information from a database or base the customization on user role, etc.Cross-posted from http://anexinetmobility.blogspot.com/2014/04/custom-site-branding-with-xslt-and-mvc.html
Monday, January 13, 2014
Wednesday, December 11, 2013
Friday, December 6, 2013
Here is a collection of things I wish someone told me when I was first starting with Sencha Touch.
- Take baby steps - Sometimes it's best to make sure that you have your layout hammered out before you create that inherited view with 37 tabs, a header toolbar, a footer toolbar, and multiple profiles for phones and tablets.
- Learn to use the chrome developer tools - OK, I know how to use the Chrome developer tools. Using them for Sencha is a slightly different matter. You have to know what you're looking for. For instance - newcomers to sencha create complex views and are baffled when they run the app and....nothing. They don't see a thing. If you inspect the HTML with Chrome, you should at least see your element's xtype. If you don't, that's a sign that you have a bad reference. If you see your view's xtype, but the height/width is 0px, that usually means that you gave it a layout but didn't properly specify the size.
- Don't overuse element IDs - This was a difficult thing to learn. I had previously been working with jQueryMobile and gave EVERYTHING an ID. This all worked in my initial, small scale tests. Once I ramped up with multiple instances of views and inherited views, this quickly caused problems. This is because every ID must be unique throughout the entire DOM and there isn't any real concept of scope. Instead of using element IDs, rely on using the DOM through the magic of Component Query. Component Query works similarly to jQuery selectors, except you can use an object's xtype as a means of finding it.
- Use the command-line build tools - You're going to use sencha cmd eventually when you package and deploy the application, so it's best to make sure that your application builds correctly. Not only will this identify issues with your code, but I've seen cases where one syntax works before building, but fails when the application is packaged. It's a tiresome process coming up with workarounds at the last minute.
- Organize your SASS - It starts off slowly, the app.scss file has one or two things in it. By the end of your project, it's a tangled mess and you've got elements scattered throughout it. SASS allows you to break your styling into multiple files and bring them in with the @import directive. One possible approach is to separate the styles into common layout, typography, theme, and view-specific files.
Monday, November 4, 2013
One of the mobile apps that I've written has to access a remote site for authentication. This allows the client to make use of multiple factors for confirming a user's identity and also confirms to the user that they're passing their credentials to the right institution.
When the application was originally written, I made use of the ChildBrowser control. In order to make sure that we were seeing the right content only if the user REALLY has authenticated, we would use the ChildBrowser's clear() method.
I was recently asked to update the application to ensure that it didn't lag too far behind the most recent versions of the tools. Updating to Cordova 3.1/PhoneGap 3.1 involved getting rid of the ChildBrowser and moving to the InAppBrowser plugin. PhoneGap makes this plugin REALLY easy to integrate with your project. All you have to do at the command-line is to issue the following command:
cordova plugin add org.apache.cordova.inappbrowser
Unfortunately, once I changed the remainder of the calls around to work with the new interface, I found there was no method to clear the cache. There are options on the Android side of things that will clear the cache as well as the session cache, but nothing on the iOS side.
It didn't take too long to figure out, but here's what I ended up with:
All I added was the one-liner:
[[NSURLCache sharedURLCache] removeAllCachedResponses];This article is cross-posted from the AnexinetMobility Blog