Adapter ratio management about larsadcontroller HOT 4 OPEN

This is an excellent idea. If this were to be done, I would prefer that it be generalized in such a way that you could easily use ground control or any other way to remotely control the ad priority or filling modes between ad networks. That way if a given ad network were performing better than another, you simply adjust its settings.

It would have to have an interface method like you mentioned above, but also be able to be overridden at runtime so that you could optionally have the ad controller pull the settings from an arbitrary location that the developer specifies (like a block of code or a custom method to invoke) in order to use a service like ground control.

Off the top of my head (with your thoughts above), this is what I see as possible implementations for this:

1. Compile-time setting of ratio with a static method:
   - (void)registerAdClass:(Class)class withPublisherId:(NSString *)publisherID withRatio:(CGFloat)adRatio
2. Compile-time blocks on an adapter that pull settings at runtime:

@property (nonatomic, copy) CGFloat(^ratioBlock)(CGFloat tapRatio);
@property (nonatomic, copy) NSUInteger(^priorityBlock)(void);

1. Combine the two methods above and have the user specify a specific adapter instance with the above properties already configured (publisherID, update blocks, etc). This would require some refactoring in the adapters to support persisting instances. The only problem this presents is that some ad networks do not have a concept of "pausing" ad requests, which is why I'm currently just deallocating the ad instances and recreating them when I need them.
   - (void)registerAdapter:(id<TOLAdAdapter>)adapterInstance;

I'd like for this to be scalable for other settings within an adapter without also cluttering up the public interface. I would like to avoid the "swiss-army knife" approach to this class.

Let me know what you think.

from larsadcontroller.

That looks like a great approach -- I like the idea of both a "set it and forget it" option (which of course still allows adjustments of ad network ratios at the time of app updates) as well as a more active (remote) management of the ad network ratios. No extra lines of code in the app delegate also makes sense, although adding a line into - (void)applicationWillEnterForeground:(UIApplication *)application may be necessary to destroy banners and reregister adapters as needed (unless you can think of a better way?).
How would you like to move forward, considering I produce lower quality code? Do I get started in a fork anyway or do you prefer to take the lead right away on this?

from larsadcontroller.

I think that if you're interested, you should begin work on it. I'm going to start a new branch to begin this work. I don't have a timetable on completion of this, however, since this is a side project of mine.

from larsadcontroller.

See a first try @ https://github.com/Fred10932/LARSAdController/tree/Managed_Adapter

Had to modify Groundcontrol somewhat to deal with servers that return a Plist as text/plain instead of application/x-plist.

I also added a change of adapters after a specified time. The reasoning behind this is that if user hasn't clicked on the ad after a few minutes, the likelihood is small that user will ever click on it.
To do:

• Proper adapter cleanup after change
• Test Plist in application/x-plist mode on server with htaccess support
• Testing and cleaning up code

from larsadcontroller.