27 March 2013

Enabling basic OpenLayers pinch zooming for Internet Explorer 10 touch events

A phenomenon described by the term ‘webkit monoculture’ is causing quite some concern in the web development community. A lot of web developers are basically coding for webkit and webkit only, or more specifically Safari on IOS. HTML5 and standards are great, but certain parts of the web development stack are moving back to a ‘works on my environment’ status that we just were getting rid of. This phenomenon rears it’s ugly head itself on all kind of places, including in the OpenLayers toolkit that I am using for my work at Vicrea.

For those not familiar with OpenLayers: think Google Maps, but then with real GIS functionality, without commercial licensing, without ads in the map, and without all kind of legal strings attached. Pure open source client side web GIS. With the advent of touch devices its community added some basic touch functionality to it, like pinch zoom. That works very smooth, provided – you guessed it – you work on a web kit based browser. Microsoft, in all its wisdom, has chose to implement touch events in a completely different way. As to why this is, and what exactly is standard or not – that is not exactly my concern here. I am making a web GIS that is not supported my Windows 8 touch devices and Windows Phone 8. That, of course, is unacceptable to me ;-)

So I created a little OpenLayers style control that adds pinch zoom to Internet Explorer 10. It’s pure JavaScript and a little primitive – it’s basically zooming in on the map center, and not on the point between your fingers, but it’s working pretty well IMHO.

It also works pretty simple: upon the activate command, it hooks itself onto two events of the map’s layerContainerDiv – MSPointerDown and MSGestureChanged. The first one is fired at the first touch point going down, the second one when MSGesture recognizes an MSGestureChanged. Important is also setting the map’s fractionalZoom property to true.

OpenLayersWindowsPinchZoom = OpenLayers.Class(OpenLayers.Control,
  {
    autoActivate: true,

    gesture: null,

    defaultHandlerOptions: {},

    initialize: function (options)
    {
      this.handlerOptions = OpenLayers.Util.extend({}, this.defaultHandlerOptions);
      OpenLayers.Control.prototype.initialize.apply(this, options);
    },

    activate: function ()
    {
      if (OpenLayers.Control.prototype.activate.apply(this, arguments))
      {
        if (window.navigator.msPointerEnabled)
        {
          this.map.fractionalZoom = true;

          this.gesture = new MSGesture();
          this.gesture.target = this.map.layerContainerDiv;
          var self = this;

          this.gesture.target.addEventListener("MSPointerDown", function (evt)
          {
            self.gesture.addPointer(evt.pointerId);
          });

          this.gesture.target.addEventListener("MSGestureChange", function (evt)
          {
            // Make scale result smaller to prevent high zoom speeds.
            if (evt.scale !== 1)
            {
              var scale = 1;
              if (evt.scale > 1)
              {
                scale = (evt.scale - 1) / 4 + 1;
              }
              else
              {
                scale = 1 - ((1 - evt.scale) / 4);
              }
              // map.zoomTo is buggy as hell so I use this convoluted way to 
              // calculate a new zoom area
              var resolution = self.map.getResolutionForZoom(self.map.zoom * scale);
              var bounds = self.map.calculateBounds(self.map.getCenter(), resolution);
              self.map.zoomToExtent(bounds);
            }
          });
        }
        return true;
      }
      else
      {
        return false;
      }
    },

    CLASS_NAME: "OpenLayersWindowsTouch"
  }
);

The MSGestureChanged event has a scale, which is a number either bigger (zoom in) or smaller (zoom out) than 1. After that it’s simply calling some standard map functions to calculate the new display area and fire away. The most logical one to use would be map.ZoomTo, but that completely messes up the map tile layout after a few times and this workaround via the resolution calculation prevents that. I assume there is a bug in the zoomTo code.

There is another detail – to prevent Internet Explorer to handle the zoom events itself, you have to mark the div in which the map will come with css style:

-ms-touch-action: none

I did that inline for the sake of simplicity ;-)

<div id="map2" class="smallmap" style="-ms-touch-action: none"></div>

As for creating the map with the control enabled: this is a normal map with just the standard controls:

map1 = new OpenLayers.Map('map1', 
	 {controls: [new OpenLayers.Control.Navigation(), 
                       new OpenLayers.Control.PanZoomBar()], 
	  numZoomLevels: 15});
while the second one sports my new control as well:
map2 = new OpenLayers.Map('map2', 
	 {controls: [new OpenLayers.Control.Navigation(), 
		  new OpenLayers.Control.PanZoomBar(),
		  new OpenLayersWindowsPinchZoom()], 
	  numZoomLevels: 15});

imageAnd that’s all there is to it. For the OpenLayers purists: yes, I am aware that I don’t implement destroy and potentially create memory leaks. I just wanted to kick off IE10 support. I hope the ‘real’ OpenLayers developers do better and now start supporting IE10 by themselves ;-)

I have made a little live demo site which looks like showed on the left. You can watch it live here and download a zip file containing all the necessary file in one go here.

The control has been tested successfully on a Nokia Lumia Windows Phone 8, a Microsoft RT and a Microsoft Surface Pro.

21 March 2013

Unit testing async Windows Phone 8 code on the UI thread with VS 2012.2 CTP4

imageThis may be the most cryptic acronym-laden title I ever used for a blog post, but it quite exactly describes what I was trying to do yesterday.

The Visual Studio 2012 CTP4 makes it possible to write real Windows Phone 8 unit tests that run in the Visual Studio Unit Test runner (in stead of only on the emulator). So when I wanted to investigate the Routing API that is new in Windows Phone 8, I decided not to write an application outright, but start out with unit test.

I set up a new solution with two projects, as I usually do: one with the actual app - and one class library with the view models, models and other logic in it that isnot directly related to the user interface. And then I added a Windows Phone 8 Unit Test App.

First things first: when I want to test routing, I first need to give the user an option to select a location to go to. I decided to use the Geocoding API. I decided the view model should contain the following:

  • A string property SearchText to be filled by the user
  • An ObservableCollection of MapLocation called MapLocations to be filled by the Geocoder, intended to be bound to a list control of some kind to enable the user to select on of the founds locations.
  • A MapLocation property SelectedLocation to hold the MapLocation selected by the user
  • A little method to actually perform the geocoding
  • A command wrapping this method.

My good and very smart friend - and fellow Phone development MVP - Matteo Pagani has already covered some ground in this direction by writing this article and inspired by it I decided to pull in the Microsoft.Bcl.Async library as well so I could use async/await, on the premises that you can never have too much beta software in your project ;-)

The method I wanted to test was pretty simple:

public async Task SearchLocation()
{
  MapLocations.Clear();
  SelectedLocation = null;
  var geoCoder = new GeocodeQuery { 
SearchTerm = SearchText, GeoCoordinate = new GeoCoordinate() }; MapLocations.AddRange(await geoCoder.GetMapLocationsAsync()); }

And so was the test method – I let it search for the street I live in.

[TestMethod]
public async Task TestLocationWrong1()
{
  var testVm = new GeocodeViewModel
    {SearchText = "Springerstraat Amersfoort Netherlands"};
  await testVm.SearchLocation();
  Assert.IsTrue(testVm.MapLocations.Any());
}

imageI ran the test…. and was quite surprised by the result. “Invalid cross thread access"??? I don’t even have a UI. Very interesting. Apparently the GeocodeQuery needs to be run on the UI thread. As to why this is, I have no idea. Some people (hi Morten ;-) ) say that if you have to unit test on the UI thread, you are doing it wrong. That may be the case, but it seems I have little choice here and  I still want to test my view model.

According to this page there is a UITestMethodAttribute for Windows Store applications to solve this kind of problems – but not for Windows Phone 8 (yet) so obviously I had to pull in the Dispatcher. Since calling stuff from the Dispatcher runs asynchronously as well take 2 didn’t work of course…

[TestMethod]
public void TestLocationWrong2()
{
  var testVm = new GeocodeViewModel 
  { SearchText = "Springerstraat Amersfoort Netherlands" };
  Deployment.Current.Dispatcher.BeginInvoke(async () => await testVm.SearchLocation());
  Assert.IsTrue(testVm.MapLocations.Any());
}

…for the simple reason that the although testVM.SearchLocation is now fired on the UI thread, the Assert is not, and it is executed directly after the BeginInvoke is called and MapLocations still is empty when the Assert is evaluated.

I don’t know if there’s a smarter way to do this, but I used an AutoResetEvent to solve it. I used that to block the test thread until the UI thread is done, like this:

[TestMethod]
public void TestLocationSearchHasResult()
{
  var waitHandle = new AutoResetEvent(false);
  var testVm = new GeocodeViewModel { SearchText = "Springerstraat Amersfoort Netherlands" };
  Deployment.Current.Dispatcher.BeginInvoke(async () =>
    {
      await testVm.SearchLocation();
      waitHandle.Set();
    });
  waitHandle.WaitOne(TimeSpan.FromSeconds(5));
  Assert.IsTrue(testVm.MapLocations.Any());
}

image

The test thread waits until waitHandle.Set() is called – or five seconds, whatever happens first – and then it performs the Assert. And that works.

As usual, you can download a demo solution here. It was actually meant to be a solution demoing the Route API, as stated earlier, but I thought this subject deserved a blog post on its own.

As stated, this project requires installation of the Visual Studio 2012 CTP4. This has a GoLive license, but it’s still preview software. Install it on your own risk.

Update: Pedro Lamas, a Windows Phone Development specialist working for Nokia, has posted about his port of UITestMethodAttribute to Windows Phone. That runs the whole test on the UI thread in stead of only the the mandatory part. This brute-force method may not be desirable for all cases, but it sure is pretty easy to use.

13 March 2013

Simple reverse geocoding with Windows Phone 8 and MVVMLight

screenshotHaving worked in Geographical Information Systems over 20 years, I can tell you rightfully the new Windows Phone 8 mapping and location abilities are more than enough to make a map maniac like me getting twinkly eyes. It has capabilities that are unheard of even just a couple of years ago – and I don’t need a big workstation, I don’t even need a PC - it’s running on my phone. The world in my pocket – in the most literal sense possible.

Two popular applications of GIS are geocoding and reverse geocoding. Geocoding enables you to find the position of earth for a descriptive text – say an address, city, building name, or any other phrase indicating a place on Earth. This is usually rather straightforward. Reverse geocoding is exactly the opposite – it’s the “what’s here?” question – given a location, what do I find here? Incidentally, answering questions like this is how I make a living at Vicrea.

Windows Phone 8 makes reverse geocoding almost embarrassingly easy. Even when using MVVMLight. So I made a simple app that show the address(es) found at the location where you tap on the map.

We start off with a simple model with two properties:

using System.Collections.ObjectModel;
using System.Device.Location;
using System.Linq;
using GalaSoft.MvvmLight;
using Microsoft.Phone.Maps.Services;

namespace TapReverseGeocode.Logic.ViewModels
{
  public class MapViewModel : ViewModelBase
  {
    public MapViewModel()
    {
      Addresses = new ObservableCollection<string>();
    }

    private GeoCoordinate tapCoordinate;
    public GeoCoordinate TapCoordinate
    {
      get { return tapCoordinate; }
      set
      {
        tapCoordinate = value;
        RaisePropertyChanged(() => TapCoordinate);
        StartReverseGeoCoding();
      }
    }

    public ObservableCollection<string> Addresses { get; set; }
  }
}

The ObservableCollection “Addresses” will hold the results, and as usual when binding to ObservableCollection you must make sure it is initialized before anything else – the constructor is a good place for that. The designer can bind this to some kind of GUI element that displays the result.

The TapCoordinate property is a GeoCoordinate and that fires off the actual reverse geocoding – and I have omitted the usual “if (viewModelPropertyName != value)” check on purpose. Even when the user taps the same location twice, I want to have the reverse geocoding code to fire every time.

The code that starts the reverse geocoding itself ain’t quite rocket science:

private void StartReverseGeoCoding()
{
  var reverseGeocode = new ReverseGeocodeQuery();
  reverseGeocode.GeoCoordinate = 
    new GeoCoordinate(TapCoordinate.Latitude, TapCoordinate.Longitude);
  reverseGeocode.QueryCompleted += ReverseGeocodeQueryCompleted;
  reverseGeocode.QueryAsync();
}

To prevent race conditions I make a new GeoCoordinate from the one provided by the user, set up a call back, and fire off the async query.

The final piece is this simple callback that processes the result of the reverse geocoding.

private void ReverseGeocodeQueryCompleted(object sender, 
  QueryCompletedEventArgs<System.Collections.Generic.IList<MapLocation>> e)
{
  var reverseGeocode = sender as ReverseGeocodeQuery;
  if (reverseGeocode != null)
  {
    reverseGeocode.QueryCompleted -= ReverseGeocodeQueryCompleted;
  }
  Addresses.Clear();
  if (!e.Cancelled)
  {
    foreach (var adress in e.Result.Select(adrInfo => adrInfo.Information.Address))
    {
      Addresses.Add(string.Format("{0} {1} {2} {3} {4}", 
        adress.Street, adress.HouseNumber, adress.PostalCode,
        adress.City,adress.Country).Trim());
    }
  }
}

It clears up the callback, clears the Addresses list, and then processes the parts of the result into a single string per address. Like any good reverse geocoding service Microsoft have implemented this to return a set of results – there may be more addresses on one location, for instance in a large apartment building – although I never got more than one result back per location when I tested this in the Netherlands.

This a complete reverse geocoding viewmodel that basically does not care where the GeoCoordinate comes from, or the result goes to. So this is very versatile. There isn’t any GUI, and yet we already have a working app

The initial XAML for binding this stuff – after setting the datacontext to this viewmodel – looks pretty simple:

<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
  <maps:Map/>
  <Grid Height="58" VerticalAlignment="Top" Background="#7F000000">
    <phone:LongListSelector ItemsSource="{Binding Addresses}" 
      HorizontalContentAlignment="Left" Margin="12,0"/>
  </Grid>
</Grid>

… and then we run into a challenge. Two actually. The last tapped location is not a property we can bind to, and that the location is a Point – a screen location, not a GeoCoordinate in real world coordinates.

This can be solved by using an Attached Dependency Property (I think), by some Code Behind or my trademark way - by creating a simple behavior. After all, I don’t want to bother designers with code and I like the easy reusability of a behavior:

using System.Device.Location;
using System.Windows;
using Microsoft.Phone.Maps.Controls;
using Wp7nl.Behaviors;

namespace Wp8nl.Behaviors
{
  public class TapToCoordinateBehavior : SafeBehavior<Map>
  {
    protected override void OnSetup()
    {
      AssociatedObject.Tap += AssociatedObjectTap;
    }

    void AssociatedObjectTap(object sender, 
      System.Windows.Input.GestureEventArgs e)
    {
      var tapPosition = e.GetPosition((UIElement)sender);
      TappedCoordinate = 
        AssociatedObject.ConvertViewportPointToGeoCoordinate(tapPosition);
    }

    protected override void OnCleanup()
    {
      AssociatedObject.Tap -= AssociatedObjectTap;
    }

 // GeoCoordinate TappedCoordinate dependency property omitted

   }
}

This behavior is implemented as a SafeBehavior child class, to prevent memory leaks. It’s actually pretty simple – it traps the ‘Tap’ event, determines the location, converts it to a GeoCoordinate and puts it into the TappedCoordinate Dependency Property. Which, in turn, can be bound to the view model. The designer can simply drag this behavior on top of the map and set up the data binding. Don’t you love Blend? XAML take 2:

<Grid x:Name="ContentPanel" Grid.Row="1" 
   Margin="12,0,12,0">
  <maps:Map>
    <i:Interaction.Behaviors>
      <Behaviors:TapToCoordinateBehavior 
          TappedCoordinate="{Binding TapCoordinate, Mode=TwoWay}"/>
    </i:Interaction.Behaviors>
  </maps:Map>
  <Grid Height="58" VerticalAlignment="Top" Background="#7F000000">
    <phone:LongListSelector ItemsSource="{Binding Addresses}" 
           HorizontalContentAlignment="Left" Margin="12,0"/>
  </Grid>
</Grid>

And that’s all there is to it. Reverse geocoding is Windows Phone 8 is insanely easy.

Full source code, as usual, can be downloaded here.

08 March 2013

Surface RT versus Surface Pro versus the competition for REAL dummies

About every pundit who is somewhat interested in Microsoft either by love or abject hate has written about this already – and still I am going to do my take. Why? Because I am one the few people on this planet who actually was crazy enough to purchase both a Surface RT and a Surface Pro and therefore am entitled to my rant – and because I still get comments like “I think Surface Pro is too expensive for a tablet and has too little battery life for it”, which indicates people still completely don’t get it. With ‘tablet’ almost invariantly people mean “iPad”, by the way.

The very short version of this post is this ‘infographic’

pro2RT2

I used a mathematical symbol which means ‘is equivalent to’. That is something entirely different than “equals to”. Very important distinction. Keep that in mind. I will use a lot of ‘equivalents’ in this blog post rant.

When you think of a Surface RT – think of something that moves in the same space as an iPad. Long battery life, relatively cheap (don’t get me started on Apple pricing), light, ideal for use on your lap or in your hand, good content consumption device. Plus some extras. But let’s not confuse the picture alrimageeady.

When you think of a Surface Pro – think of an Ultrabook. Yes, a real computer. A real powerhouse too, ultra portable, and it runs the full Monty – I mean Windows 8 - but that comes at a price. It’s heavier, more expensive, burns more battery, and it gets hotter too. Of course it does. Look, it’s like saying “My wife has this cute Japanese car that does over 50 miles to the gallon when she’s doing 70 on the interstate but this other car burns much more fuel and generates a lot of exhaust” and then the car you use…

…is the car equivalent of something like this:image
Dude, I have some bad news for you. If there’s indeed the equivalent of an F22 Raptor sitting in your driveway when you just want to do some cruising, you might have paid some more attention to the brochure or might have asked some more questions at the dealer clerk before getting out the ole’ VISA card. This machine can carry more and heavier load than your wife’s car – and it can take it there very much faster. This machine is made for serious business. As is Surface Pro. Only with less pyrotechnics.

Now I will admit Microsoft has made life a little bit more complicated than my simple images and broad statements do justice. That’s because of a very a simple reason: the current state of affairs in electronics, as well as the radical design approach the Surface hardware engineering team took, made it possible that under the “Surface” flag now reside two very similar looking – but very dissimilar devices. It’s like the F22 and your wife’s Japanese car nearly look the same, have the same controls, and even share accessories – but one will be a very good car, the other will take off at supersonic speed and be halfway Some Place Where Bad People Live (and – admittedly – a place where those Bad People won’t probably be for very much longer) before your wife has even made it to the onramp of the interstate. Incidently, your wife may be in for a hell of surprise when one day she just wants to take the kids to school and takes the wrong key set ;-).

The funny thing is – radical as it’s design may be, Surface Pro is ‘just a PC’. As I showed in the ‘infographic’ above, it’s actually ‘just an Ultrabook’, in the same way an F22 is ‘just a jet airplane’. Surface Pro is the nth generation descendant of all the PC’s in the world, and it’s odd that it took a software company to let it see the light. Yet, the smaller, cheaper Surface RT is actually a much more remarkable and innovative design – it runs on total different hardware, that has an extremely long battery life, but still it runs Windows 8. Like I said, RT is more like a tablet. But, to make things more complicated, in a smart move to make their ‘tablet’ offering more attractive and not just another me-too, Microsoft have made it possible to attach a keyboard to Surface RT and ships you a fully licensed Home version of Office. You get the crown ‘desktop jewels’ for free. Office in a very portable box. So in stead of only a consumption device, Surface RT is also a content creation device. You can make Word documents, Excel sheets, PowerPoint presentations just like on any other PC. Using a traditional desktop program. You can even attach a mouse to it using it’s USB port. So your tablet can act like a PC to an extent. And here my infographic breaks down, and my F22 versus the wife’s car analogy as well. It’s like your wife’s car has this extra set of controls that can be used to fly short distances at limited height as well - wouldn’t she want have that to overcome traffic jams and red lights ;).

So a more accurate way to position RT next to the competition is like this:

RT3

There is this other funny side effect too – because Surface RT runs on different hardware, the ‘foundation’ of it’s Windows needed to be changed too. You can hardly see that on the outside, but it has profound effects, one of them being that Windows RT – the Windows version that runs on Surface RT - is completely impervious to viruses. It’s like trying infect a fish with the human common cold – DNA does not match, the organs that are needed for infection are simply not there.

So it comes down to this:

  • Surface Pro is a PC – it may look like a tablet and it can be used as a tablet, but it’s not its primary intended use. It’s a bit heavy for that and has this other characteristics that doesn’t make it the ideal tablet. Just like an F22 can be used on the highway – but it’s better in the air. You are doing development? Heavy gaming? Heavy duty photo or movie editing? This is the machine for you.
  • Surface RT is primary a tablet but can also be used for some PC (Office) tasks that used to require a full PC. It’s like a car that can fly a little, but it cannot carry deadly loads with it. You are doing office, mail and some content/web browsing, casual games, maybe a bit of movie watching? A lot of it on the go, removed from any outlet?  Try this one.

And of course, you can also try any other kind of device, running either Windows RT or Windows Pro (i.e. being equivalent to Surface RT and Surface Pro) to find out what suits your need. I give you only one golden rule – whatever you buy, Surface or no Surface, RT of Pro – make sure it has a touch screen. With touch Windows 8 really shines.

PS: In case anyone wonders whether or not I am happy with my choice for Surface Pro as a portable development machine – let me just quote my fellow MVP Rob Miles on that one: “HELL YEAH!”

02 March 2013

Publishing games in the Brazilian Windows Phone store

Brazil, a strong developing economy, is the largest country is South America, and has the biggest population of South America as well. From a game developer’s standpoint, it’s unfortunately also one of the ‘restricted’ countries. In short, this means you cannot submit a game – any game - to the Brazilian Windows Phone store without it being rated first. Since most developers outside of Brazil think this is a complicated and expensive procedure, and don’t speak Portuguese anyway – they tend to uncheck the Brazilian store and thereby leaving the Brazilians stranded, and denying themselves the opportunity to branch out in South America.

Now this is no longer necessary. A Brazilian guy named Guilherme S. Manso contacted me on twitter about a month ago claiming he made a write-up describing how to get your game rated for the Brazilian store. This got me about half-way, and the rest was explained to me in a Skype session by my fellow Phone Development MVP Rodolpho Marques Do Carmo. With Guilherme’s permission I reworked both explanations to one blog post, making it easy for every game developer to enter the Brazilian store. And the procedure is free, too.

If the game already has an ESRB or PEGI game rating
imageRecently, the government of Brazil started accepting the indicative international PEGI and ESRB ratings as a prerequisite for a “national auto rating”. That is, if a game has been rated by any of these institutions, all you need to do is to select one of the age groups from the DJCTQ (the Brazilian government rating) and attach the document that proves that the game has the PEGI or ESRB rating when you submit the game in the Windows Phone Development center. You must choose an age range that matches as closely as possible to the age received by indicative classification PEGI or ESRB. L is for all ages, the others show the age groups – 10 years, 12 and so on. If you already have a rating like this you probably know all about rating and probably don’t need this blog post anyway. I did not follow this track – my game had no rating at all.

If you don’t have any rating yet and want a Brazilian specific rating
First of all, you will need this document. It’s mostly English so it should be intelligible for almost everyone able to read this blog post ;-). It’s a Word document, and it mostly contains check boxes. I ticked check boxes by right-clicking them, selecting “Properties” and then clicking “Selected” under “default value”. You have to fill in some other stuff and then you have to hand-sign it. It’s rather straightforward. You can then print the result, sign it and scan it, or – as I did - sign it with the a pen on a tablet and save the result as PDF. The word document as I used it – minus my signature – can be seen here and used as an example.

Second, you will need to write a synopsis of the game – and provide game itself. I did this the easy way and combined these points: I made another Word document that described the game, provided a global store link to the game, a link to the game in the USA store, and I made a video of the game play that I made available for download. The document I used can be found here. They have a lot of games to process, so make the work of the raters as easy as possible. Another tip: make sure there is a trial version of the game available. If the game needs to be bought first, it will take much longer to get certified.

Third – optionally – you will need to provide a bill of rights for the game. This is only necessary when the Rating Requester Name is different from the Publisher Name (or when it’s not clear that it comes from the same producer). It is a simple statement signed by hand as well, saying that you are the copyright owner of the game or that the holder is aware that you are asking for the classification. Since that did not apply to me, I have no example of that.

E-mailing the rating request
You will need to e-mail the rating request document (the thing with all the checkboxes), the synopsis and optionally the bill of rights to classificacaoindicativa@mj.gov.br.
The title of the mail needs to be: "Jogo para Classificação - <your game name>" (this is the only part that needs to be Portuguese).
I simply e-mailed:
"Dear Sir, Madam,
I hereby request certification of my game Catch’em birds for release in Brazil according to the attached documentation.

Highest regards

Joost van Schaik
Amersfoort
The Netherlands

Obtainingimage the game certificate
Here things get a little odd: certification will take about ten days, but you will not be informed about the progress or the result. You will need to go to this page regularly to check if your app has passed certification. It shows itself like showed to the left. You simply enter the name or part of the name of your game, click ‘consulta’, and with any luck it will show a result. There is a catch: it will only displayed on this page for a pretty short time. If you miss it, you will get this page, which basically means ‘not found’

image
But, if you hit the grey bar at the left bottom that says “Abrir/Fechar Pesquisa” you get an extended search form that allows you to enter dates and stuff:image
So here I ask the ‘find everything (todos) that contains the word ‘birds’ and was approved between January 1st and February 28th 2013 and now if you hit ‘consulta’…

image
Bingo! Click the blue header (in my case “Diário Oficial da União - Seção 1 - Edição nr 38 de 26/02/2013 Pag. 27”) and this will download a file called “INPDFViewer.pdf”. That’s basically a page of a Brazilian law book saying your game is permitted for the given classification. There’s a bunch of games on that page, but near the end of the page it says:
Título: CATCH`EM BIRDS (Holanda - 2012)
Titular dos Direitos Autorais: JOOST VAN SCHAIK
Distribuidor(es): JOOST VAN SCHAIK (MICROSOFT`S WINDOWS PHONE STORE)
Classificação Pretendida: Livre
Categoria: Ação
Plataforma: Telefone Celular/Smartphone
Tipo de Análise: Sinopse e Vídeo
Classificação: Livre
Processo: 08017.004064/2013-35
Requerente: JOOST VAN SCHAIK

And that’s it. Now you can tick the ‘Brazil’ checkbox in the Windows Phone dev center, select a category according to your classification, and upload the INPDFViewer.pdf as proof. I have tried this procedure to the end, and my game is now in the Brazilian store. And so, my friends, can be yours. The road to Brazil is now wide open for game developers, thanks to Guilherme and Rodolpho, so let’s go to Brazil!

BTW, I haven’t tried this but I assume publishing Windows 8 Store apps can be done following the same procedure.