V1.1.3 bugs

[1280103995]

Today, I tried the new version to see if some of the previous bugs have been completely fixed, and then I encountered some problems.

~~On iOS, the build failed, this is the log: ~~ The solution is to use the old version of Iterable-iOS-AppExtensions. (Note: My Xcode version is 12.5)

target 'XXXXXX' do
  pod 'Iterable-iOS-AppExtensions', '6.3.3'
end

~~On iOS: The content of rich push is not displayed, which is probably the reason for using the old version of Iterable-iOS-AppExtensions.~~

Both platforms: 1. Inapp messages cannot be received on both platforms (the old version also has the same problem, it seems to be a server problem). 2. The action to open the notification is set to Open URL: https://www.iterable.com. But only started the app.

---

There is one on both platforms. That is, the SDK can accurately jump to the corresponding page when processing deep links. However, there may be a delay when the navigator processes the default path. Therefore, the deep link page is displayed first, and then the home page is displayed.

Process: Receive push message --> Click on the message --> Open the app and jump to the deep link page --> Jump to the homepage

The solution I thought of is: change the urlHandler method to an asynchronous call, so that the user can figure out when to return the result.

For example:

1. Change the function of Iterable.js on line 370 to be asynchronously called. After the change, the implementation of 1 second delay for Android at line 337 is unnecessary.

   async function callUrlHandler(url, context) {
   if ((await Iterable.savedConfig.urlHandler(url, context)) == false) {
       Linking.canOpenURL(url)
           .then(canOpen => {
           if (canOpen) {
               Linking.openURL(url);
           }
       })
           .catch(reason => { console.log("could not open url: " + reason); });
   }
   }

2. User realization

   config.urlHandler = async(url, context) => {
      const complete = this.appStartupComplete || await this.checkAppStartupComplete();
   
      //do somethings
      if (complete && url.match(/product\/([^\/]+)/i)) {
         this.navigate(match[1]);
         return true; // handled
      }
   
      return false;
   };

[1280103995]

I will go back to the old version, these tests took me a long time.

[Ayyanchira]

Hi @1280103995, thanks for trying out the new version and giving us feedback.

The solution is to use the old version of extension. (Note: My Xcode version is 12.5)

Will check on this one. 👍

in-app messages cannot be received on both platforms (the old version also has the same problem, it seems to be a server problem).

In Apps never had a problem in my tests; even in previous versions. Can you specify what device model and Android/iOS versions you are using? Also, is the Firebase and APNS settings configured properly? And also, is/are there other libraries relying on Firebase?

The solution I thought of is: change the urlHandler method to an asynchronous call, so that the user can figure out when to return the result.

That is a great idea. 👍

[1280103995]

Hi @1280103995, thanks for trying out the new version and giving us feedback.

The solution is to use the old version of extension. (Note: My Xcode version is 12.5)

Will check on this one. 👍

in-app messages cannot be received on both platforms (the old version also has the same problem, it seems to be a server problem).

In Apps never had a problem in my tests; even in previous versions. Can you specify what device model and Android/iOS versions you are using? Also, is the Firebase and APNS settings configured properly? And also, is/are there other libraries relying on Firebase?

The solution I thought of is: change the urlHandler method to an asynchronous call, so that the user can figure out when to return the result.

That is a great idea. 👍

The problem of not receiving in-app messages is my fault. When creating the event, the expiration date used the default value (I don't know why iterable chose a date in the past as the default value?), here must fill in a future time.

On iOS, viewing the rich push content changed from clicking "view" to long-pressing the notification.

I will test 1.1.3 again.

[1280103995]

I retested version 1.1.3 and updated the problem description.

[grifotv]

I'm able to install version v1.1.3 but have this error when trying to install the pods:

[!] CocoaPods could not find compatible versions for pod "Iterable-iOS-SDK":
  In Podfile:
    Iterable-React-Native-SDK (from `../node_modules/@iterable/react-native-sdk`) was resolved to 1.1.3, which depends on
      Iterable-iOS-SDK (~> 6.3.4)

None of your spec sources contain a spec satisfying the dependency: `Iterable-iOS-SDK (~> 6.3.4)`.

You have either:
 * out-of-date source repos which you can update with `pod repo update` or with `pod install --repo-update`.
 * mistyped the name or version.
 * not added the source repo that hosts the Podspec to your Podfile.

I can see that the Iterable-iOS-SDK v6.3.4 was released and is correctly defined as a dependency. When looking for it in the CocoaPods website, I see version 6.3.3 as the latest version in the search page, and in the detail page I see version 6.3.4. It makes me think there's something wrong in the CocoaPods servers potentially.

@1280103995 I'm wondering if you faced the same Pods error.

[grifotv]

I managed to install the pods now by running pod install --repo-update as described in the docs.

[1280103995]

Hi, @grifotv, i tried again, but the same error still occurs.