Friday, January 9, 2015
Thursday, January 8, 2015
One technique that I've found to make great looking icons in mobile applications is using SVG icons. Sites like IcoMoon and FontAwesome provide free and premium icons packaged as SVG graphics or true type fonts. The advantages of these icons over PNG images is that they are by nature resolution independent. Instead of having to include multiple copies in your project at different DPI levels, you can include a small ttf file and have access to the images you need at any resolution.
For my project, I needed a check mark (available), an 'X' (unavailable), as well as icons for refresh and calendar. I wandered over to icomoon.io and selected the icons using the icomoon app. From there I was able to download a custom font that included the icons as well as a demo webpage showing the character strings necessary to render them.
With the font downloaded, I added it to my Xamarin.Android projects /Assets folder.
Looking at the HTML file included with the zip download, I could see that the characters for my icons are using ea0f and ea10 for unavailable and available respectively.
In my list row adapter in the Xamarin.Android project, I defined these characters in a dictionary.
Finally, when defining the layout for the row, I loaded the font and set the character text and color according to the data. Reserved rooms have a red X and available rooms have a green checkmark.
Note that the line that is setting the text to e953 displays the separate calendar icon.
The rendered list appears below (unfortunately, it was a busy day to use real data, so no available rooms are shown)
This is cross-posted from the Anexinet Mobility blog
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.