Quite a few people have asked me of the last few weeks about what is happening with the AdRotator project, is it dead, are we on a permanent holiday (Vacation for our American chums) or did we just get board with the whole thing as we have been fairly quiet of late.

Let me put one ting to bed,

(just resting )

Both Gergely and I had our work / family schedules ramp up quite a bit for the last few months ( by a few I really mean a lot) but this doesn’t mean we have lost interest in AdRotator, far from it our goals with the next version keep getting more and more ambitious and we have already done a fair bit of ground work already, such as:

## The new XML configuration

One of the biggest pains in V1 was the XML config, it was either not configurable enough or was limiting in very annoying ways, you could just push ads but that was about it and you had no control over how they functioned.  We added house ads to give you a bit more control and potentially sell ad space in your apps but again this was quite limiting as you could only have 1.

The new config XSD has been stable for a while now and had these goals:

• Each config line is separate Ad space supporting any of the enabled Ad Providers (break the one line per provider in V1) – Allow multiple Ad Units to be used per provider
• Add AdRotator features to XML config such as Sliding Ad, Refresh Rate, etc (per config / per provider?)
• Compress XML config – (SHOULD)
• Size of ad space – (MUST) – Will especially be important on Win8
• Ad Order – Ability to specify an order of Ads, rotate in order
• Ad Groups – With the addition of multiple ads per provider, should we also have the capability to group settings?

The new XSD looks like this (for you XML freaks out there ) – granted we’ve not actually gone to the level of having an actual XSD before but thought it pertinent for V2

<?xml version="1.0" encoding="utf-8"?>
<xs:sequence>
</xs:sequence>
</xs:complexType>

<xs:choice minOccurs="0" maxOccurs="unbounded">
</xs:choice>
<xs:attribute name="CultureName" type="xs:string" />
<xs:attribute name="Width" type="xs:double" />
<xs:attribute name="Height" type="xs:double" />
<xs:attribute name="Probability" type="xs:int" />
<xs:attribute name="EnabledInTrialOnly" type="xs:boolean" />
</xs:complexType>

<xs:complexContent>
</xs:complexContent>
</xs:complexType>
<xs:complexContent>
</xs:complexContent>
</xs:complexType>
<xs:complexContent>
</xs:complexContent>
</xs:complexType>
<xs:complexContent>
</xs:complexContent>
</xs:complexType>
<xs:complexContent>
</xs:complexContent>
</xs:complexType>
<xs:complexContent>
</xs:complexContent>
</xs:complexType>
<xs:complexContent>
</xs:complexContent>
</xs:complexType>
<xs:complexContent>
</xs:complexContent>
</xs:complexType>

<xs:choice minOccurs="0" maxOccurs="unbounded">
</xs:choice>
<xs:attribute name="Width" type="xs:double" />
<xs:attribute name="Height" type="xs:double" />
<xs:attribute name="Probability" type="xs:int" />
<xs:attribute name="EnabledInTrialOnly" type="xs:boolean" />
</xs:complexType>

<xs:attribute name="AppId" type="xs:string" />
<xs:attribute name="SecondaryID" type="xs:string" />
<xs:attribute name="Width" type="xs:double" />
<xs:attribute name="Height" type="xs:double" />
<xs:attribute name="Probability" type="xs:int" />
<xs:attribute name="IsTest" type="xs:boolean" />
</xs:complexType>

<xs:restriction base="xs:string" >
<xs:enumeration value="PubCenter"/>
<xs:enumeration value="InnerActive"/>
<xs:enumeration value="MobFox"/>
<xs:enumeration value="Smaato"/>
<xs:enumeration value="None"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="SlideDirection">
<xs:restriction base="xs:string" >
<xs:enumeration value="Top"/>
<xs:enumeration value="Bottom"/>
<xs:enumeration value="Left"/>
<xs:enumeration value="Right"/>
<xs:enumeration value="None"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>

Now this is just the initial cut and I expect this to evolve over time but with the flexibility included this shouldn’t break compatibility

## More reflection support

In V1 we use reflection a little bit, mainly for the house Ads but big pains expressed regularly were:

Why can I only have one of each provider (to support flip flop configuration between backend provider settings)
Why do I have to have all provider DLL’s registered in my app, even if I don’t use some
Why don’t you support provider x
Where is my coffee, why doesn’t it make me coffee?

Ok the last was a reach but you get the point, the first also created a pain for House Ads, since you had to do careful trickery to get round the configuration limitation 9if at all you even did)

Adding new provider has always been a pain just because of the various ways each work, the network calls they have and the platform support they have, some even have WebAPI support for non-traditional platforms and why didn’t we support that (well in the XNA version we do to a level but it never got out of that box)

So in V2 we are breaking that mold and have already made strides on how to implement this, it’s far from ready but we have a god idea, in fact it was #1 on our bucket list but Gergely is our reflection expect (I’m still a noob there) and his time as been even more limited than mine.  However we have made some progress towards that goal

## PCL Support

If you have been following my blog I have become a bit of a PCL nut these days and shoving PCL projects into whichever situation is was most effective (PCL is not a 1 solution cures all , it has it’s uses like any other technology).  With AdRotator this was no different.  All code that we can put into a PCL we are doing so and abstracting where platform dependencies are to limit the level of rework necessary for additional client platforms.  Even my recent experience with the MonoGame team has helped shape some of this vision.

With the WebAPI version we may even release a completely PCL version but we will have to see how easily that pans out with the ever increasing support for functions in PCL projects.  Thanks to recent development we’ll be able to have the compression support in our core PCL project thanks to some recent developments, yay.

# The Future

We are working as hard and as fast as we can with V2, support or V1 is limited at the moment but we still help out where we can but apart from emergency fixes it’s unlikely we’ll be releasing an updated version of that soon (apart from the current Alpha release which is awaiting community testing and any other patches required), our focus is on V2 with the limited time we have.

If you want to get involved then you can, the V2 site is a GIT site and you can fork away, make changes and send us a pull request.  Keep changes small  if you can to ease merging back into the main branch ( a lesson hard learnt on the MonoGame project ).