How T4 templates can help you with maintainable multi-page apps in JQM

We can utilize the power of T4 templates to generate a single HTML page which comprises of multiple separate HTML ‘children’ pages and a layout page, making multi-page apps more maintainable.

Leverage the power of Twilio from Azure Mobile Services

Ever wanted to send a simple text message from your web app? Well, now you can by using Twilio - an awesome cloud-powered API for voice calls & text messaging. Okay, I know that statement sounds like something out of an infomercial, but I recently had a simple need to send text messages from Windows Azure Mobile Services (WAMS), and after a bit of research, I came across Twilio which allows me to do just that.

Using Twilio from within WAMS can be quite tricky at first, but after a few practise rounds, I finally got the hang of it and realized that its actually very simple and easy to use, so I decided to write about how Twilio and WAMS together can solve a simple real-world scenario.

How RESTful is your service?

Web services are everywhere these days, from social media platforms to enterprise line-of-business solutions. It is extremely important to be able to expose APIs for your solution, in order to reach more external consumers on multiple platforms. As a modern trend, we see that more and more APIs are surfacing claiming to be RESTful, but in fact, they're actually just good old remote procedure calls (RPC).

Many of these proclaimed "REST"-style services are implemented not even knowing what the term means, so I've decided to help try explain REST and how to get your services RESTful.

Using the Twitter REST API v1.1 from Azure Mobile Services

Since the retirement of the Twitter REST API v1, I have been having trouble doing a simple query using the new search API introduced in version 1.1 from Azure Mobile Services because it now requires a signed authentication header in the request using the OAuth 1.0 protocol.

I would suggest reading the tutorial on Schedule recurring jobs in Mobile Services which provides a basic walk through on creating a scheduled job in Azure Mobile Services that requests tweets from Twitter and stores it in a table. The reason you should read this tutorial is to gain some background knowledge on the concept for better understanding of my newly devised method of use.

The problem with the [out-dated] tutorial mentioned above is that it still uses version 1 of the recently depreciated Twitter REST API.

Current (old) approach

Here's the code for the scheduler borrowed from the [current] tutorial:

After plenty of research (and failed attempts) on properly signing the request to have Twitter authenticate it using custom code, I realised that Azure Mobile Services is hosted by a NodeJs process and learned that the 'Request'-object comes out-of-the-box with OAuth support.

New (updated) approach

By simply assigning the application's keys and tokens to the OAuth property of the request, it worked like a charm:

Do take note

There are some breaking changes to the API therefor I strongly recommend studying the Twitter API 1.1 documentation. Some of the other changes I had to make to the original code include changing the expected response body property 'results' to 'statuses' as well as the mapping to the.'update' object.

I hope that this saves someone out there somewhere a lot of trouble and time.

Your comments and tweets are welcome. @FanieReynders.

Till next time!

ASP.NET Web API <#= Proxy to T4 #>

One of the coolest new features of ASP.NET is Web API, which allows you to build powerful RESTful services exposed over HTTP. HTTP is not just for serving up web pages, but it provides a platform for building APIs that expose services and data. It is simple, flexible, and ubiquitous.

ASP.NET Web API is all about REST HTTP Services. Unlike Web Services, it does not expose an end-point for meta-data exchange. When consuming a HTTP Service, you will have to create your own client-side code that must serve as a proxy for interfacing with the API.

Like any other WCF junkie out there, I've been working with Windows Communication Foundation for quite some time now implementing Web Services. Not only is it flexible and extensible, but it offers inter-operability, multiple message patterns, transactions and  meta-data exchange etc.

The nice thing about WCF is meta-data exchange, which allows you to generate the client-side proxy-code, contracts and classes used for talking to the service. On the other hand, ASP.NET Web API is more light-weight, operates only via HTTP and is used more for serving CRUD-based operations. The latter, however, does not have functionality (yet) for exposing service meta-data. Until now...