EUID Support

[dcaunt]

Implements EUID Support via a new EUIDManager type which vends a UID2Manager configured for EUID.

There is a new AndroidManifest meta-data key uid2_environment_euid for toggling the EUID environment in the dev app.

Reference iOS PR: IABTechLab/uid2-ios-sdk#57

• Add EUIDManager
• Add toggles to dev app to change environment from UID2 to EUID

EUID support in GMA and IMA adapters to follow in separate PRs.

[dcaunt]

Not clear to me yet if this should still be UID2, or EUID.

[IanDBird]

I don't know how we get these AdError's reported, so i'm not sure. Worth asking the team though.

[IanDBird]

I don't know how we get these AdError's reported, so i'm not sure. Worth asking the team though.

[mrmans0n]

The existence of this different class that's just a factory for a slightly different UID2Manager seems pretty weird. From my lack of knowledge, what is exactly changing here from the normal UIDManager.getInstance ?

We could either go the factory function route, the extension route, the initializing lambda route, etc. But to be able to give a helpful suggestion I'd need to know what is changing exactly here.

FWIW The java-ish UID2Manager shape is not exactly helpful either here XD

[mrmans0n]

Another alternative is, if possible, working toward this being an object instead of a class because you could pretty much instantiate an EUIDManager class here that'd be kind of useless (and misleading).

[koalaparadise]

+1

[IanDBird]

The challenge here is trying to keep backwards compatability with existing integrators.

Another alternative is, if possible, working toward this being an object instead of a class because you could pretty much instantiate an EUIDManager class here that'd be kind of useless (and misleading).

Dave and I have spoken about this previously, and would both love to move away from a singleton. Our current thinking is to consider this when moving to 2.0.0 of the SDK, so later - as it impacts a lot of other things (e.g. all the documentation already created for publishers).

I do agree we should consider what's easiest for publishers to consume. Since a lot will support an app that supports both UID2 and EUID, the existing interface means they will be required to do this constantly:

if (isUID2) { UID2Manager.getInstant() } else { EUID.getInstance() }

The alternative would be to just change the UID2Manager.init method to allow UID2 vs EUID configuration (and environment) and everyone access directly via UID2Manager.

[koalaparadise]

+1

[IanDBird]

Nit: Since this is dev code, I don't feel strongly at all, but just to call out that for the vast majority of users, the default will be UID2. Therefore it would make sense to have this inverted where true is the default, and therefore isUID2.

[dcaunt]

I reverted the manifest back to false as that was my intention. Is that what you meant? EUID would then only be used if the manifest value is set to true.

[IanDBird]

The challenge here is trying to keep backwards compatability with existing integrators.

Another alternative is, if possible, working toward this being an object instead of a class because you could pretty much instantiate an EUIDManager class here that'd be kind of useless (and misleading).

Dave and I have spoken about this previously, and would both love to move away from a singleton. Our current thinking is to consider this when moving to 2.0.0 of the SDK, so later - as it impacts a lot of other things (e.g. all the documentation already created for publishers).

I do agree we should consider what's easiest for publishers to consume. Since a lot will support an app that supports both UID2 and EUID, the existing interface means they will be required to do this constantly:

if (isUID2) { UID2Manager.getInstant() } else { EUID.getInstance() }

The alternative would be to just change the UID2Manager.init method to allow UID2 vs EUID configuration (and environment) and everyone access directly via UID2Manager.