Highcard Game: First App in the Marketplace

At QFrame, we are very proud to announce that as of today, we've got our first app up and running in the Windows Phone Marketplace.

It is a very simple game, based on the drawing of cards, which can be played from 2 up to 4 players. After a draw, the highest card wins. It is excellent to use if you'd need to decide who needs to do the dishes, who should go for bread in the morning or, who should pay the next round of drinks, ...

This little experiment thought us a lot about the basics of Windows Phone development and about the approval process. We were revoked at first for the marketplace, since we only took a dark background into account. This was an easily fixed issue, though.

So, if you're interested, go and download it to your phone, and let us know what you think about it.

Mobile Cross Platform MV Solution

After the initial hours lost on installing everything, I have been playing some more with MonoDroid lately, trying to port a basic Windows Phone 7 application to an Android device. Part of this was quite easy (thanks to MonoDroid that is) and part of it took some refactoring of the existing code. All in all, the experience was very insightful.

The existing WP7 application uses the MVVM pattern, which makes it very easy to get a separation of concerns between your model, view and viewmodel (I sometimes like to rant about this separation of concerns not being as clear as it should be in some applications). It also works very well in combination with the databinding that is provided in Silverlight. If you want to know more about the MVVM pattern, check out the article by Josh Smith in MSDN Magazine.

While MVVM works very well with Silverlight, WPF and Windows Phone apps, I did have some issues using this pattern in combination with MonoDroid. Let me walk you though this.

I started off thinking which parts of the existing code I would be able to reuse for the Android application. Reusing the views was out of the question, since Android views are written differently than Windows Phone views. But my models should be easily reusable, as should be my viewmodels.

The existing application already had the model and viewmodel classes in a separate Windows Phone class library. The views were contained in a Windows Phone 7 application (MemoChallenge.Wp7). So, reusing the models and viewmodels, would just be a matter of using this same class library for my Android application. Now, you can't just reference a Windows Phone 7 class library in an Android project. For this to work you need a second class library, specific for the Android/Monodroid project and some clever project linking.

For the Android application I actually created two more projects, one for the Android  views (MemoChallenge.droid), and one class library (MemoChallenge.droidlogic), which would be a linked project to the Windows Phone 7 class library (MemoChallenge.logic). You can use the Project Linker tool for this. This will link the two class library projects and will make sure that any change you do in one project, gets reflected in the other project.

After doing this, I immediately got my first compile errors, and they were abundant. Why did I get all these errors?

The thing is, viewmodel classes use commands all over the place. Or actually, they use the ICommand interface. This interface turned out to be quite a big problem. It is contained in a Windows specific dll, so the Android SDK does not know what to do with it.

To solve this problem, I could have rewritten the ICommand interface for Android. This would also mean I would have to add conditional compilation attributes all over the viewmodel code. I was not willing to do this, since it would be a lot of work. And I am not that fond of conditional compilation attributes.

Instead I used a combination of the MVVM and MVP pattern. I did not want to throw away the existing viewmodels, since they were working just fine. I did move them though, to the views project (MemoChallenge.Wp7), so they were no longer present in the shared class library. As a replacement for the Android application (and the WP7 application, remember these projects are linked), I added presenter classes. My viewmodels became very slim, I practically removed all of their logic and moved it all to the corresponding presenters. Now only thing my viewmodels had to do is forward the call to a presenter and we're done.

   public class GameViewModel : ViewModelBase, IGameViewModel 
   { 
     private ICommand _startCommand; 
     private ICommand _sameCommand; 
     private ICommand _notSameCommand; 
     private GamePresenter _presenter; 
     private IGameData _gameData; 

     public GameViewModel() 
     { 
       _presenter = new GamePresenter(this); 
     } 

     public ICommand StartCommand 
     { 
       get 
       { 
         if (_startCommand == null) 
           _startCommand = new RelayCommand(() => _presenter.Start(), 
             () => _presenter.CanStart()); 
         return _startCommand; 
       } 
     } 

     //rest of the code omitted 
 }  

I hope this gives you an easy way to get MVVM to work on Android/MonoDroid.

Cross Platform Mobile Development

At this years NDC conference, I followed a couple of talks about mobile development. It was announced there that the people behind MonoTouch and MonoDroid were moving to a new company named Xamarin. Well, as of yesterday, they have actually made the move and all sources for doing cross platform development can be found at their site.

They are actually providing a really cool way of doing cross platform development. You don't need to learn a whole lot of Objective-C or Java to develop applications for iPhone or Android, but you can develop in C# .Net, the language you use for doing Windows Phone 7 development. The only thing you still need to provide, that is specific for the iPhone and Android devices, is the user interface specific for each device. If you develop your applications wisely, though, - that is, using one of the MV* patterns - this is a walk in the park.

For iPhone development you will need a MAC, because the iPhone SDK only works on iOS. You can then install Mono and MonoDevelop (instead of Visual Studio) for OSX to start developing. For people like me, who are used to tools like ReSharper, you will, however, again need to learn how to type.

For Android development, the Java SDK is needed, and again MonoDevelop or Visual Studio 2010. With some handy project linking in Visual Studio, you can easily provide a shared code base for all three platforms. On this, watch the NDC talk, by Jonas Follesoe, about cross platform development!

The good news also is, that Xamarin offers both MonoTouch and MonoDroid as a free trial version that doesn't expire. The only drawback to the trial is that you can't deploy to actual iPhone or Android devices, only to their respective emulators. But this should be enough to get you started. Once you want to try out specific features the emulators don't offer (like gps, camera, ...) you will need to move to a paid license (or once you want to deploy to the marketplace, that is).

You will however need a little bit of extra effort if your initial WP7 projects are hosted on TFS. MonoDevelop for now does not offer a build in way for synchronising projects with TFS. You can use Microsoft Visual Studio Team Explorer Everywhere 2010, which offers a command line utility for connecting to TFS. Also SvnBridge gives you an SVN kinda way for connecting to TFS. And also, you could move your code base to SVN or GitHub (I love that place, not only for its name) alltogether.

This weekend there is also the MonoSpace conference in Boston going on, specifically for Mono development. They have a couple of sessions on mobile development as well. I hope they will put videos on-line of their talks.

Since I don't own a MAC (yet), I will try out the MonoDroid SDK in the next couple of weeks. Be sure to check back in to watch the progress (and the walls I will probably hit).

Got me a Windows Phone 7 (and happy with it)

Since we, at QFrame, are developing for Windows Phone 7, it was only a matter of time until some colleagues and I got a couple of those devices ourselves. I went for the LG E900 Optimus 7 black. Ordered it at pdashop and just two days later my new phone got delivered. And of course, ever since, I have been playing with it.

What I like about the phone? First of all, the Windows Phone 7 OS gives quite a good integration between a lot of services I use on the Internet (Facebook, my different Exchange accounts, my Google mail, Windows Live, ...). My contacts and calendars get imported automatically, which is really, really handy, no time wasted giving them all in by hand or syncing them on regular intervals. The only configuration that took a bit longer was the exchange account we use at work, but that was mainly due to the fact that Cronos uses different settings on their servers than the defaults. Normally Windows Phone 7 devices are quite capable of connecting to your exchange server while just using your email address and password. They auto-detect your mail settings and configure the connection for you.

I did have some problems though with an account I misconfigured and which I can't get deleted (there just isn't a button for it). If anyone has an answer for that, feel free to fill me in!

Next thing I like is the fact I have all kinds of data with me now. Emails are synchronised once I get near a wifi connection (I don't have a data subscription on my SIM card, but I'm thinking of getting one). Oh, and talking about my SIM card, I lost a couple hours because my card didn't get recognised by the phone. Blame it on me being a woman, but I put the card in the wrong way. Yes, that was really stupid. I even retried putting the card in a couple of times, still doing it the wrong way. My boyfriend also pointed out afterwards that there's a picture next to the slot indicating the right way. Making it even more stupid of me.

Further, the camera is fine, it also has a panorama shot option which is pretty cool, but which you don't use that often. Another feature specific to the LG Optimus is the 'Play To' app. With this you can directly play your audio, video or picture files to any devices that are capable of this. I can now stream this content to our XBox 360 or to our DLNA device. Pretty easy way to get my music loud and clear out of the Bose surround system connected to it.

App-wise I really like the Kindle reader app. We already have an Amazon account and a couple of books on our Kindle. Now being able to read those books on my phone is quite handy. I even like the navigation on the phone through these books a bit better than on the Kindle itself. I also have some RSS readers and feeds on my phone for keeping up with the news, A Facebook and Wikipedia app, a runbuddy and (of course) a lightsaber app. I just couldn't resist that last one.

Game-wise I'm thinking of buying Ilomilo now that I've played the trial. And yes, I have been able to not be tempted in buying angrybirds (yet). I also got the Guitar Hero trial, but for some reason it won't start up.

There are also some things I don't really like about the phone. First of, I went for the LG, instead of Samsung, because of its 16 Gb memory which is bigger than the 8 Gb of Samsung. But still, I think 16 Gb is not that much, and there is no way in putting in an extra memory card. Do I need that much space? Yes, I do. I like it when I have most of my music with me, which is a lot. My 30 Gb iPod has been too small for me for quite some time now.

Another thing is battery lifetime. I do need to recharge every evening. probably because I'm playing with the thing all day long, but still, I come from a simple phone that lasted a whole week. Although I need to admit that that same phone occasionally just stopped working for a day or two for no reason at all.

The Zune software isn't ideal either. But still, anything is an improvement to iTunes, which I really hate. Fact is iTunes keeps on not finding my media files even though I pointed the program to the location of the files for like a billion times. Last thing it did was not copy over my Start to Run podcast. I just hope the Zune software will do a better job at this. What I don't like about the Zune software however is the fact it doesn't give a good overview of all my media files (I miss some categories). I also had to set up a second Windows Live account so I could get at the good stuff. The Belgian marketplace just isn't what it should be.

But overall I am very very happy with my new phone. It gives me some good response times and nice features which come in handy in everyday life. I'm not that into playing with stuff that much, but I can't seem to keep my hands of this phone.

Unit Test Windows Phone 7 Project

In the windows phone 7 course I recently followed, there was an issue in unit testing a windows phone 7 project (you can find my recent post on this course here). The fact is, you can't create a Visual Studio unit test project for your phone project. Does this mean you cannot unit test your project? Of course it doesn't! Here's a solution to this problem.

First of all, I am using the MVVM pattern in my windows phone 7 project. This means my views, viewmodels and models are separated from each other, so I can place them in different projects. I created a normal windows phone 7 project for my views and a different windows phone 7 class library project for my viewmodels and models. Next thing you can now do is create a third project, also of the windows phone class library kind, which will contain your unit tests. You can see this basic setup in the following picture.

The fact that you take a windows phone 7 class library project for your unit tests is important. This solution will not work if you choose to use for instance a Silverlight class library project.
To this test project I now added the NUnit and Rhinomock dll's using Nuget and with this I can test all I want. One thing I still encountered was an error in my Unit Tests telling me the System.Windows dll could not be found.

This is quite a weird error, especially since the System.Windows.dll is present as reference in the test project. I tried adding different versions of this dll (all in my C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone folder), but no luck. Eventually I found that the dll was present in the project, but it just didn't get copied to the bin/Debug folder. Changing its Copy Local setting to True did the trick (and I kicked myself for losing quite some time on this stupid error).
So, there you go, a quick and easy way to unit test windows phone 7 projects. Soon I hope to give you some posts about my first Silverlight game and after that my first XNA game.

Windows Phone 7 Course

A couple of weeks ago I followed a two day Windows Phone 7 course (a little thank you to Microsoft for making this course free for Microsoft Partners is in place here). During the course, there were some small issues mentioned you need to take into account when developing for a Windows Phone 7 device that don't seem so obvious. Just to get you started, here's an overview of the most important stuff that's different from regular Silverlight development. I won't go into the gory details, just give you an overview of some stuff that I thought was a bit peculiar or different to what I was used to and some stuff you just need to know, which you don't find easily on the MSDN site.

First of all, when doing Windows Phone 7 development, you can use an emulator to see the result of all your hard coding work. That is, if you don't have the real stuff (which I don't, all donations are welcome!). When working with the emulator, one of the time consuming tasks, is typing in characters (eg. when editing a text box). The emulator gives you an on screen keyboard you can use to type, but this is not very practical when using your mouse! And if you try using your pc's keyboard to type, you'll find your key presses are not accepted.

There is, however a very quick and easy solution to use your pc's keyboard: just press your pause button (you know, the one you hardly ever use) and start to type. Once you're done typing, just press pause again. This will save you loads of time in the emulator.

Next, if you want to use animations in your Silverlight application, there are several ways to start a storyboard. You can do this with an event trigger in your XAML, using code, or by using the visual state manager. When developing for a Windows Phone 7 however, be aware that when using event triggers in XAML, only the Loaded event is available. Because you have this restriction, the better option to start a storyboard animation is by using code, just because it gives you more options.

Another difference is the absence of the NotifyOnException and NotifyOnValidation options you normally have for Silverlight databindings. These are just not there. If you get an error on your databinding, keep in mind, you will not see this in your interface.

If you want to unit test your Windows Phone 7 application you're out of luck. The standard unit test project type of Visual Studio is not compatible with the Windows Phone 7 project type. I am pretty sure however it must be possible to unit test your app using a 'plain old' NUnit class library (which I still think is a better option than the build in unit testing Visual Studio gives you).

One last, very small tip: don't close your emulator each time you change something in your code. It just increases the start-up time when you run your app. It's not a big thing, but it can truly save you a lot of time.

So, there you have it, some small, but still important things to keep in mind when developing for a Windows Phone 7 device. One of my next private projects will be a small 2D and 3D XNA app for the Windows Phone 7 (after teaching OpenGL and XNA a couple of years, I'm just aching to try this). I promise I will make some posts about it. And at this moment at QFrame (my company) we are also working on an (almost finished) Silverlight app for the phone, which uses Azure services and which we will demo at the Belgian TechDays 2011 next week. Be there!