Windows Azure Mobile Services in Portable Class Library

In my current project, a multiplayer game for mobile devices I only using Windows Azure Mobile Services as backend. The game will be available for multiple platforms and I will use Xamarin for iOS and android.

When using Xamarin I can reuse a lot of code if I using PCL (Portal Class Library) that i shipped with Visual Studio. When creating a new PCL-project you can choose which taget platforms the project will build for, in my case Windows Phone, Windows Store, Xamarin iOS and Xamarin Android.

In order to reuse so much code as possible I want to have the communication with my backend in PCL. When using Windows Azure Mobile Services I can have all communication there except for the code for authentication. But then I put an interface i PCL and each platform will have a specific implementation of the interface.

But where to find the Mobile Services assemblies for PCL? I installed Mobile Services via NUGET to my Windows Phone project (Windows Phone is my first platform). But Mobile Services was not just installed to my Windows Phone project, I also got the assemblies for PCL (and other platforms) i my packages folder. It enabled me to add the assemblies manually to the PCL-project.

Size limit on app download when using 3G

iOS and Windows Phone has size limit on how big apps you can downloaded when you’re not connected to a Wi-Fi-network. Windows Phone has a limit on 20 Mb and iOS has 50 Mb.  Android has not that type of limit, but an APK on Google Play is limited to 50 Mb, but you can add extensions that are much bigger than so.

When are you downloading apps to your phone? It’s often when you sitting on the bus or waiting for something. Do you have a Wi-Fi-connection then? Often not.

I think it could be a good thing to think about when developing apps. If a user found your app and cannot download it, the chance that they choose to download another app instead is big. If you have big content in you app, you maybe can have it on a server and download it when the user starting the app.

Probably the user don’t need that content from start and you have some time to download it, if they navigate to a part that need the content, show a loading dialog that tells the user that content is under download.

Developing apps with mono

WordRoom started as a Windows Phone project, the third client we started to develop and the first one we released was for Windows 8. We developed the windows 8 relative fast because we could reuse a lot of the code from the Windows Phone project in that we used portal library for the core logic.

As I mentioned above, Windows 8 was the third client we started to develop. The second was for android devices. I started to build the android client with java and eclipse. Step one was to translate all core logic from C# to java, a lot of work but I developed an almost finished client for WordRoom. But in the end of 2012 when we should start to develop the client for iOS we decided to use and mono touch and mono for android from Xamarin so that we could use the same assemblies for the core logic that we did when developing for the Windows platforms. We also share data contract assemblies between the backend and the clients. So now we running the same code in at backend in Windows Azure, on Windows 8, Windows Phone, Android and iOS.

The decision to start using mono is one of the best decision we have taken. We saving a lot of time and we get an app that is much easier to maintain.

Next app I will develop I will think about that that the code will be shared between different platforms earlier in the process. Because if you have a structure in your project with GUI and business/game logic split up and using interfaces for platform specific features, for example local storage you can reuse much more code and save a lot of time.