When Written: Dec 2013
In my last article I investigated the Intel XDK mobile phone development environment. Using this free set of development tools it is comparatively easy to build mobile apps for most platforms using the universal but yet to be finalised HTML5 – JavaScript route rather than using the mobile operating system’s native code.
A new version of Intel’s free mobile development tool XDK
The particular app I was building stored all the data on the phone in the local data store which HTML5 gives you, doing things this way meant that this app was not reliant on having an internet connection to work, this being a requirement by the client. However another requirement was that the mobile app should be able to email out an Excel spreadsheet as an attachment which contained the data in a format that could be used by head office. Because the ‘sendEmail’ function of the mobile framework would not allow the attachment of files, probably because of sandbox security reasons, it was decided that the best way to achieve this would be to provide a web service that would take the data from the app and produce an Excel spreadsheet and then email it to an address contained in the data. To do this required a web service to be built which I decided to do using ASP .NET and C#.
Creating Web Services in Visual Studio is a simple enough task now, and I have covered it before, however what is different here was the significant amount of data that needed to be transferred. It really was too much and too varied to be transferred by the simple passing of a variable by calling the web service with something like:
MyWebService(MyValue1,MyValue2…)
The best way to transfer this amount of data is by using JSON which stands for JavaScript Object Notation and whilst it has its roots in JavaScript it has become a language-independent data format. Most languages and systems have ways of reading and outputting JSON in much the same way as they can read and create XML. Whilst you could use XML for this task, the advantage of JSON over XML is that it is more compact and has the ability to use arrays. An example of JSON data might look like:
{
"rwceditors": [
{ "FirstName":"Jon" , "LastName":"Honeyball" },
{ "FirstName":"Steve" , "LastName":"Cassidy" },
{ "FirstName":"Paul" , "LastName":"Ockendon" }
]
}
To send this data to your web service you will use the normal HTTP POST which you will be familiar as one of the two ways of sending data from a web form, the other being of course ‘GET’. Where things are a little different, is in describing the data type when you send it, so that the receiving application knows that you are trying to send JSON formatted data rather than information that might be expected to come from a user filled in web form. You do this by setting the ‘contentType’ and the ‘dataType’ parameters. Now whilst JSON and web services have both been around for some time and that most frameworks purport to support this type of data exchange how this is achieved in code is not always easy to find out.
If you do a search of the web of how to achieve this between a client using JQuery and a .NET web service then you will find an incredible number of different suggestions, most of them very complex and requiring many lines of code. These are all unnecessary if you are using .NET 3.5 or above so I thought it be worth explaining how to do this as the technique of passing data from an app to a web service and perhaps back again is a very useful on to master. As I said before we are looking here at JQuery which is an easy to use framework using JavaScript and for the server side web service we shall use .NET 3.5 or above. I still find myself having to use no higher than 3.5 as many of the web servers out are still 2003 and .NET 4 requires 2008 or above, but for most projects this is not a limitation. Should it become so then rather than upgrading all the servers you could just bring up a server running 2013 with .NET Framework 4.5 on and run all your web services on this, with these being called from your older web servers, that way saving any issue of upgrades breaking things.
So back to our code which hopefully you will find beautifully simple. The main trick with getting this code to work is the correct declaration of data types. The trick is to make sure that the variable that we are going to use to hold the JSON data has to be of type ‘object’ so we define this at the beginning of our code:
myData = new Object();
We now have to fill it with our values, if we use the data we showed earlier then this would be coded like:
myData.FirstName = "Jon";
myData.LastName = "Honeyball";
Now we want to send this albeit very simple data to our web service. On the client-side we create a function that we can call at any time that will send our data to the webservice that we have yet to write.
function CallWebService(myData) {
$.ajax({
type: "POST",
url:"http://www.mywebserver.com/websvc.asmx/MyKillerService",
async: true,
data: "{ 'Info':" + JSON.stringify(myData) + "}",
contentType: "application/json; charset=utf-8",
dataType: "json",
success: function (data) { $("#panelreport").html("Sucess"); },
failure: function (errmsg) {
$("#panelreport").html("Failed");
}
});
};
The line $ajax is the JQuery command to make an asynchronous HTTP request to a URL. We want this to be asynchronous so that our application code will continue execute and our app will remain responsive to the user inputs whilst the web service is doing its stuff, because this is a mobile app we cannot rely on the network being fast or even there! Hence the necessity of an asynchronous call.
The next line of code simply defines the method that will be used to send the data and it will always be “POST” followed by the URL of the web service. This URL deserves some explanation if you are not familiar with calling web services. The first part is fairly normal looking as it is referring to a ASP .NET page on a server this page being called ‘websvc.asmx’ obviously what you call it depends up to you, but the interesting bit is the bit after that which looks like it is referring to a folder which in this context does not make sense. What in fact it is doing is referring to a service call called ‘MyKillerService’ within the Web Service.
You can think of service calls rather like function calls where you can call a piece of code and either pass variables to it or not and the code will execute and may or may not pass variables back to your calling code. After the URL we then set whether the call is going to be asynchronous ( the default ) but if for some reason you wish it to be synchronous then you can set it here. Next we have the important bit and that is defining what data is going to be sent and whilst we have already put our data into our object called ‘myData’ it needs to ‘wrapped up ‘correctly so that our web service can process it.
You will also note that we are using a resupplied JavaScript function called ‘JSON.stringify’ which will convert our object into a correctly formatted JSON string. Sometimes you can get away without this stage but it does make sure that there are no issues with null values and the like. The next two parameters that we have to enter we have already covered and they are to define the ‘contentType’ and the ‘dataType’ to JSON, and finally the last two parameters are calls to two separate functions, one in the case of the web service call being successful and the other in the event of a failure for what ever reason. In this example I am just writing the result to an information panel on the mobile app called ‘panelreport’.
So now we can call this carefully crafted function from within our app, but of course very little will happen without the web service. So we had better build this.
As we are going to be using .NET then open Visual Studio and select .NET framework 3.5 then create a new project under the language you prefer, select ‘web’ and then you should have the choice of building an ASP .NET Web Service Application. Select this and decide on a name for it, then after clicking on the ‘OK’ button you should have your web service built for you, it really is a simple as that to get started. You will need to make some changes before you can read your data in from the app first.
This is what Visual Studio should generate for you:
namespace WebService1
{
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[System.ComponentModel.ToolboxItem(false)]
// To allow this Web Service to be called from script, using ASP.NET AJAX, uncomment the following line.
//[System.Web.Script.Services.ScriptService]
public class Service1 : System.Web.Services.WebService
{
[WebMethod]
public string HelloWorld()
{
This is what you will need to end up with:
namespace PerfectProjects
{
[WebService(Namespace = "http://mydomain.co.uk")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[System.ComponentModel.ToolboxItem(false)]
[System.Web.Script.Services.ScriptService]
public class PcProWebSvc : WebService
{
public class myData
{
public string FirstName { get; set; }
public string LastName { get; set; }
}
[WebMethod]
[ScriptMethod(ResponseFormat = ResponseFormat.Json)]
public string MyKillerService(myData Info)
{
As you can see you are also telling the web service to expect JSON data by setting the ‘ResponseFormat’. We also tell our service what the layout of the JSON data to expect is using the ‘get’ and ‘set’ commands, you can consider this to be a way of defining the schema of the datastore. So using this if we want the ‘FirstName’ we can refer to it with:
Info.FirstName
Which is nice and simple now we have got this far!
Obviously your final code will do a whole lot more that this example shows, as mine does but I hope this shows you how easy it can be. But as with all coding, it rarely goes completely smoothly, a simple missed comma can stop you in your tracks for ages sometimes. It is the ability to debug and to be able to analyse what is going on that can make all the difference to a development environment. When dealing with a solution that is split between two or more completely separate areas on client machines and servers then trying to see where things are going wrong can be tricky to say the least. When doing this type of development one tool I find very useful is the free but curiously named ‘Fiddler’. Now if those of you at the back will stop giggling for a minute I will try to explain what it does and how it can be of enormous help ( more giggles! ).
Without tools like Fiddler certain debugging tasks are impossible
Fiddler is made by Telerik who make a lot of development tools and add in controls, so much so that their web site at http://www.telerik.com is always worth returning to see if there is something that might make your development life that bit easier. What Fiddler does is to monitor all HTTP and HTTPS traffic to and from the machine that it is installed on and whilst just that is helpful, where Fiddler really scores is that it enables you to examine and decode this traffic so you can really get a very clear idea as to what is going on.
In the case of our example we are able to see and check to correct structure of the JSON data being sent to the web service and also to see the content of the response sent back by the web service. This means that you have got a fighting chance of being able to see where things might be going wrong if your code is not behaving correctly. There are plug in’s for various browsers that will do similar things but the great thing I find with Fiddler is that it monitors all the web type traffic irrespective of what client program is generating it so you get a full picture of everything that is going on which can have its uses when debugging.
Now whilst free tools like Intel’s XDK are a great way to get start developing there often comes a time when their limitations start to cost your company money by causing longer developments times and the lack of support for involved issues can cause projects to stall. One that I am currently investigating and have so far been very impressed with is VSNomad (http://vsnomad.com ) by the UK Cambridge-based company, RedGate. From its name you might guess correctly that VSNomad is a plug-in for Visual Studio, it allows easy development of JavaScript and HTML5 from within Visual Studio with support for Android and iOS development as well as debugging tools. A really nice feature is the drag and drop UI designer which makes to construction of screens so much quicker.
Before I continue I must point out a couple of limitations which will have an effect on whether you can consider using this tool. Firstly is needs Visual Studio 2010 or 2013 but will not work with the free Express versions as these don’t allow extensions. VSNomad will also only build for versions of iOS greater than 4.2 or Android greater than 2.2 but this is normally not an issue. Whilst like all other development solutions for iOS you will need an iOS Developer licence which is not expensive, at least you will not need to buy a Mac to develop on.
I really like the UI designer in VSNomad as this enables the developer to put together the user screens quickly so the client can very early on get an idea of how the app might work. One drawback of this is of course is that your client will see these finished looking screens and think that their app is almost done and then pester you for the shipping version! But then it is up to you to train your clients properly!
Literally as I was typing this article, Nomad announced a major change in their software. Whilst the tools and the development environment stay similar, the underlying build service has been changed from their own to Adobe’s PhoneGap (https://build.phonegap.com ).
[graphic: phonegap.jpg caption: VSNomad now uses Adobe’s PhoneGap Build service rather than their own]
This means that if you already have a PhoneGap account then you can use that, if not then there are various plans starting from free but quite limited, or a basic PhoneGap build at $9.99 per month or you can use your Adobe Creative Cloud Membership which starts at $29.99 per month but obviously gives you access to some of Adobe’s tools.
Because of this change to the underlying build service it now means VSNomad download is free, but it does require a valid PhoneGap account to run. I think it still represents a great and coherent way to develop HTML5 mobile apps. The mobile device emulator is not only very good and full of features where you can emulate device features like accelerometer and GPS but also set the network behaviour to different speeds and emulate the dropping out that occurs with mobile networks.
The performance of the emulator is also excellent with the switching between your coding and testing environments being quick and smooth which is not always the same with some offerings. If you are into mobile development you will probably already have a PhoneGap account and so VSNomad becomes a great plug in to Visual Studio which turns it into a powerful mobile development tool not just for Windows Phone but now also for Android and iOS.
VSNomad brings some great tools to Visual Studio
You can cancel your PhoneGap subscription at any time once you have finished your project as your apps will keep working irrespective of whether you have a current valid subscription. The work at my company varies between different platforms and development tools depending on the jobs, this means that the subscription model where you pay monthly whether you use it or not can make it an expensive route unless you can switch the subscription on an off depending on your needs. I’m sure that like me a lot of you may not use a particular development tool for months on end and yet another time you may seem to be using little else.
Because of this I prefer the non-subscription model of application licencing although I can see the benefits for some companies and certainly for the application supplier where revenue is being generated on a regular basis rather than relying on revenue from upgrades and new customers.
Article by: Mark Newton
Published in: Mark Newton