Migrating to SDK 10.8.X

For Application/Adapter written in Objective-C

1. Import of sub-modules such as InMobi.IMBanner (or InMobi.IMSdk):

   Issue: Compilation error “No submodule named 'IMSdk' in module 'InMobiSDK'; did you mean 'Swift'?"

   Reason: The notion of sub-modules is not supported in Swift by default.

   Solution: Replace (@import InMobiSDK.IMBanner;) with (@import InMobiSDK;).

   Note

   This is also applicable to any other submodule (such as InMobiSDK.IMSdk, InMobiSDK.IMBannerDelegate...). Notes: This is also applicable if you have a line such as (#import <InMobiSDK/IMBanner.h>). In this case, you will also need to replace it with (@import InMobiSDK;).

2. Usage of Constants such as IM_GDPR_CONSENT_AVAILABLE:

   Issue: Compilation error “Use of undeclared identifier IM_GDPR_CONSENT_AVAILABLE.

   Solution: Replace IM_GDPR_CONSENT_AVAILABLE with IMCommonConstants. IM_GDPR_CONSENT_AVAILABLE.

   Note

   All these constants are now available under the class IMCommonConstants. Other constants that are now static members of IMCommonConstants class:

   • IM_GDPR_CONSENT_AVAILABLE
   • IM_GDPR_CONSENT_IAB
   • IM_SUBJECT_TO_GDPR
   • IM_PARTNER_GDPR_CONSENT_AVAILABLE
   • IM_PARTNER_GDPR_APPLIES

3. Usage of Enum values with Objective-C (k) notation:

   Issue: Compilation error “Use of undeclared identifier kIMSDKLogLevelDebug, did you mean IMSDKLogLevelDebug?"

   XCode Suggestion: Replace kIMSDKLogLevelDebug with IMSDKLogLevelDebug

   Solution: Please accept the fix suggested by the XCode editor.

   Note

   This applies to the usage of any other constant with objective-C ‘k’ notation. kIMSDKAgeGroupBelow18, kIMSDKEducationHighSchoolOrLess, kIMSDKGenderMale can all be corrected using the same approach. The complete list of the Enums that may be present in your application includes: IMSDKGender, IMSDKEducation, and IMSDKAgeGroup.

4. Methods showFromViewContoller for IMInterstitial class:

   Issue: There are two overloaded versions of this method, and both will give you a compilation error.

   Solution: Please accept changes suggested by the XCode Code Completion feature.

   Example 1: Replace the older with, the newer:

Older:

[self.interstitial showFromViewController: self];

Newer:

[self.interstitial showFrom: self];

Example 2: Replace the older with the newer:

Older:

[self.interstitial showFromViewController:self withAnimation: kIMInterstitialAnimationTypeCoverVertical];

Newer:

[self.interstitial showFrom:self with:IMInterstitialAnimationTypeCoverVertical];

5. Linking errors for pure Objective-C application:

   Issue: If you have a pure objective-C application (without a single Swift file), then you will get a lot of linking errors such as:

   Undefined symbol:  _OBJC_CLASS_$__TtCs12_SwiftObject

   Undefined symbol: value witness table for () and so on. This is because InMobi SDK is a statically linked framework, and your application cannot find the path for the swift libraries.

   Solution: There are two solutions to fix these linking errors:

   Solution 1: Please add an empty dummy swift file to your project. When you do that, the XCode editor will ask if it should generate the auto bridging header; select yes. The net effect of this will be that the swift compiler can find the location of required swift libraries hence fixing all the link issues.

   This can be done as follows:

   1. In the XCode, select File NewFile option.
   2. Select iOS Swift File option. Click Next.
   3. Give any name you like (e.g., dummy.swift) and ensure that this file is being added to the correct target (in case you have multiple targets in your project)
   4. Select Create. Then Select “Create Bridging header”.
   5. Build your project.

   
   Solution 2: Please carefully select your target (from the project) in XCode and go to
   Build Settings Search Paths Library Search paths and the following two entries:

   • $(SDKROOT)/usr/lib/swift
   • $(TOOLCHAIN_DIR)/usr/lib/swift/$(PLATFORM_NAME)

   Again, the compiler will be able to find the location of swift libraries resulting in fixing the linking errors.

For Application/Adapter written in Swift

1. Import sub-modules such as InMobi.IMBanner (or InMobi.IMSdk):

   Issue: Compilation error “No such module InMobiSDK.IMBanner”

   Reason: The notion of sub-modules is not supported in Swift by default.

   Solution: Replace (import InMobiSDK.IMBanner) with (import InMobiSDK).

   Note

   This applies to other submodules (e.g., InMobiSDK.IMSdk, InMobiSDK.IMBannerDelegate, and so on).

2. Use the Constants such as IM_GDPR_CONSENT_AVAILABLE.

   Issue: Compilation error “Cannot find 'IM_GDPR_CONSENT_AVAILABLE' in scope"

   Solution: Replace IM_GDPR_CONSENT_AVAILABLE with IMCommonConstants. IM_GDPR_CONSENT_AVAILABLE.

   Note

   All these constants are now available under the class IMCommonConstants. Other constants which are now static members of IMCommonConstants class:

   • IM_GDPR_CONSENT_AVAILABLE
   • IM_GDPR_CONSENT_IAB
   • IM_SUBJECT_TO_GDPR
   • IM_PARTNER_GDPR_CONSENT_AVAILABLE
   • IM_PARTNER_GDPR_APPLIES

3. Method primaryView of IMNative class

   Issue: Return type of this method is now optional. Hence, if you use this method, you must adjust the code to unwrap the method's return value.

   Solution: Manual code adjustment. You may want to add this subView to your master view ONLY if the returned value is non-nil.

   Example: If you have the following line in your source (older), change it to the newer.

Older:

self.contentView.addSubview(native.primaryView(ofWidth: aWidth))

Newer:

if let aView = native.primaryView(ofWidth: aWidth) { 
    self.contentView.addSubview(aView) 
}

4. Ad Object creation in source code:

   Issue: If you are creating Ads in source code, please note that all the 3 Ad constructors (IMBanner, IMInterstitial, and IMNative) now return non-optional instances.

   Solution: Please remove the code (if any) for unwrapping/optional binding of the instances returned by these Ad Constructors.

   Examples:

   • If you are using the “if let” construct, it is redundant now since the returned instance is no longer optional.
   • If you are trying optional chaining via “?.” notation, please update your source code and remove the usage of “?”. And you can access the member variables/methods without this chaining.

5. Rename to satisfy this requirement warning:

   Issue: Compilation warning(s). “Rename to ‘banner(_: didReceiveWithMetaInfo: )’ to satisfy this requirement

   Solution: In most cases, the fix (such as Rename) suggested by XCode is correct.

   Example: Source Line with warning

func banner(_ banner: IMBanner!, didReceiveWith info: IMAdMetaInfo!)

Source Line after accepting the code fix by XCode:

func banner(_ banner: IMBanner!, didReceiveWithMetaInfo info: IMAdMetaInfo!)

List of Renamed APIs:

func interstitial(_ interstitial: IMInterstitial!, didReceiveWithMetaInfo metaInfo: IMAdMetaInfo!) 
func userWillLeaveApplication(from banner: IMBanner!) 
func userWillLeaveApplication(from interstitial: IMInterstitial!) 
func userWillLeaveApplication(from native: IMNative!) 
func userDidSkipPlayingMedia(from native: IMNative!)

6. The difference in optionality of a parameter than expected by a protocol:

   Issue: Compilation warning(s): “Parameter of 'nativeDidFinishPlayingMedia' has different optionality than expected by protocol 'IMNativeDelegate”

   Solution: In most cases, the fix (such as remove!) suggested by XCode is correct.

   Example 1:

Source Line with a warning:

func nativeDidFinishLoading(_ native: IMNative!)

Source Line after accepting the code fix by XCode:

func nativeDidFinishLoading(_ native: IMNative)

Example 2:

Source Line with a warning:

func native(native: IMNative!, didFailToLoadWithError error: IMRequestStatus!)

Source Line after accepting the code fix by XCode:

func native(native: IMNative!, didFailToLoadWithError error: IMRequestStatus)

The instance method nearly matches the optional requirement of a protocol warning:

Issue: Compilation warning(s). “Instance method 'native(_:didInteractWithParams:)' nearly matches optional requirement 'native(_:didInteractWithParams:)' of protocol 'IMNativeDelegate' Solution: Please check the method in the respective delegate to see which parameter type is different and do the fix accordingly.

Example 1:

Source Line with a warning:

public func native(native: IMNative!, didInteractWithParams params: [AnyHashable: Any]!)

This method in IMNativeDelegate protocol is expecting params of type [String: Any]. Hence simply updating AnyHashable with String and removing the “!” In the method, the signature will fix the warning.

Correct source line after a manual change:

public func native(native: IMNative!, didInteractWithParams params: [String: Any])

Example 2:

Source Line with the warning:

func banner(_ banner: IMBanner!, didInteractWithParams params: [AnyHashable: Any]!)

If we check this method in IMBannerDelegate protocol, we can see that there are three differences:

• The “!” after the IMBanner type param needs to be removed.
• It is expecting params of type [String: Any] and not [AnyHashable, Any]
• It is expecting [AnyHashable, Any]? and no [AnyHashable, Any]!

Correct source line after the manual change:

func banner(_ banner: IMBanner, didInteractWithParams params: [String: Any]?)

List of Removed Methods

The following methods have been removed. Hence please stop using them.

IMBanner:

-(void)getSignals;

IMnterstitial:

-(void)getSignals;

IMBannerDelegate:

-(void)banner:(IMBanner*)banner gotSignals:(NSData*)signals;
 
-(void)banner:(IMBanner *)banner failedToGetSignalsWithError:      (IMRequestStatus*)status;

IMInterstitialDelegate:

-(void)interstitial:(IMInterstitial*)interstitial gotSignals:(NSData*)signals; 

-(void)interstitial:(IMInterstitial*)interstitial failedToGetSignalsWithError:(IMRequestStatus*)status;

Replacement: Use [IMSdk getToken] in place of the above methods