A Hobbyist Tackles Windows Azure Mobile Services
So everything's going mobile. We'll all hook into the cloud. Now it's touch-happy Windows 8 and an emphasis on Windows Store apps built with JavaScript and HTML5. It's inevitable, and I get that. But what's a hobbyist programmer like myself going to do, after spending a lot of time trying to learn the Microsoft .NET Framework and finally getting to the point where I can create interesting desktop applications?
Start over.
I don't like JavaScript. Never have. I don't get it--all those functions within functions and spaghetti code I can't figure out. C#/.NET seems a lot more organized and understandable.
But that's just me. More important, what about you, the professional developer making a living in the Microsoft ecosystem?
Well, the company is trying to smooth the transition. Take, for example, the new Windows Azure Mobile Services (WAMS) preview, which I've been playing around with. To recap, this is a Microsoft effort to simplify back-end development for your mobile cloud apps, targeting developers who want to focus on the client side of things and not worry about the nitty-gritty details of interacting with a database and such.
I found a couple things interesting about this initiative. First of all, it's yet another indication of Microsoft's attempt to be part of the transition from a world of PC desktops to mobile devices hooked into the cloud, obviously, along with becoming a good open source citizen.
Second, it's yet another indication of Microsoft's goal to simplify programming, making it more accessible to the not-professionally-trained masses. It kind of feeds into the whole "can anyone be a programmer" debate, which recently garnered more than 760 comments on Slashdot in response to an ArsTechnica.com article.
I decided to see if WAMS delivers, because, of course, if I can do it, anyone can do it. Well, I can do it; it's that easy. I started with some beginner tutorials available at the WAMS developer site, complete with a link to a free Windows Azure trial account to get you started. You also have to enable the WAMS preview in the account management portal. And you need to download the WAMS SDK, which, though clearly targeted at the mobile arena, could only build Windows 8 apps at the time I started playing around with it--though Windows Phone, Android and iOS support was promised soon. (Update: Microsoft partner Xamarin announced an open source SDK for MonoTouch for iOS and Mono for Android, available on GitHub, which also hosts the open source WAMS SDKs and samples.)
The first tutorial, "Get started with Mobile Services," is a simple "TodoList" app, letting you view, add and check-off/delete items from a list of things to be done. First you have to create a service. You need to fill in specific things such as the URL of your Windows Store app, database to use and region (though, curiously, the "Northwest US" region illustrated in the tutorial isn't available yet--you can only use "East US"). In this tutorial you create a new database server and table, instead of use an existing one.
After setting up the service, you create a new app to use it. The management portal includes a quickstart to do this. The quickstart can also guide you through the process of connecting an existing app, which basically just requires adding some references and a few lines of code to connect to your database table, which you make via the portal.
There are also tutorials available for getting started with data, validating and modifying data using server-side scripts, adding paging to queries, adding authentication, adding push notifications and more. These include downloadable projects for C# or JavaScript apps. (Yes, C# and .NET aren't going away; I exaggerated a little bit earlier, but you know what I mean.)
These beginner tutorials all involved setting up a super-simple new database or using a built-in data source such as a collection for your data. I usually check out a bunch of different tutorials when investigating a new technology, mixing and matching and trying different things until I usually get it to work right through sheer brute force, trial-and-error. I wondered about the use of an existing database. I couldn't find nearly as much guidance for that scenario, so I thought I'd explore it further.
I turned to the trusty AdventureWorks example database. WAMS uses ordinary Windows Azure SQL Databases, so I used the SQL Database Migration Wizard to generate a script to build the database in the cloud. You just need the info to connect to the server you set up via WAMS.
Once the wizard is done and your database is visible from the WAMS portal--you can't use it. You have to do a few different things to get it working. That process is described by Microsoft's Paul Batum in response to a Sept. 6 reader query in the WAMS forum. Basically you have to connect to the database management portal, reached from the regular Windows Azure management portal, to alter the schema so WAMS can use it. I wanted to use the AdventureWorks HumanResources.Employee table, and the WAMS service I set up was called "ram," so I ran this "query" from the database management portal:
ALTERSCHEMA ram TRANSFER HumanResources.Employee That changed the schema of just that one table, of course, as you can see in Figure 1.
[Click on image for larger view.] |
| Figure 1. Changing the schema of an existing database table to match your WAMS service. |
That would be quite tedious to do for every table, but there's probably some batch command or something that can change them all. I also had to change the existing primary key "EmployeeID" column to a lowercase "id," which WAMS requires for everything to work correctly, such as the browse database functionality (I'm not sure if anything else is broken). But WAMS still didn't know about the database, so I had to use the portal to "create" a table named "Employee," exactly as demonstrated in the tutorials where you set up a new database from the portal. After a few seconds, WAMS recognized the database and populated the new table with records. If your primary key column is "id," you can browse the database, as shown in Figure 2.
[Click on image for larger view.] |
| Figure 2. Browsing your database table via the management portal. |
Having an existing database at the ready, I used the portal "Get Started" page to grab the information I needed to connect to WAMS from an existing app (it also shows you how to create a brand-new app, which involves creating a database table and downloading a prebuilt Visual Studio solution all set up to use it). This was fairly straightforward. Figure 3 shows the steps and code for C# apps, while Figure 4 shows the process for JavaScript apps. Heeding the winds of change, I took the JavaScript route.
[Click on image for larger view.] |
| Figure 3. The steps to build a C# app. |
[Click on image for larger view.] |
| Figure 4. The steps to build a JavaScript app. |
With the MobileServiceClient variable "client" obtained from the WAMS portal as shown in Figure 4, I simply had to grab the table, read it and bind the results, assigned to the dataSource property of a WinJS.Binding.List, to the ListView's itemDataSource:
var empTable = client.getTable('Employee') .read()
.done(function (results) {
empItemsListView.winControl.itemDataSource =
new WinJS.Binding.List(results).dataSource;
});The read function uses one of four server-side scripts (JavaScript) that WAMS provides for insert, read, update and delete operations (because there's no System.Data namespace to use).
You can customize the scripts as you wish. For a contrived, impractical example, to query the AdventureWorks Employee table and return only three "Production Technician – WC10" employees who are female and single, I changed the read script to this:
function read(query, user, request) { query.where({Gender: 'F', MaritalStatus :'S', Title :
'Production Technician - WC10'})
.take(3);
request.execute();
}Note that a mssql object is also available for situations where a more complex SQL query might be needed. With that object, the read script above could be written as:
function read(query, user, request) { mssql.query("select top 3 * from Employee
where Title = 'Production Technician - WC10'
and Gender='F'
and MaritalStatus = 'S' ", [], {
success: function(results) {
request.respond(statusCodes.OK, results);
}
});
}Normally, of course, the server-side scripts would be used for validation, custom authorization and so on. Such query customization as in my contrived example would be handled from the client. For example, the functionality of my contrived example would be duplicated in the MobileServices.MobileServiceClient's getTable function from the client, like this:
var empTable = client.getTable('Employee') .where({ Title: 'Production Technician - WC10', MaritalStatus:
'S', Gender: 'F' })
.take(3)
.read() .done(function (results) {
empItemsListView.winControl.itemDataSource =
new WinJS.Binding.List(results).dataSource;
});WAMS uses a REST API, so the above function call emits the following GET request header to the server, as reported by Fiddler, the free Web debugging tool:
GET /tables/Employee?$filter=(((Title%20eq%20 'Production%20Technician%20-%20WC10')%20
and%20(MaritalStatus%20eq%20'S'))%20
and%20(Gender%20eq%20'F'))&$top=3 HTTP/1.1That returns the JSON objects shown in Figure 5, as reported (and decrypted) by Fiddler.
[Click on image for larger view.] |
| Figure 5. The JSON objects returned by WAMS, as seen in the Fiddler Web debugger. |
The resulting ListView display when I hit F5 in Visual Studio is shown in Figure 6.
[Click on image for larger view.] |
| Figure 6. The final product: database information displayed in a ListView. |
I didn't explore the tutorials much beyond the basics because I was primarily interested in the new aspect of connecting to an existing database, and this proved the concept. But for mobile apps, obviously, push notifications are important and, as mentioned, some tutorials are available through the portal to cover that functionality and user authentication. The push tutorial, however, uses C#, not JavaScript. One reader commented on the push notification tutorial, "Where is the JS version of this documentation? I am a HTML developer." There was no reply.
Not to be outdone, other readers in the .NET camp complained about the lack of C# code, specifically for server-side scripting, in the WAMS support forums. In reply to the question of whether or not C# or another .NET language would be supported for scripting, WAMS guru Josh Twist replied: "we have no firm plans right now but certainly haven't ruled this out. Again, we're listening to customer feedback and demand on this (you're not the first person to ask) so thanks for posting." Several other readers also weighed in on the subject, with one saying: "I agree. This seems kinda mismatched. The client allows script or C#. But the server side is JavaScript only. Seems the server side would be even a better fit with C#."
There were also some requests for Visual Basic tutorials. In fact, that was the post with the most total views in the support forum. Twist replied, "This is on our list of things to do." (Hmm, I wonder if that "to do" pun--all the tutorials are "to do" lists--was intended.) Microsoft's Glenn Gailey replied with links to the Visual Basic versions of the "Get started with data" tutorial and the WAMS quickstart project.
I'm sure such issues will get ironed out as the WAMS preview continues and user feedback is collected, so give it a try and let Microsoft know what you think. As a hobbyist, I'm certainly giving it the thumbs up. In fact, I was gratified that Twist mentioned the hobbyist as one of three distinct personas to whom WAMS is relevant. Twist listed these three roles in his introduction to WAMS on his The Joy of Code site. He said Microsoft research found that about two-thirds of developers were interested in the cloud but suffered from "cloudphobia," in that "they wanted backend capabilities like authentication, structured storage and push notifications for their app, but they were reluctant to add them" for lack of time, expertise and so on. In addition to the hobbyist, the other two developer types he mentioned were the "client-focused developer," targeted by WAMS, and the "backend developer," who is already experienced in writing server code.
So I'm looking forward to seeing how WAMS matures (hopefully before my 3-month trial Windows Azure subscription expires). As Twist said in a Joy of Code post, "we're working on making it even easier to build any API you like in Mobile Services. Stay tuned!"
What do you think about WAMS? Share your thoughts by commenting here or dropping me a line.
Posted by David Ramel on 10/03/2012