And more detail for IE:

I am still seeing a lot of IE8, and more 7 than I expected.

And lastly, mobile devices:

Web Services

You are going to need a way to move data to and from devices, and you’ll need the services before you can build those apps. Start planning on those services now, leverage your existing team to build out WCF or JAX-RS APIs for the data you to need to share or accept. All that talk a few years back about SOA is now coming to fruition with an expanding new generation of consumers of web services.

Here’s another hint on that front:

JSON + REST

Unfortunately, most of that talk about SOA a few years back focused on SOAP services, and things like WS-*. Mobile devices have a constrained network pipe, so you want the smallest message possible. Sorry XML. Also, mobile devices tend to be CPU constrained, so you don’t want to do a bunch of parsing either. Sorry XML. As an added bonus, web apps are good at consuming JSON as well.

Start with services, then move on to the mobile apps.

This is an expansion of my thoughts on part of this article.

I used a Mac for this experiment, and at this point I am sure it would be a different experience on a PC.

jQuery Mobile + PhoneGap

Install

The install of this is very easy. Download the .zip files, extract them to wherever you would like. I used Eclipse for my IDE. Following the tutorials on both the PhoneGap and jQuery Mobile sites was simple enough to get up and running.

Development

Since I am experienced at both web development and Android development, getting going was pretty easy. I simply imported the necessary files into my project. The tutorials and docs were fairly easy to follow, and I had my demo app running before lunch. Debugging is a bummer if you use the app on the emulator or a device. You are better of using a browser to develop with and debug on, and then deploying to the emulator or device for testing. The code/debug cycle with the browser is very quick and efficient. But you still have to go back to the emulator/device a fair amount which is pretty slow. I didn’t use PhoneGap for anything but being a container, so if you were integrating with any native plugins the browser for debugging might be out.

Given it’s roots, jQuery Mobile will integrate well with server-side frameworks like ASP.NET or JSPs. jQuery Mobile doesn’t have a broad set of controls or features. For instance I wanted a date picker, but I needed to go and search for one because the platform I was targeting didn’t support the HTML5 date input control. I ran into a similar issue with data binding. You will need plugins and other libraries. jQuery plugins are abundant, and it’s not easy to separate the good ones from the bad.

For me, one of the downsides of jQuery Mobile is the UI. It looks like an iPhone app. If I’m building a hybrid solution, I don’t want my Android or WP7 apps to look like iOS apps. There is a terrific ThemeRoller tool, but in the end it still looks like what it is. I’m sure if you delved into the CSS you could get it to look more styled. If you have a high design component to your app, it could be hard to get there.

Sencha Touch 2

Sencha Touch was initially a mobile-web solution, but with version 2 Sencha has introduced the ability to package the app for iOS and Android.

Install

The install experience for this was frustrating to say the least. You need to download the SDK and a SDK tools package. This was really not clear on the download page, and I didn’t figure this out until trying to use the tutorial. The tutorials want these items to be installed in very specific places, so if you have a “standard” way of setting up projects this isn’t going to work for you. Also, you need to install Compass, and that isn’t documented anywhere except in the video, so if you are not inclined to watch a video (like me), you’ll have issues. I’m an experienced developer, it shouldn’t be this hard to get something up and working. As with any framework, there are often more than one way to accomplish tasks, and this is no different in ST2. In general the code used in the tutorial didn’t match up well with the task paradigm in the documentation, so that was frustrating as well.

Development

Since Sencha Touch 2 (ST2) is purely text file development, I used my favorite web editor WebStorm. Any editor would work fine, so this is a bonus for not being tied to Eclipse. You have to do more with the command-line, and I’m sure there are folks who want the IDE experience and folks who want the text editor experience. The command-line tool creates a project structure with all the dependencies set (like Rails, Maven, etc.), so getting going was quick once I got the tool working.

Getting to know the framework for ST2 is certainly harder if you are not a JavaScript guru. Most of how ST2 works is for you to write JavaScript that renders into HMTL at run time. You see this when starting up the app/site, there is an ellipsis on a blue background that displays while the rendering is going on. This makes the code/debug cycle slow. And if you make a mistake, this screen never clears. You have to have a JavaScript dev tool running at the time to know what went wrong.

The paradigm for ST2 is very different, heavy on the JavaScript. If you are a traditional web developer, this will be a tough shift. ST2 does not lend itself to integration with server-side frameworks because you would need to be emitting tons of JavaScript instead of HTML. For ST2 you need to embrace generating you content via JavaScript and writing Ajax web services to get the data from the server. I actually like this paradigm, but it’s going to be tough going for the .Net crowd to adopt this paradigm. This paradigm fits well with native mobile development, because you have to develop the services for data. So now you aren’t completely locked in to the hybrid platform if you want to make a change later. I’ll try to explore writing more HTML with ST2 and less JavaScript and see if it can work more like traditional web development.

I tried to use the command-line tool to build the hybrid Android app, but could never get it to work. I’m certain it is a permissions problem (remember I’m using a Mac), and from here it would probably be a better solution to wrap the ST2 app in PhoneGap. The tool also only took one image for the app icon. I’m not sure how that would work out for the other device sizes on the Android platform. Packaging ST2 this way felt like maybe it was a rushed feature.

ST2 has tons of controls, lots of great functionality like data binding built right in. It’s a steep learning curve though. ST has been criticized in the past for feeling slow, version 2 is supposed to improve upon that. Still, everything is rendering in the browser layer on a memory and processor-constrained device. I predict user’s experiences with speed will vary.

Conclusion

I think neither one of these are a clear winner. jQuery Mobile will force you to spend time to find other solutions to features you need, while ST2 will force you to spend time with its steep learning curve. I think this only further rebukes the myth that mobile web or hybrid is somehow cheaper than building a native app. PhoneGap is clearly a necessity for either of these for a hybrid solution, so you will still need separate projects and hardware platforms to get the work done for a cross-platform app. And as soon as you start using images in your designs, the effort for the creative team will quickly equal the need for creative work in a native development environment. You will need to spend significant time with CSS media queries and Modernizr to deal with the slight differences you will encounter between platforms and browsers. If I was forced to choose today between these two solutions, I would choose ST2 + PhoneGap, simply for the sheer amount of functionality built into ST2, despite the steep learning curve. I don’t believe either of these is THE solution for hybrid or mobile web development. I’m still looking….

1. Slow Down
   One of my main gripes about meetings is making a decision on the spot. At least for me, my best thinking occurs somewhere else after the fact. I need time to consider the implications and possibly see alternatives before I can be certain it’s the correct decision. So to make the most effective decisions, postpone immediate decisions as often as possible. Make the time to explore the alternatives.
2. Break from the Pack
   This is the basis of one of the main arguments by Ted Neward in his keynote at Codemash 2012 that I already covered. The “best practices” are found in books, on the web, in corporate documents. Generally, these can get the job done. But I doubt it’s always the best or right solution to a problem. It’s certainly the safest. If that’s the goal, then go that way. But in business we are always looking for the advantage, and I doubt the best practice gives you the advantage. More likely, it’s a starting point which you should use to find the best solution. Slow down and think about how the best practice solves the problem and if that is really the solution you need.
3. Encourage Disagreement
   I have long used this as a metric in my interview process. I want team members who will express their opinions. Usually the best answer to a problem is not the result of the idea of a single person, but an amalgamation of ideas or compromise between multiple ideas. If no one can disagree with the boss/tech lead/manager then you might as well adopt only the best practices and call it done.
4. Engage with Maverics
   I think this one is a little harder in an enterprise environment, since often a big corporation is not the home for maverics. I think what you need to do here is actively engage with people whose viewpoints are not aligned with yours. People who think differently about a problem may provide you with some insight you may have missed or not considered properly. I have always thought of code reviews as a source for this. I approach them as a way to see someone else’s problem solving at work. I’m not interested in telling them how they did it wrong, but seeing what they did well and adapt that to my problem solving toolkit.

The problem occurs because the browser only trusts calls from the exact same domain, unless the server says that it trusts your domain (or all domains). This is by design.

So the resolution is to have the server tell the clients what domains it trusts for cross-site calls. Seems simple, but of course there is more to it than that.

When the browser detects a cross-domain call, it behaves differently if your service is configured correctly. If you were expecting your JavaScript code to perform a POST to a REST URL, that is no longer what happens, at least initially. Instead of performing the POST, the browser actually sends an OPTIONS verb call to your REST URL. This is called a preflight request. Your service needs to respond to the preflight request containing the OPTIONS verb and let the browser know which parameters are acceptable on a cross-site call. If everything matches up and your client is in an allowed domain, then the browser performs the original POST that you expected and everything continues on normally.

If your service is not configured correctly, the browser doesn’t cooperate and you don’t see anything at all. Again, this is by design.

Configuring The Service

From an HTTP point of view, what we need to do in code is add the following name/value headers to our HTTP responses:

• Access-Control-Allow-Origin
• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Max-Age

The first, Access-Control-Allow-Origin, needs to be added to any request so the browser knows to use the OPTIONS verb for cross-site calls, which just error out otherwise with an XmlHttpReqeust Error 101 in JavaScript. The other three need to be added in response to the OPTIONS verb request. 

The Access-Control-Allow-Origin header can be added with one or more values. If you expect any client anywhere to call your services, like Google Maps does, you want to add * for the value, allowing all callers. Otherwise, the most secure way to use Access-Control-Allow-Origin is to set it for the specific domains you want to accept. Say your services are at https://service.yoursitehere.com, and your client site is http://www.yousitehere.com, you want to set the value to http://www.yoursitehere.com.

The code adds the Access-Control-Allow-Methods header to tell the browser which HTTP verbs your calls will accept as cross-domain.

By adding the Access-Control-Allow-Headers header, you control exactly which HTTP headers are allowed in the actual request which follows the preflight request.

The Access-Control-Max-Age header tells the browser how long to cache the preflight call result before doing it again during this browser session. I set this long to avoid multiple preflight requests.

In my case, I’m using configuration-less WCF services as described here. In my experience much of the pain with WCF in the past has been with the complex configurations, and this option circumvents that problem substantially.

The C# Code

So this is how it’s done programmatically, in Global.asax in my case:

 protected void Application_BeginRequest(object sender, EventArgs e)

 {

 }

I put it Global.asax in order to avoid having each request handle multiple verbs and calling the handler in each service call. The downside to this is that any non-service request also gets the additional header and processing as well. For me, there are only service requests in this app so this is not a big deal.

The Client

I’ve regularly used jQuery to access services from client HTML code. It’s not complicated, the important parts are formatting the call to send JSON properly in response to our preflight request, which includes the dataType, contentType and data parameters to the $.ajax call.

 $.ajax({

 });

Tools

If you are debugging REST services, you need some good tools. I have used Fiddler, the Chrome Developer Tools (the Network panel in particular) and the Chrome app Advanced REST Client Application successfully.

References

This post is the basis of the fix I’m describing

W3C description of how the HTTP process works

FireFox and CORS, also a lot of good info on HTTP headers

This year I was fortunate enough to attend CodeMash in Ohio. Just like last time, it was an amazing experience. The speakers, the venue, the food, the folks in attendance. All of it made for a great experience. I learned, I laughed, I left exhausted.

General Observations

I went to mostly mobile-oriented talks, and over a two day period every single speaker I watched used a Mac. On top of that, all the presentations were very minimalist. I don’t know if that’s the tools on the platform or folks finally rejecting the glitz of PowerPoint and focusing on content. I hope it’s the latter. Sales folks take note.

Mobile developers are actively rejecting the BlackBerry platform. One even pointed out how his company just stopped accepting work for that platform. Another who was building a mobile product pointed out that the expense of supporting the BlackBerry platform across three different active versions was too much. Has any technology died so publicly?

In the Java-oriented talks I saw, there was very little Eclipse. Mostly I saw IntelliJ Idea. This was interesting for me, because I love ReSharper for .Net work, and have been using WebStorm for HTML5/JavaScript coding.

Notable Quotes

As always, there were a number of notable quotes that summed up so many aspects of what was being conveyed.

Ted Neward, Keynote Address

“Reject the Goal of Reuse”

I’ve been seeing this message more and more lately. Reuse happens so rarely unless you are actually building a library, that otherwise you are probably wasting effort and introducing bugs by striving for reuse in code that was not necessarily intended for reuse.

“Best practices are merely average”  “Best practices == avoid thinking”

The bigger the company, the more they care about best practices. So there will be fewer risks, fewer rewards, and overall mediocre results. Seen it, sadly still living it.

“Reject the temptation of the familiar”

I’ve been working on this one for almost the last year. I’m learning the mobile paradigm, learning Java, writing services in something other than .Net. I am very surprised how much I had blinders on when I was immersed in Microsoft-only development.

Bill Pugh, Effective Use of FindBugs in Large Software Development Efforts

“The challenge for FindBugs is to find the intersection of stupid and important.”

I have long been a fan of automated tools for helping me tighten up code. His quote sums up the intent perfectly, finding the stupid mistakes you may have made that could result in important problems in your code.

Ted Neward, Android: Where You Can Stick Data

Answering questions about SQLite on Android: “It’s not Oracle, and if you treat it like it is you’re doing it wrong.”

Understand your platform and user paradigm. Enough said.

Bruce Eckel, Polyglot Programming: The Power of Hybridization

“You don’t know where the difficult parts will be”

So don’t plan to optimize anywhere, you won’t be right ahead of time. I have seen this myself more than once. The real trouble isn’t visible at the beginning. See any article on estimating for another aspect of this issue.

“Typing is noise”

Bruce favors languages with minimalist syntax, believing those languages express your solutions clearly for those who come after to read your code. This has inspired me to start learning Python.

“Go will replace C++ as the low-level language used in high performance applications”

I’m recording this for posterity. Bruce says he’s remarkably good at predicting these things, even though no one listens. I’ve read some of his work and have faith, so you read it here first.

Bruce Eckel, Reinventing Business

“The best people would be leaving companies all around you to come work for you if you were hiring the best”

There is a metric for your recruiting staff.

Geeks Are Funny

After dinner on Thursday, there was a Pecha Kucha competition which was great entertainment, hosted by the inimitable Scott Hanselman, with a geek celebrity panel of judges consisting of Ted Neward, Julie Lerman, and Keith Elder. The winner was Leon Gersing, the heartfelt and real @rubybudda. Here are a couple cell phone videos of the event:

Jon Skeet Coding in the Style of Glee

Mel Grubb Urinal Rules

Leon Gersing On Love  Tiebreaker (Talking to a set of slides he’s never seen before)

Just as good as the talks was the Twitter stream on the big screen behind the presenters. You see a brief glimpse of it at the beginning of Jon’s talk. Geeks are funny.