Saturday 23 June 2012

Microsoft.Sharepoint.Sandbox.dll

Just a quick post about an error I recently came across, namely, this one:

"Could not load file or assembly 'Microsoft.Sharepoint.Sandbox, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. An attempt was made to load a program with an incorrect format."

So, how did I come across this?

I wanted to do some development on a SharePoint 2010 project but, I didn't want to do it on a server that had SharePoint installed (the code path used on a non-SharePoint server would mean that the SharePoint features wouldn't have been used).

To achieve this, I needed to copied across the Microsoft.Sharepoint.dll over to the non-SharePoint server and then have the project reference this DLL so that everything compiles correctly. I should add here that the server I copied the DLL from was a 64-bit server and the non-SharePoint server is a 32-bit server.

Upon compilation, everything is fine and dandy, everything compiles and there's no problems. However, at runtime, I get the above error. But why?

Well, there's two important parts to this error message...

Could not load file or assembly 'Microsoft.Sharepoint.Sandbox, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies.

This tells us what file is causing the problem. Microsoft.SharePoint.Sandbox? We didn't include that! As it turns out, when you reference the Microsoft.Sharepoint.dll, upon building the project, this is automatically put in to your web applications bin directory.

The second part tells us why it's causing us a problem...

An attempt was made to load a program with an incorrect format.

This occurs when you try to run a 64-bit DLL on a 32-bit process. 

So, we now know what's causing the problem and why. How do we solve this problem? Simple. We delete it! On a non-Sharepoint server, the Microsoft.Sharepoint.Sandbox.dll isn't used so it can be removed from the bin directory of your web application. The best way to do this is to add a post-build event to your project which deletes the DLL so you don't have to do anything. Obviously however, if this is used on a SharePoint server you will need that DLL so just be aware of that.

And that's it, another odd problem solved.

Tuesday 12 June 2012

HTML5 - Geolocation

After my last blog post, I thought I'd take a look and see what this geolocation melarky is all about.

As it goes the API is extremely simple and easy to use which makes blogging about it pretty straightforward.

The aim of the API is to get the longitude and latitude of the device that is accessing your website. This information can then be fed into another application to make it more user friendly. For example, a common use for this information is to put it into Google Maps to show exactly where your user is.

So, how do we use this API?

First off we need to make sure that the browser supports geolocation. To do that, we simply need to check that the navigator.geolocation object exists. That can be achieved with the following:


if(navigator.geolocation){
   // Do Geolocation Stuff
}


All straightforward so far. So now it's time to grab the longitude and lattitude. There are two methods available within the API to accomplish this: getCurrentPosition and watchPosition. getCurrentPosition runs once and gives you the users location. watchPosition will continually run, allowing you to track the user as they move. Both run asynchronously. There is one final method included in the API, clearWatch. This method allows you to stop tracking the users position after you've called watchPosition.

Now let's have a look at these methods in a bit more detail.

getCurrentPosition

The function definition:

getCurrentPosition(successCallback, errorCallback, options)


The success and error callback parameters explain themselves. The options parameter allows the developer to specify the timeout value, the maximum age of a position call (basically, how long it lives in a cache) and how accurate the position call will be.

To determine how accurate the position call will be you need to understand how geolocation works. There are a variety of ways in which a users location can be worked out, as listed below.

  • WiFi - Accurate to 20 metres. The MAC address of any and all WiFi access points detected by the users device is sent across the web and mapped against a database of wifi access points and locations. From what I can find out, different browsers use different databases. For example, Chrome and Firefox use a database created by Google. Safari however uses Skyhook's Wireless service.
  • IP - Accuracy varies greatly and can give false information. In this instance, an IP address, or a range of IP addresses are mapped to locations within a database. Unfortunately, due to the nature of IP, addresses and locations change and occasionally IP addresses can get mapped to a completely wrong location.
  • GPS - Accurate to 10 metres. This method only works outside so is only ever an option with a mobile device. GPS is quite an advanced system, if you're interested in the gritty details of how it works, have a read of this. This method unfortunately can take a bit of time and can use more power which may be important if you're target device is a mobile phone/tablet. It is however, the most accurate out of all of the geolocation methods.
  • GSM/CDMA IDs - Accurate to 1km. This will take unique ID of your mobile device and will use it against the local mobile phone towers to triangulate your position. Accuracy will significantly improve where there are more towers, so, if you're in an urban area, accuracy will be far greater than if you're in a rural area.
Ok, so, here's an example of using the getCurrentPosition method:


var success = function(position){ 
    alert("Latitude: " + position.coords.latitude + ", Longitude: " + position.coords.longitude); 
};

var error = function(error){
    alert("Error. Cannot find your position");
};

navigator.geolocation.getCurrentPosition(success, error, { enableHighAccuracy: true });


The enableHighAccuracy option essentially means that the method of determining the users position that provides the highest accuracy will be used. This only really matters when your user is using a mobile device with GPS. GPS uses more battery power than the other methods and can take a couple of minutes to return so may be something you want to avoid where possible.

watchPosition
The function definition:

watchPosition(successCallback, errorCallback, options)


Look familiar? It should do. It's exactly the same as the getCurrentPosition method, with one small difference. This method will return a watch ID. The watch id is then passed into the clearWatch method to stop tracking the users position, but more on that in a bit.

So, like I said, the purpose of this method is to track the users position. When they move, assuming that no errors are thrown, your successCallback will be called. This callback takes the exact same parameters as the getCurrentPosition successCallback function did so, you can grab the new longitude and latitude co-ordinates and use them for whatever you need.

Just as a very quick example of the use of this:


var success = function(position){ 
    alert("Latitude: " + position.coords.latitude + ", Longitude: " + position.coords.longitude); 
};

var error = function(error){
    alert("Error. Cannot find your position");
};

watchId = navigator.geolocation.watchPosition(success, error, { enableHighAccuracy: true });


clearWatch
The function definition:

clearWatch(watchId)


Pretty simple eh? This effectively cancels your watchPosition call made earlier. So, as an example, you could have something like this:


var success = function(position){ 
    alert("Latitude: " + position.coords.latitude + ", Longitude: " + position.coords.longitude); 
};

var error = function(error){
    alert("Error. Cannot find your position");
};

watchId = navigator.geolocation.watchPosition(success, error, { enableHighAccuracy: true });


function stopTracking(){
  if(watchId != null){
    navigator.geolocation.stopWatch(watchId);
  }
}


You can then call the stopTracking function from wherever you want.

And that's about it for the API. If I'm honest, its simplicity surprised me. I personally think that location based services will really take off in the next year (if they haven't already) as HTML5 becomes the standard on more and more browsers. Location information opens up a world of possibilities, from helping you to find your friends in a crowd to providing more relevant information to you when you're performing web searches. Now that the technology is there, it's up to us developers to use it to give our users the best possible experience.

Before I sign off though, I should mention one thing regarding location services and it involves one of the 'keywords' being spoken about all the time at the moment.... privacy.


Google Chrome prompting the user.
Obviously, tracking a user's current position does come with a few privacy concerns. Web browsers have done what they can to address this by ensuring that when you request a users position, either via the getCurrentPosition or the watchPosition method, that the user is notified and they are then given the option of denying you access to that data. (If this occurs, your error callback will fire rather than your success callback.) However, this in my eyes isn't enough. I think websites should take a bit of responsibility too!

Ok, here comes a bit of a rant so feel free to stop reading here but a pet peeve of mine is sites that do request my location information and then use it for something that isn't stated on the tin. Take for example Facebook: Now and again I may want to publish where I am in the world so my friends can see for whatever reason. So, when I go to publish my location the website prompts me that Facebook wants to access my location data. Not a problem, how else are they going to publish my current location? What I do not then expect is for my location to be posted on everything afterwards. Especially when I've gone to the pub instead of heading home! Facebook doesn't just do it after you've published your location - it updates your location whenever you make a comment or a status update and as far as I'm aware, there's no easy way stopping that from occurring.

Now I'm sure Facebook has some setting somewhere that lets me turn it off for posts but I shouldn't have to. I agreed to let Facebook access my data to do a specific task that could not be accomplished without that data. I did not agree to let Facebook plaster it over every post/comment I subsequently make. I'm sure Facebook isn't the only culprit here and I understand that if you throw up a configuration option for each and every action then it's going to become pretty tedious. But, if I had been notified of their intentions at the start then I may not be ranting.

Ok, rant over. In conclusion to that little out-burst... just make sure your users know why you need their location data and exactly what you're doing with it. If not for your users benefit, then do it for your own as I'm sure someone will be ranting about your website if you don't.

Monday 4 June 2012

The Mobile Web - To App or Not To App, That Is The Question


Accessing the web on the move is becoming something all of us are doing more and more of each and every day. With smartphones and tablets becoming more advanced on an almost daily basis, the question of "should I make my website mobile enabled?" has been replaced with "how do I make my website mobile enabled?" and with technology in it's current state, that question can be boiled down to the following:

"App or Website?"

By this I mean, do you write a native app which you can download from an app store and run on your mobile device or, do you improve your website so that it can be accessed by a mobile device easily?
In my humble opinion, and bare in mind I am primarily a web application developer, that the website option is the way to go. Most things can be achieved by a website and it reaches a far wider audience than an app ever would do.

Why do I say this? Well, I'm going to go through what I consider to be the important factors when weighing up the above question, hopefully after that all will become clear.

Audience Reach

This is the first major issue and one that should hold some serious weight. If you develop an app, your app will only work on a specific platform. So, if you build an app for the iOS then only apple devices will be able to use it. What if your user is using an Andriod, Blackberry, Samsung or some other smartphone? Well tough. You've limited the amount of people your product/service can reach straight away. The workaround for this is to build the app separately for each individual platform. That in it self brings problems. If you're a software house, it's unlikely that you're going to have developers who know how to program for iOs, Android, Windows Phone 7, etc. That means you're going to have to train them up, that takes time and money. If you're not a software house, or you don't want to build it yourself, you can always outsource the work, but that's not cheap. Put simply, unless you're a company with a large amount of resources or, you're somebody with an immense amount of time on your hands, that's not really an option.

Let's compare that to making your website platform independant. Yes, over the years, making a website work on many different browsers has been a complete headache but things are changing. Browsers are learning! Yes, the odd tweak is needed here and there but in the most part, if you program to W3C standards then you shouldn't have many problems now days, especially on the major mobile platforms, which in my eyes, doesn't include Microsoft Internet Explorer. So you've made your website, you've programmed to W3C standards, what next? Well nothing. That's it. All browsers on all phones can access your mobile website. That's considerably cheaper and easier in just about every way you can think of.

Look and Feel

When discussing this topic with fellow developers, people inevitably say that a website won't give the same look and feel as a native app. "You can't get rid of the address bar!" I hear them say. Well, that's not strictly true. You can, but both you, the developer and your user need to know what to do. In iOS (I own an iPhone and have access to an iPad so know this platform reasonably well) you can add meta tags that, when run from the home screen, will get rid of the address bar and will let you style the status bar too. For example, the tag:


<meta name="apple-mobile-web-app-capable" content="yes" />


will ensure that the web application loads in full screen, with no address bar, when loaded from the home screen. Unfortunately though, there is a bit of a flaw in this. As I said, this only occurs when loaded from the home screen. That means your user must first add the website to their home screen. As far as I'm aware, there's no way of providing the user with an easy way of doing this, they must be familar with the iOS user interface. I'm sure this is equally true with Android phones. This does pose a bit of a problem, maybe it's not a problem for your particular product/service but it is something to bear in mind.

A Website Can't Be Viewed Offline!
"A website can't be viewed offline, what if my user is on a plane or in tunnel?". I hear that argument a lot when talking about this and it just doesn't hold up. HTML5 has introduced Offline Web Applications which I've blogged about before. They allow a website to be viewed with no internet connection available. Yes, it assumes you've visited the site previously but you can easily argue the same with an app, after all you need to be online in the first place to download the app. And yes, I agree, offline web applications can be a pain to create, especially if your content is dynamic but they're by no means impossible. I imagine it'd be no more harder than creating an app from scratch. Again though, it depends on your needs. If you definiately require offline access then it can be achieved by both an app and by an offline web application. Chances are though, you don't.

Access To Phone Devices
Unfortunately, building a website isn't the holy grail. After all, if it was there wouldn't be a need for apps. This is one area where apps have the upper hand. They have access to your phones devices, for example, your phone has a microphone. Your app can use that. Your phone has a camera, your app can make use of that. Now in theory, if you're just deciding whether to make your website an app or to make it mobile compatible, then this may not be a problem. Your original website wouldn't have had access to these devices either but maybe by using these controls, you can make a certain process within your website easier. It's something to consider.

I should say on this note that phone developers are beginning to realise this and seem to be building API's that help bridge the gap for websites. In the iOS 4.1 update, Apple sneaked in an undocumented update to it's Safari browser... two new JavaScript events were created, ondevicemotion and ondeviceorientation (see http://mobile.dzone.com/articles/how-use-gyroscope-your-iphone for more details). These provide website developers access to the accelerometer data and the gyroscope data of an iPhone/iPad which they can then use for whatever they want. 

The App Store

Just about all mobile devices now have some form of "App Store". A central place that a user can go to search and download your app. Whether the use of an app store is a good or bad thing completely depends on your situation. The app store does give users a central place to be able to search for your specific app. It may also open up another revenue stream for you; you can charge people to download your app! On the flip side of the coin, it's an extra expense, for example, you need to pay Apple to be able to put your app in the app store. On top of this, all apps are accredited by Apple so you need to make sure your app ticks all of their boxes. This may or may not be extra work for you and your development team. Plus, accrediation takes time. You've got to wait for someone at Apple to do their job before your app gets out in to the world. Maybe this extra time delay isn't a problem, maybe it is. Either way, It's certainly something that you don't have to worry about when building a web application.

The other thing to consider in this area is, how do you push out updates? If your application is sold to many different clients, it's quite possible that each client will buy and use a particular version of your product. What happens when you need to release an update? Maybe some clients have contracts so that they can download the latest updates, maybe some don't. There's no way to distinguish. In it's current form, the app store (at least the Apple version) doesn't support this kind of business model, either all users have the ability to download the latest update, or none of them do. This may very well lead to clients receving access to versions of your product that firstly they haven't paid for and secondly, and arguably more importantly, they may not want. As always, there are ways around this, you could for example release a "new" app for each client. You'd then have to come up with a way of managing that. If you then have that across all major mobile devices (I'm thinking Android, iOS, Blackberry, Windows), you've now got to have some form of version control for all of those, for all your clients. That's going to get very messy, very quickly. Maybe you could build your app so that it's backwards compatible and then only allow new content to be accessed by the clients that have that in their contract? There are ways around it but the chances are, it's not how you do things currently and will require a bit of a re-think in your release procedures.

So, what do you do?

In my very humble opinion, if your application is a web application, first and foremost, make sure it works on mobile devices before even thinking about building a native app. The amount of effort and resources that are required to make sure that your app has the same audience reach as a web application just isn't worth the bother. A native app, in my eyes, should be considered an extra bonus and nothing more.

As an example, let's look at the National Rail website as I think it's a particularily good example. Using their website, I can find out the times of trains across the whole of England. If I access http://www.nationalrail.co.uk on my desktop then I get the full blown website, I can look up times, book tickets, look up services updates, the lot. If I access the site on my iPhone or iPad (these are the only devices I have access to at the moment), then a specific mobile device website is loaded. The website I see there is a bit more stripped down but, I can perform all the same functions with minimal fuss. 

Once National Rail had that in place, they went one step further and built an app. If you load the app on the iPhone, like the mobile specific website, it too allows you to look up train times. The difference here is that they've taken advantage of device specific features. For example, the iPhone has the ability to track your position via GPS. National Rail have then used that information within their app to give you a listing of the nearest stations to your current location, something not really possible with current web technology (That's not strictly true, you could use the new HTML5 Geolocation API but I have no idea how accurate that actually is... maybe a subject for a different blog post).

Ok, so what if your application isn't a web application at all, maybe it's a desktop application that you're thinking of porting to a mobile device. Well, there is no generic solution for this. It'll depend on your product and the service you provide. As a general rule of thumb, I think it's always better to port your application to the web before creating an app but then again I am a web developer so my opinion may be a little biased.

I hope the above has helped but this is a subject that has quite a few different schools of thought so I'm interested in hearing what you think so feel free to comment!