> This is part of a three-post series on working with Parse.com in Unity. For more info please see the other posts in the series:
>
> [Part 1 - Intro and App Structure](https://www.mikecann.blog/programming/working-with-parse-com-in-unity-3d-part-1-intro-and-app-structure/)
>
> [Part 2 - Services, Helpers and Looming](https://www.mikecann.blog/programming/working-with-parse-com-in-unity-part-2-services-helpers-and-looming/)
>
> Part 3 - Tests, Typescript and Common Code



In the last post I covered how to use Parse.com in Unity itself, in this post I want to talk about to to go about writing backend code.

**Note all the code talked about can be found in the [Parse Unity Sample Project on Github.](https://github.com/mikecann/ParseUnitySampleProject)**

## Environment

I briefly talked about App structure in [my first post](https://www.mikecann.blog/?p=5435). I like to use use Visual Studio with Typescript and C# for my Backend as they all play nicely together an produce a hassle free way of coding up the backend.

I like to have the Parse command line app running in develop mode (parse develop "Parse Unity Sample") at the same time so I can see whats happening on the server when I call it, and it allows for very quick iterations:

[![2014-11-11_08-39-16](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-39-16-1024x268.png)](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-39-16.png)

## Typescript

I have talked a lot in the past about my love for Typescript and so I love to use it whenever I can. Parse lets you run Javascript code on the server so I use Typescript that compiles to Javascript. To get it to work I first create a Typescript project that has been setup with CommonJS as the module system:

![2014-11-11_08-40-46](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-40-46.png)

I then make sure all the code is contained withing the /cloud folder (so that the require() works):

[![2014-11-11_08-45-22](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-45-22-1024x324.png)](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-45-22.png)

It works well, particularly when combined with my (not yet finished) Typescript definition for Parse which provides type safety for as much as possible:

![2014-11-11_08-47-02](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-47-02.png)

For example, the code that is run before a User is saved looks like:

```AS3
// Force this TS file to become a module
export var x = 2;

Parse.Cloud.beforeSave("\_User", (request, response) => {

    // Must have a player name
    if (request.object.get("playerName") == null || request.object.get("playerName") == "")
        return response.error("Must supply a player name when creating a new user");

    // Email and username must equal
    if (request.object.get("email") != request.object.get("username"))
        return response.error("Username and email address must be equal");

    // All done
    response.success();

});
```

## Testing

Because there is no way to run Parse cloud code offline, all tests must run on code that runs on the Parse servers. At first this sounded really nasty to me and almost put me off using Parse all together but once I realised that I could just create another App for testing and structure my test in such a way that I could isolate each test, I grew to like it, I actually really enjoy writing these tests now.

I like to use NUnit with the Parse .NET SDK for the testing because it lets us use some more advanced C# features such as async / await which the Unity SDK hasn't got access too, and more importantly it returns the server error messages (unlike Unity) which we can test against.

To get started just create a Test class in your Typescript project (surprisingly Typescript projects work well C# within them in Visual Studio) and start testing:

```csharp
namespace ParseUnitySampleBackend.Tests
{
[TestFixture]
public class SaveUserTests
{
[SetUp]
public async void Init()
{
TestingHelpers.InitParse();
ParseUser.LogOut();
}

        [Test]
        [ExpectedException(ExpectedMessage = "Must supply a player name when creating a new user")]
        public async void RequiresPlayerName()
        {
            var user = new GameUser()
            {
                Username = TestingHelpers.GetRandomUserEmail(),
                Password = "a"
            };
            await user.SignUpAsync();
        }

    ...

```

I included some simple helpers that I like to use for testing which setup Parse before each test.

If you use Visual Studio's Test Explorer with the parse command line you can get really good feedback on what is happening on the server:

[![2014-11-11_08-59-15](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-59-15-1024x386.png)](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-59-15.png)

## Common Code

Because I write my tests in C# and my Unity code is in C# I would like to share my common code between the two projects. Unfortunately simply splitting the project out into a library project then including it as a reference in the testing project doesn't work because Unity requires a different compiler (Unity 3.5 subset on mono) and thus when you try to add that as a reference you get errors related to invalid assemblies:

![2014-11-11_09-03-05](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_09-03-05.png)

The solution I found is to use a little known trick of linking source. To do this select the "Models" folder from the common project and while holding Control and Shift drag it into the Backend project, you should note that the cursor changes to a little shortcut icon and when in the backend project the file icons now have a shortcut icon to indicate they are linked:

![2014-11-11_09-05-26](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_09-05-26.png)

This means that files are linked to the Common project so they are included in compilation and any changes you make to those files in either the Common project or Backend project will be reflected in the other.

This is perfect as it now lets us compile the same files using a different compiler and version of Parse.

## Conclusion

Well thats it for my three part post on how to get started using Parse in Unity. I hope it helps some people, please do leave me a comment or email me: mike.cann@gmail.com if you have any questions.

Happy coding!

> This is part of a three-post series on working with Parse.com in Unity. For more info please see the other posts in the series:
>
> [Part 1 - Intro and App Structure](https://www.mikecann.blog/programming/working-with-parse-com-in-unity-3d-part-1-intro-and-app-structure/)
>
> Part 2 - Services, Helpers and Looming
>
> [Part 3 - Tests, Typescript and Common Code](https://www.mikecann.blog/programming/working-with-parse-com-in-unity-part-3-tests-typescript-and-common-code/)



In the last post I covered the basic app structure, in this post I want to cover some of the specifics of the front end, the Unity part.

**Note all the code talked about can be found in the [Parse Unity Sample Project on Github.](https://github.com/mikecann/ParseUnitySampleProject)**

## Services

I like to split my code up so that all the work that involves dealing with remote services are contained within "Service" classes. The service classes are responsible for taking game data and turning it into a form that the remote service can deal with, then translating the result and passing it back to the game.

In the sample project I have just one service, the UserService, which is responsible for logging a user in or signing them up or logging them out, basically all functionality that that concerns the "GameUser" class.

### Tasks

Lets take a look at the Login method in the UserService class:

```csharp
public Task<GameUser> Login(string email, string password)
{
Debug.Log("Logging in..");

    return ParseUser.LogInAsync(email, password)
    	.OnMainThread()
    	.Then(t => Task.FromResult((GameUser)t.Result));

}
```

We can see that it takes in an email and password then logs in for us and returns a Task<GameUser>.

Parse uses Tasks throughout its Unity SDK as a way of handling asynchronicity. You will probably familiar with Tasks if you have done any work with aync / await in C# 5 or greater.

Unity runs on an old version of C# it doesn't have any concept of Tasks baked in so Parse includes the System.Threading.Tasks namespace. Although Unity does not have any support for async / await you can still use the Tasks API in a [Javascript-like Promise way](https://www.html5rocks.com/en/tutorials/es6/promises/).

Tasks allow us to provide a callback method that will be called when the Task returns, which allows the game to continue on running while we wait for the server to respond. For example, this is how we call Login:

```csharp
private void Login()
{
isLoading = true;
userService.Login(usernameInp.text, passwordInp.text)
.Then(OnLoggedIn, OnLoginError);  
}

private void OnLoginError(Exception e)
{
isLoading = false;
menus.ErrorPopup.Open("Error logging in!");
}

private void OnLoggedIn(GameUser user)
{
isLoading = false;  
 menus.States.SetState("Logged In State");
}
```

The Then function after login is being called on the Task<GameUser> and is the first of my helper libraries that I have included in the sample project which imports my [Unity Parse Helpers](https://github.com/mikecann/Unity-Parse-Helpers) library.

In that library I have included a number of extension methods for Task that allow you to chain functions together for example from the SignupState:

```csharp
private void Signup()
{
isLoading = true;

    // Signup
    userService.Signup(usernameInp.text, passwordInp.text, playernameInp.text)

    	// Then Login
    	.Then(t => userService.Login(usernameInp.text, passwordInp.text))

    	// Then we are done
    	.Then(OnLoggedIn, OnError);

}
```

This makes chaining asynchronous logic together in Unity a breeze and you don't ever have to deal with the headache of using yeild!

## Threading

The first major headache I came across when using Parse in Unity is to do with threading. Note from my earlier example of Login in UserService:

```csharp
public Task<GameUser> Login(string email, string password)
{
Debug.Log("Logging in..");

    return ParseUser.LogInAsync(email, password)
    	.OnMainThread()
    	.Then(t => Task.FromResult((GameUser)t.Result));

}
```

The function "OnMainThread" is a helper extension I wrote to deal with the threading issue. If we were to remove that function then when we try to login Unity would throw an error something like:

![2014-11-11_08-07-43](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-07-43.png)

This is because below the covers Parse is making web calls on a separate thread and when it returns the result is passed back to us without returning to be main thread and pretty much everything in Unity needs to happen on the main thread so when we try to access a variable that lives on the main thread Unity crashes.

There are a few ways around this issue, Parse documents that you can [use coroutines](https://www.parse.com/docs/unity_guide#tasks-coroutines) to deal with this, but I would really rather not have to use coroutines so instead I used another common solution, a "Loomer".

A Loomer basically just takes a function and waits until the game is running on the main thread before executing the function. So behind the scenes my "OnMainThread" extension function is calling the loomer which ensures that any Tasks that follow it will execute on the main thread:

```csharp
public static Task<T> OnMainThread<T>(this Task<T> task)
{
var tcs = new TaskCompletionSource<T>();
var loom = Loom.Instance;

    Action<Task<T>> a = t =>
    {
    	loom.QueueOnMainThread(() =>
    	{
    		if (t.IsFaulted) tcs.SetException(t.Exception);
    		else if (t.IsCanceled) tcs.SetCanceled();
    		else { tcs.SetResult(t.Result); }
    	});
    };

    task.ContinueWith(a);
    return tcs.Task;

}
```

So whenever you call Parse functions in your services just make sure you call "OnMainThread()" and you should be good to go!

On a separate note, I have already [previously mentioned](https://www.mikecann.blog/programming/fixing-unitys-internal-compiler-error/) that if you are going to write extension methods for Tasks you must make sure that you sepparate your action from the ContinueWith() else you will get an internal compiler error in Unity!

## Errors

Unfortunately there is an issue in Unity with Parse that means that we cannot get proper error messages back from the server. For example if a user mistypes their email address when logging in all we get is a HTTP error code like "404 - Not found", this is obviously not particularly helpful. Parse does actually return a better error than which can be seen if you use the Rest or .Net API but whatever reason in Unity that error message gets lost.

This is probably the single biggest drawback with using Parse.com with Unity but it is apparently a [fundemental issue with Unity](https://www.parse.com/questions/unity-sdk-handling-errors). I have [started a thread on the Parse Google Group](https://groups.google.com/forum/#!topic/parse-developers/s4tw8iiSpAA) to see if we can get an update on this but im not holding any hope. I did hear a rumor that the new version of the Unity compiler (shipping in Unity 5+) will finally include improvements to network stack.

Generally you can work around it as you can guess what the issue is if an error occurs and handle it in your business logic. Its still really annoying however particularly when it comes to debugging and testing, hence why I have devoted another post to that very subject..

## To Be Continued...

And thats basically it for dealing with Parse.com in Unity, I strongly reccomend [checking out the source](https://github.com/mikecann/ParseUnitySampleProject) if you need more information on anything I have covered, hopefully it makes more sense.

In the [next part](https://www.mikecann.blog/programming/working-with-parse-com-in-unity-part-3-tests-typescript-and-common-code/) ill talk about how to structure your backend so that you can easily test your cloud code.

Almost exactly [6 months ago I released Post To Tumblr 4](https://www.mikecann.blog/myprojects/post-to-tumbr/post-to-tumblr-v-4/) and today im proud to have pushed the 5th version of my popular Chrome Extension to the [Chrome app store](https://chrome.google.com/webstore/detail/post-to-tumblr/dbpicbbcpanckagpdjflgojlknomoiah?hl=en).



About a week ago Tumblr decided to change its security model which meant that my 34,000 ish users were now stuck. Unfortunately to get PTT to work required an entire rewrite of the way I handled users and posting to tumblr. Under the pressure of from tons of emails from angry users every day I set to work restructuring it all.

Now with version 5 users must authenticate with my backend:

![screenshot_003](https://www.mikecann.blog/wp-content/uploads/2014/08/screenshot_003.png)

Then they can add one or more tumblr accounts to the PTT account:

![screenshot_001](https://www.mikecann.blog/wp-content/uploads/2014/08/screenshot_001.png)

Which then seamlessly integrates into the app:

![screenshot_010](https://www.mikecann.blog/wp-content/uploads/2014/08/screenshot_010.png)

The backend authenticates the tumblr accounts and stores the oauth access keys so that it can make calls to tumblr on the user's behalf in the future. Its a much simpler system than I had previously, and it allows for multiple tumblr accounts which has been requested many times in the past.

The backend is built upon parse.com's cloud service. Its pretty much a hosted node.js environment but I really like it because its really fast and easy to work with and has a very generous free tier :)

[![screenshot_011](https://www.mikecann.blog/wp-content/uploads/2014/08/screenshot_011-1024x572.png)](https://www.mikecann.blog/wp-content/uploads/2014/08/screenshot_011.png)

I wrote the entire backend using Typescript which compiles down to JS which runs on parse, so that means that the entirety, client and server of Post To Tumblr is written in Typescript. A great feeling and utility as it allowed me to share code between the client and server.

I have an almost complete Parse.com type definition file now, surprisingly it isnt actually available on DefinitelyTyped but when I get round to it ill upload it myself.

In addition to the backend changes I totally restructured most of the client to use requireJS for nice modular JS loading. Im much happier with the structure of the client as a result and it feel less like guesswork and global-variable-spaghetti!

I hope my users enjoy it!

As mentioned in my [previous post](https://www.mikecann.blog/games/taming-unity/) I have been working on a multiplayer game built in Unity for a little while now. I ummed and ahhed over the technology choice for the backend for a little while before deciding to go with [Parse.com](https://Parse.com)'s library. The reason being that it looked simple to implement (they have a Unity SDK), they take care of all the backend headaches for me and the pricing model looked fair.



The Parse Unity library is okay, not as fully fleshed as some of the other languages they support but good enough for what I needed apart from one critical point, the lack of type-safety in the queries such as:

```csharp
new ParseQuery<Armor>().WhereLessThanOrEqualTo("cost", 13);
```

This annoyed me so much that I decided to write some extension methods that take advantage of Lambda functions to provide the type-safety. The above now becomes:

```csharp
new ParseQuery<Armor>().WhereLessThanOrEqualTo(a => a.Cost, 13);
```

The library can also handle chains such as

```csharp
new ParseQuery<Player>().Include(p => p.Stats.Heath.Remaining); // becomes "stats.health.remaining"
```

The library also handles interfaces by introducing a new attribute "ParseFieldType".

```csharp[parseclassname("father")]
public class Father : ParseObject, IFather
{
[ParseFieldName("daughter")][parsefieldtype(typeof(child))]
public IChild Daughter { get; set; }
}

new ParseQuery<Father>().Include(f => f.Daughter.Name); // becomes "daughter.name" and works because ParseFieldType redirects the chain to Child rather than IChild
```

It can even handle lists

```csharp[parseclassname("father")]
public class Father : ParseObject, IFather
{
[ParseFieldName("children")][parsefieldtype(typeof(child))]
public List<IChild> Children { get; set; }
}

new ParseQuery<Father>().Include(f => f.Children[0].Name); // becomes "children.name"
```

To get started go grab the .dll from my Github project for the library: [https://github.com/mikecann/Unity-Parse-Helpers](https://github.com/mikecann/Unity-Parse-Helpers)