Option 2:

This option requires modifying the definition of ConsentType and ConsentStatus, changing them to be String constants for better compatibility with Objective-C.

Public types

ConsentType

@objc(AEPConsentType)
public class ConsentType: NSObject {
    public static let collect = "collect"
}

ConsentStatus

@objc(AEPConsentStatus)
public class ConsentStatus: NSObject {
    public static let yes = "yes"
    public static let no = "no"
}

Retrieving current consents

Definition:

The difference here is that API now returns a dictionary of String's for both Swift and Objective-C.

/// Returns a dictionary containing all the consents and their current status as strings
/// - Parameter completion: invoked with a dictionary containing the consent type mapped to the current consent status
@objc(getConsents:)
static func getConsents(completion: @escaping ([String: String]?, Error?) -> Void)

Swift usage:

Consent.getConsents { (consents, error) in
    // check error, handle consents
   guard error == nil else { return }
   let collectConsent = consents[ConsentType.collect] // value would be a `String`
}

Objective-C usage:

[AEPConsent getConsents:^(NSDictionary<NSString *,NSString *> * _Nullable consents, NSError * _Nullable error) {
    if (error != nil) { return; }
    NSString *consentStatus = consents[AEPConsentType.collect];
}];

Updating/setting a consent

The difference here is that API now accepts String parameters rather than enums.

Definition:

/// Updates a given `ConsentType` to a `ConsentStatus`
/// - Parameters:
///   - type: the `ConsentType` to be updated
///   - status: the `ConsentStatus` for `type`
@objc(setConsent:status:)
static func setConsent(type: String, status: String) 

Swift usage:

 // set collect to yes
Consent.setConsent(type: ConsentType.collect, status: ConsentStatus.yes)

// set collect to no
Consent.setConsent(type: ConsentType.collect, status: ConsentStatus.no)

Objective-C usage:

 // set collect to yes
[AEPConsent setConsent:AEPConsentType.collect status:AEPConsentStatus.yes];

// set collect to no
[AEPConsent setConsent:AEPConsentType.collect status:AEPConsentStatus.no];

from aepsdk-edgeconsent-ios.

Option 1 provides a better Swift experience in my opinion, albeit very minimal by using enums rather than using strings as a substitute for enums. However, it doesn't provide a nice interface for Objective-C, as you have to use "magic" strings to index the consents and their status.

Option 2 uses strings as a substitute for enums, allowing for similar usage when indexing and reading consent status. However, this increases the possible inputs into the API, and could lead to accidental misuse of the APIs.

from aepsdk-edgeconsent-ios.

It's my impression that getConsents will return all consents while setConsents will only allow setting a subset of the consents (maybe only "collect"). For example we only want "adId" consent updated when setAdvertisingIdentifier is called.
How will we restrict which consent preferences are set? Will we have a separate ConsentType enum or just throw/return errors from setConsent?

from aepsdk-edgeconsent-ios.

@lind The newly proposed type ConsentType will be a public-facing enum that is not used internally within the extension (besides the public API). We will define it based on which consents we want available for the customer to modify. That way we can restrict which type of consents can be set via the public API.

from aepsdk-edgeconsent-ios.

@nporter-adbe thanks for putting this up. Before we go into the implementation details, can we make the Consent type even more flexible to account for values like these in the future?

...
 "xdm:personalize": {
      "xdm:content": {
        "xdm:val": "y"
      }
    },
"xdm:marketing": {
      "xdm:push": {
        "xdm:val": "n",
        "xdm:reason": "Too Frequent"
      }

ref https://github.com/adobe/xdm/blob/master/components/datatypes/consent-preferences.example.1.json

We should also consider:

• allowing the developer to update multiple consents at once
• have the same format for input/output in the set/get APIs so they can easily compare with their cached consents as in this example:

getConsents(completion: @escaping (consents: Consents?, Error?) -> Void {
   ...
    if consents not equal localConsents 
       updateConsents(consents.merge(localConsents))
}

from aepsdk-edgeconsent-ios.

@dobrin I took a look at that link regarding different consent examples, and they are quite confusing. It appears they do not follow any hard schema. Some contain keys such as "content", some contain "reason" some contain "preferred". I'm not sure how we are supposed to model those types, given there is no consistency. The strangest one to me is the personalize consent how it has the value nested within a "content" field.

The only thing that pops into my head is allowing an optional free form dictionary to be passed in when setting a consent, which isn't a great experience. For us to provide good APIs, we need consistent types that conform to some sort of schema.

Do you have any suggestions?

setConsent(type: .push, status: .no, data: ["reason": "Too frequent"])

For your last two bullet points:

• Regarding setting multiple consents at once, we could provide a variadic approach to allow for setting multiple consents at a time. However, I think this is overkill. Making separate API calls for each consent seems reasonable.

• All API examples provide the same format. However, in your example, you are suggesting we expose the Consents type. I don't think we should do this for a few reasons.

1. It includes metadata, which I've been told is not to be set by the customer, so we would require the customer to initialize Consents and understand the metadata field when it has no relevance to their use case.
2. The ergonimics of working with the Consents type aren't great. This is because it is modeled to fit the exact XDM schema. Instead, I propose we expose stripped-down types that only expose what the customer needs to know about. This improves the API usage by making it simpler and less verbose to set and read consents. I don't think the customer should be doing any merging of consents on their end, that's the responsibility of the Consent extension.

from aepsdk-edgeconsent-ios.