When Written: April 2014
Browser based emulators will only take you so far in your testing.
When writing a mobile App in HTML5 it is usual to use a desktop PC with a development tool like Intel’s XDK which includes ‘Ripple’ , this being a mobile device emulator software so that you can visualise your App. However whilst this will get you so far there is no substitute for testing on real devices, only by doing this can you see what the true final user experience will be. The obvious things like: how easy is it for the user to use the App by touch? For the App experience to be pleasant you need to minimise the amount of text they have to type as this is usually much slower and more error prone than using a traditional keyboard, and also you need to space the Apps buttons in such a way so that the wrong options are not selected by mistake. No amount of testing on an emulator will highlight such issues. For example, on my current App, one modification that was needed was to move the ‘Clear all Data’ button to a different screen after I mistakenly hit it whilst handling the phone. I also added a ‘Are you Sure’ prompt!
It is also during this testing on the actual devices that incompatibilities will arise. Whilst the emulators are very useful they don’t do much more than provide a way of visualising different display formats. What they will not emulate is the different lack of support of different features. I have put this on my wish list for Christmas – or before would be nice. Can someone out there write an emulator that also reflects the unsupported HTML5 features of the device that it is trying to emulate? I have found a way to achieve this but it is a little tedious although at least it does mean that you can emulate most device dependant HTML5 implementation limitations. Mobile devices all use a browser engine to do their rendering of HTML5 and this engine is either the same as or very similar to its desktop big brother, so the trick is to choose a web based emulator like http://www.mobilephoneemulator.com and then run it in different browsers each of which reflect their corresponding mobile devices. For example Safari for iOS, Chrome for Android and IE for Windows Phone. This will get you somewhere although I find a quick look at http://caniuse.com also very helpful, since this site shows what is supported in which version of what browser in great detail and really helps when developing in a yet-to-be-finalised language like HTML5.
http://canIuse.com can save a lot of grief wondering why your HTML5 is not working.
More obvious exclusions are the lack of any type of local database support for Windows Phones and the annoying lack of support for ‘datalist’ object in iOS. This latter limitation means that creating an autocomplete type text object is tricky with iOS; it can be done but it does rather go against the mantra of ‘write once, run anywhere’ that web technologies promise to offer us one day. Autocomplete text fields are a great way to minimise the amount of keying a user has to do on a mobile App, which, as I pointed out earlier is slower and more error prone than the more traditional desktop solution. The way these fields work you are probably familiar with but may not be aware of their name; as the user keys in the first few letters a drop down appears with the matching words from a predefined list. However, this is not like a traditional drop down list where the user’s input is limited to items on a list, with a ‘datalist’ the user can either select from the list or enter new text in a way that is similar to the old combo-box that we had way back, ever since the early days of Windows development with VB3. Some days the view of the progress we have made in software development does seem obscure. Thankfully jQueryUI comes to our rescue and this can be made to work with development tools like XDK.
Just select the bits you need and build your own jQueryUI framework
Because we are writing for mobile devices with limited storage it is a good idea to minimise the size and number of frameworks that you use, particularly since this will also speed up the initial loading time of your app, no bad thing. With jQuery you often don’t need all the controls that it offers so I suggest that initially you use the full version and then when you are happy your code is working as it should, then go back to the jQueryUI site (https://jqueryui.com/download ) and create a customised version of the framework file for your App. I do things this way because on occasions one control needs other support code and by starting coding with the full version it is easy to see what breaks after you have created your custom jQueryUI file. Once jQueryUI has been added to your project you can use the ‘autocomplete’ control to replace the HTML5 datalist. This autocomplete control will work on all platforms and so the problem with the current lack of support in iOS and Safari for the HTML5 datalist control is solved.
Because the mobile device emulators out there do not currently show such limitations of the real hardware devices that they are supposed to represent, you have no alternative but to test and debug on the real hardware. In the early days this could be tricky but now all the major mobile platforms have mechanisms in place that allow you to install on selected devices without having to submit them for approval and distribution via the relevant store.
The easiest one to do this with has always been Android because all you have to do is send someone an email with your code attached or a link to it and as long as the default security setting on their phone has been changed by the user to allow the install of Apps from places other than the Store at Google Play then your App will install and run. Various development tools, including now the excellent Intel XDK, will even allow you to connect your PC to the phone via a USB lead and single step and debug as you use your App on the phone, which is very useful for finding some of the more obscure reasons why your code is misbehaving.
With Windows Phone development it is a little trickier. First you need to register as a developer; this will cost you about £13.80 a year for an individual. You then log into your Windows Phone Developer hub and follow the process of submitting your App. As you will be testing you can submit the App as a ‘Beta’ product which will mean that the App will not appear in the Windows Store, but during the submission process you can add up to 100 testing users by simply adding their Microsoft Live IDs. These people can then be sent an emailed link that will enable them to see the App as it would look in the store with your description and screen shots and they can then download and install it from there. Talking of screen shots, one of more tedious tasks with all this multiplatform development is the creation of icons and splash screens to the correct dimensions. The worst platform for this is iOS with no less than twelve images required before you can submit, with some of these separate image dimensions having only four pixels difference!
The task of submitting of an iOS App is perhaps the most complicated of all but there are some very good walk-throughs on the Apple web site, and as long as you take it steady and don’t get confused over some of the terminology then it all works well. Again like Windows, you will need a developer account and this is £60 per year for iOS. Whilst you are at the testing stage then you can bypass a lot of the approval stages of submitting to the iTunes Store by building and submitting your App as an ‘Ad Hoc’ App as opposed to ‘Production’. If the App is built as ‘Ad Hoc’ you can only install it on iOS devices for which you have previously registered their Unique Device Identifier UDID as a device with your developer account and then used this to create a new ‘Provisioning Profile’. You may ask what the heck is this provisioning profile? It is a small file that is built by the Apple developer portal by you after you give it all the information it needs and it is used by the system to establish the relationship between the ‘AppID’ the ‘Distribution Certificate’ and the ‘Push Certificate’. See, I did warn you about the terminologies!
So now you can get your App trialled on Android, Windows and iOS devices and deal with any issues that might arise before you release it into the various stores for public distribution, and hopefully make some money from it.
As we have mentioned the grubby subject of money, I wrote in the last article about in-App purchases. This is the mechanism where the developer can offer ‘power ups’ and other enhancements, usually in games, to the user in exchange for a payment. These have come in for some criticism as children have managed to run up large bills on their parent’s credit cards which are registered to the store. Normally the child would need to know the store password before anything can be bought, but both Apple and Google stores would leave a period of time when the password would not be requested again, a bit like a session timeout. This period would mean that once the parent has entered their password for an initial purchase, the children were able subsequently to purchase more items without the knowledge of the password or their parents! That is until the credit card statement turned up! Apple have had to refund users to the tune of several millions and modify their store whilst Google are currently being taken to court in the States over this, (http://www.bbc.co.uk/news/technology-26528512 ) no doubt the outcome will be similar.
The particular App that I am working on talks to a remote web service for some of its functionality. Now debugging this scenario is bad enough when the client App and the web service are both running on your local development box but things get fun when you roll out the web service to a live server and things break. As web services by their very nature have no visible front end which might display helpful error messages you are working blind a lot of the time. This is where the Remote Debugging capabilities of Visual Studio really come into its own. With this enabled you can literally single step through your application as it runs on the remote server just as if it was running locally. It is very useful and clever stuff. To use it you have to install the Remote Connection Manager on the server and run it, you also need a ‘proper’ version of Visual Studio as the free ‘Express’ version will not perform this particular trick. In Visual Studio you open your project and then select ‘Attach to Process’, browse to the server on your network and then you can view all the processes running on it. You then need to select the correct one, in this case it is called ‘w3svc’ and that is all there is to it. Obviously you may have issues with firewalls or VPNs but I will leave that to you to sort out, it worked great on our network!
With Remote Debugging enabled I was able to figure out one little bug that was stopping the remote server from behaving as the local one had, so the next step was to test the mobile App on a mobile device rather than an emulator and see if it would talk to the remote server. Surprise, surprise it didn’t! It just sat there reporting to me that the connection had failed! Remote Debugging was not helping me now as the request from the mobile device didn’t seem to get that far, the emulator version worked fine still. So with very little to go on I resorted to looking at the web server’s logs. These don’t tell you much but at least I could see that the calls to the web service were at least getting through. What was interesting was that while the calls from the tests via the emulator were appearing in the logs as the expected ‘POST’ call, the calls from the mobile phone were coming in as ‘OPTIONS’ calls. Now what these are is the device requesting information from the server about the type of HTTP methods that the server supports before it sends any data. The server needs to reply that it supports POST requests; however, in this case it was not responding with anything and so the transaction ended at that. What was required was some code in the Global.asax.cs file of the web service so that the server would return the correct response, this code would look something like:
protected void Application_BeginRequest(object sender, EventArgs e)
{
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", "*");
if (HttpContext.Current.Request.HttpMethod == "OPTIONS")
{
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Methods", "GET, POST");
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Headers", "Content-Type, Accept");
HttpContext.Current.Response.AddHeader("Access-Control-Max-Age", "1728000");
HttpContext.Current.Response.End();
}
}
This will return the two methods of ‘POST and ‘GET’ when asked by a client App or browser and this was reflected in the web server’s logs. When this code was added to the server I was rewarded by everything working live as it did when run locally on the development box.
The next step was to build and distribute the app to a small select bunch of people for testing and feedback. I prefer initial testing to be to a small number of testers so that I am not inundated with a large number of reports of any obvious faults and the rolling out new builds is not too onerous, so far this testing is going well, we may be going live by the next article!
Article by: Mark Newton
Published in: Mark Newton