Closed 1280103995 closed 2 years ago
I will go back to the old version, these tests took me a long time.
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. 👍
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.
I retested version 1.1.3 and updated the problem description.
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.
I managed to install the pods now by running pod install --repo-update
as described in the docs.
Hi, @grifotv, i tried again, but the same error still occurs.
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)
~~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:
Change the function of
Iterable.js
online 370
to be asynchronously called. After the change, the implementation of 1 second delay for Android atline 337
is unnecessary.User realization