jQuery and jQuery Mobile

October 29, 2011 in Programming

jQuery Mobile logo

jQuery Mobile logo

I promise, this blog isn’t all C#.  I do a significant amount of JavaScript development too.  I am working on, hopefully, a intuitive templating library with JavaScript, but that is nowhere usable by the public yet.

Another part of JavaScript that I am heavily into (as is most JavaScript developers) is jQuery.  jQuery is nothing new, it has had a dominant presence in the JavaScript framework for a little while now.  It is easy to see why, of all the frameworks I have dabbled in, jQuery is:

  • Small.  When gzipped and minified, it is 31K, as of 1.6.4.
  • Easy to learn.
  • Great performance.
  • Leverages knowledge you may already know – primarily CSS selectors.

With jQuery, there are a couple of sister frameworks for building UIs: jQueryUI and jQuery Mobile.  jQuery alone is a utility, event, and DOM manipulation framework.

jQueryUI is a making-web-2.0-applications-alive framework, with a support for styled buttons, auto completes, toggles.  Primarily, it provides rich support for things like dialogs, progress bars, tabs, dragging, dropping, sorting and animation.  It is a mature framework that is going under re-construction for a simplified API so extensibility is even easier.  I use this for the REAL TIME REHAB project I work on on the side.

jQuery Mobile is a new addition to the jQuery suite of frameworks. jQuery Mobile specializes in making mobile- and touch-friendly UIs that can be used across mobile devices and desktops.  It is in an RC2 version (release candidate).  The full version 1.0 is literally in the coming week or two.

jQuery Mobile is something I have used quite a bit in the last few months.  A project at the day job required a touch screen interface, so we started using jQM (a beta version) as the basis of the UI.  We heavily modified a good portion of the CSS and the framework was hacked or extended to support features we needed.  It has serves us well, even though we never got beyond a late beta version of jQM (just too late in our development cycle to upgrade to the RC and trying to fix any breaking changes).

Admittedly, I have become a huge fan of jQM.  In its short lifetime, it has become a real feature complete framework:

  • HTML5 semantic markup defines most the interface.  You can make a mobile friendly website with jQM without writing a single line of code.  You provide “data-” attributes to elements that jQM recognizes and transforms the elements for you.
  • Small.  about 25K gzipped and minified.  That is smaller than the core jQuery library.  The gzipped and minified core CSS is about 7K.
  • Works well on a variety of devices and browsers.  Click here for the graded browser support.
  • Provides support for the major form input elements.  Has custom select list support and support for some of the HTML5 input controls. jQueryUI, on the other hand, doesn’t even address input elements very much at all.
  • Gracefully degrades.  It will simply degrade back to default HTML rendering if your browser sucks.
  • AJAX friendly.  Forms can be a classic style, or automatically use AJAX-submitted forms.

The framework, as of RC2, is easily extensible.  It uses, essentially, the same widget framework that jQueryUI uses.  It is easy to make new components.  They even added a theme-roller to easily make your own theme swatches (http://jquerymobile.com/themeroller/ - it is in beta – also, just to make sure I do not appear totally biased, jQueryUI also has had a Theme Roller for a long time) and get on-demand, custom CSS.

How easy is it to use?  Well, for fun, and because I have meaning to update my resume for a long time, I made a quick interactive, jQuery Mobile-based resume.  I added some custom script to do some list sorting and special handling for the popup menu on the footer of each page.  Everything else is semantic HTML5 that jQM interprets.

Also, note, while the resume looks like it spans several pages, it is actually all just one HTML file.  jQM can split up an HTML document into several jQM “mobile pages”.

The CSS for the interactive resume also is resolution-aware.  Using CSS media queries it can format the layout of the page to support a few resolution levels.  Try looking at it on a desktop, then on a mobile device (portait and landscape).

The page is self-contained.  The custom CSS and scripts are in the page itself.  The external libraries (jQuery and jQM) are included via a public CDN.  You can take this page, change it with your information, and upload it somewhere else, and would probably work just fine.

Personally, I didn’t hand-craft each line of HTML.  On my local development machine, I wrote a quick MVC3 app that spits out the HTML file.  I then just copied it to my web space.  The reason I did it this way is that I can make different views for, perhaps, a PDF version, a highly summarized version or a straight text version as needed without changing my data model (which is a quick and dirty .NETclass with my “resume data”).

Final NOTE:  I am not looking for a new job.  I did want to update my resume as the previous version was getting ugly and dated.

Click this and take a peek at my resume!

Sugary C#, part 2

October 25, 2011 in Programming

What was part 1?  LINQ vs. LINQ was part 1, essentially.  As I was writing about using LINQ syntax versus extension methods, I started thinking about all of the other obvious syntactic sugars in C#.  While, personally, I am not a fan of the LINQ syntax, there are other sugary parts of C# I do not mind so much, and actually use quite a bit.  Today’s article is about a single keyword that seems to have a lot of C# developers (at least the ones I know) split down the middle of usefulness/annoyance.

var

Yup, that keyword seems to get a lot of opinions on why it should be used and why it should not be used.

For the uninitiated (e.g., those who are new to C# or have lived under a rock for three years), var is a shortcut to declaring identifiers in a particular scope.  Unlike JavaScript’s var, which is the only way to declare identifiers and all identifiers are not strictly typed, C#’s var is completely type-safe and bound at compile-time.

That is right, the C# compiler will infer the type of the value being assigned the identifier at compile-time and statically give the identifier the correct type.  There are some caveats:

  • A value must be assigned to the identifier when the identifier is declared.  This is how the type is inferred.
  • Once the type is determined, the type of the identifier does not change for entire scope of the identifier.
  • The type will not change at run-time.
  • If the value assigned to an identifier declared with var is ambiguous, the compiler will complain.  You will have to cast the value to a specific type to compile without errors.  (especially true for assigning a null value)
  • var can only be used in a local method scope.  You cannot use it in member declarations in a class or struct.  It cannot be used as the return type of any method.

var is not a dynamic type (C# 4.0 does provide a dynamic type. I might go over that in a future article.).  An identifier declared with var has full Intellisense enabled.  You can even hit F12 on the var keyword of the identifier being declared and Visual Studio will jump you to the correct declaration in your project.  So, why would you want to use var?

  • You don’t want to worry about identifier type declarations when changing type names or namespaces.
  • Faster to type, no need to find the correct type to declare your identifier with.

Yup, pretty much pure sugar.  So, what would be the reasons to not use var?

  • Lack of readability in some cases, especially if the type of the identifier is not evident in local scope.  Intellisense helps this greatly, but not everyone will be looking at code in Visual Studio.
  • It is lazy.

Maybe laziness is not a problem for you (it certainly isn’t for me), but the readability is a problem for a some developers. Let’s consider a couple of examples.

Example 1:

public string ExampleMethod1(string arg1, int arg2)
{
    string arg2str = arg2.ToString();
    return string.Format("{0} {1}", arg1.Length, arg2.Length);
}

public string ExampleMethod1var(string arg1, int arg2)
{
    var arg2str = arg2.ToString();
    return string.Format("{0} {1}", arg1.Length, arg2.Length);
}

The above example has two methods that have the same exact result.  In fact, the MSIL generated for the above methods (sans the method name) is the same.  The example that uses var has good readability and is understandable from a quick glance.  The type inference is based on a local variable and the fact that it is assigned the result of the ToString() method gives it away that arg2str is a string.

Here is another example:

Example 2:

public string ExampleMethod2(string arg1)
{
    MyClass c = MyStatic.GetInstance(arg1);
    return c.ToString();
}

public string ExampleMethod2var(string arg1)
{
    var c = MyStatic.GetInstance(arg1);
    return c.ToString();
}

The example here that uses var certainly has a readability issue now.  Not knowing anything about the static method MyStatic.GetInstance() raises questions on what type c is.  The compiler knows and Visual Studio knows.  Moving your mouse over c in the return statement will reveal the correct type.  Also, the MSIL should be the same.  The compiler is 100% OK with this.  Your eyes, however, may have “trouble”.  Especially, perhaps, if I gave you just this snippet of code:

public string ExampleMethod2var(string arg1)
{
    var c = MyStatic.GetInstance(arg1);
    return c.ToString();
}

If this was all that was presented, you would have no idea what type c was, without being told.

var - love it or hate it, it does make coding faster and easier.  It is not always readable, however.  Personally, I am guilty of over-using it at times.

Are you a var-hater or a var-lover?

C# – LINQ syntax vs. LINQ extension methods

October 24, 2011 in Programming

The LINQ syntax in C# is purely syntactic sugar for the LINQ extension methods in the System.Linq namespace.  Now, syntactic sugar doesn’t bother me so much if it seems to provide a better coding experience while still being readable.  However, the LINQ syntax in C#, however, has always reeked of “excessive crap that I have trouble formatting and reading.”

In short: I don’t want SQL in my C#, I want C# in my C#!

Anyway, here are two examples of the same LINQ query.  The first example uses the LINQ syntax, the other one just calls extension methods.

C# LINQ Syntax:

from u in Users
where u.Type == UserTypes.Admin
orderby u.Name
select new { Name = u.Name, Email = u.Email }

Regular C# syntax

Users
    .Where(u => u.Type == UserTypes.Admin)
    .OrderBy(u => u.Name)
    .Select(u => new { Name = u.Name, Email = u.Email });

Now, I don’t know about the rest of the C# world, but the LINQ syntax seems very un-C#-like.  Also, for long queries, I am not really sure a of proper way to format the LINQ code.  Also, I can never remember the subtleties of the LINQ syntax (admittedly, this is from disuse).

The second form seems more natural to me.  Each line has it’s own defined lambda expression.  I could use different lamda expression arguments for each individual call.  I can ALSO mix-and-match some of the calls.  Like:

Users
    .Where(u => u.Type == UserTypes.Admin)
    .Select(u => new { Name = u.Name, Email = u.Email })
    .OrderBy(u => u.Name);

The output of this would be the same.   Also, using the regular C# syntax and Intellisense allows me to explore the LINQ extension methods and find alternate ways of tackling a problem with LINQ that the LINQ syntax does not allow me to do.

There is one thing that the LINQ syntax does make easier:  Joins.  The extension method syntax can get a bit messy for join operations, especially when you get into outer-joins.

Your preference? Am I missing something by using the LINQ syntax that would really make using it easier?

Programming, stuffs, and, very occasionally, cats – WELCOME

October 24, 2011 in Miscellaneous

using Cats.Linq;

Yes, I made a blog – the world will not explode, I promise.

Switch to our mobile site