Release v3.1.0 #297
Release v3.1.0 #297
Conversation
- Adds new MT related APIs - Deprecates older methods - Updates versions - Updates CHANGELOG.md
- Removes deprecated function calls - Adds new buttons to testing new MT APIs
- Makes view collapsible - Adds a reusable component
- Adds ability to raise custom event and custom attributes for profileSet
- Supports CleverTap iOS SDK v7.1.0
* task(SDK-4406) - Revamps sample app - Makes view collapsible - Adds a reusable component * task(SDK-4406) - Revamps sample app - Adds ability to raise custom event and custom attributes for profileSet
* fix: flutter 3.29 drops android flutter embedding v1 (#289) * task(SDK-4421) - Adds support for flutter 3.29 - Updates workmanager dep compatible with flutter 3.29 - Updates changelog - Updates docs * task(SDK-4421) - Adds support for flutter 3.29 - Fixes changelog --------- Co-authored-by: Rodrigo Boratto <[email protected]>
- Fixes manifest file
…was called (#292) * task(SDK-4393) - Theoretical fix for NPE when onDetachedFromActivity was called * task(SDK-4393) - Fixes formatting
[SDK-4407] iOS Multi trigger support
Task/sdk 4406/support corev7.1.2
WalkthroughThis PR updates the clevertap_plugin to version 3.1.0. It upgrades both Android and iOS SDKs, replaces deprecated device-level event APIs with new user-level event log APIs, and adjusts plugin registration methods. The update also includes changes to application inheritance on Android, documentation modifications, and adjustments in dependency management and build configurations across Android, iOS, and example projects. Changes
Sequence Diagram(s)sequenceDiagram
participant F as Flutter
participant P as CleverTapPlugin (Native)
participant CT as CleverTapSDK
F->>P: Invoke getUserEventLog(eventName)
P->>CT: Request event log for eventName
CT-->>P: Return user event log data
P->>F: Respond with event log (as Map)
Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (11)
example/android/settings.gradle (1)
23-23: Plugin Declaration Consistency:
The new plugin declaration on line 23:id "org.jetbrains.kotlin.android" version "2.0.20" apply falseis functionally correct. However, for consistency with the other plugin declarations (which use the method-call style), consider refactoring it to:
- id "org.jetbrains.kotlin.android" version "2.0.20" apply false + id("org.jetbrains.kotlin.android").version("2.0.20").apply(false)This will maintain a uniform style in the plugins block.
example/pubspec.yaml (1)
27-31: Dependency Source Change – Workmanager:
The dependency forworkmanagerhas been updated from a version constraint to a Git-based declaration:workmanager: git: url: https://github.com/fluttercommunity/flutter_workmanager.git path: workmanager ref: mainThis change should be verified for stability and caching behavior. Also, ensure that any functionality previously provided by the removed
open_filedependency is no longer necessary or has been replaced.CHANGELOG.md (1)
15-31: Markdown Formatting Suggestion:
Static analysis indicates several markdown lint issues (MD004) regarding unordered list styles. For improved consistency and adherence to markdown guidelines, consider replacing the dashes-used for list items with asterisks*. For example:- - Adds support for triggering InApps based on first-time event filtering... + * Adds support for triggering InApps based on first-time event filtering...This change is purely stylistic but can improve overall readability and compliance with markdown standards.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
15-15: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
16-16: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
17-17: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
18-18: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
19-19: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
20-20: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
21-21: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
23-23: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
24-24: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
25-25: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
26-26: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
27-27: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
28-28: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
29-29: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
30-30: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
31-31: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
android/src/main/java/com/clevertap/clevertap_plugin/Utils.java (1)
96-109: Introduced eventLogToMap method
This method cleanly convertsUserEventLogdata into aMap. Consider adding null checks for fields likeeventNameordeviceIDto avoid potential runtime exceptions.example/lib/main.dart (7)
242-242: Prevent potential file path exposure.
If the returned file path contains private or sensitive data, consider masking or removing it before displaying it to the user.
473-506: Consider refactoring dialogs to reduce duplication.
You can unify single-input and multiple-input dialogs or extract common logic to a helper method.
508-554: Similar dialog structure could be merged.
Merging this dialog with the single-input version helps maintain DRY principles.
559-752: Large build method.
Breaking this into smaller widgets or separate methods enhances maintainability and readability.
919-922: Optional validation for empty eventName.
Consider validating or handling empty event names before recording the event.
988-994: Handle incomplete or null attributes.
IfattributeKeyorattributeValueis empty, it might lead to unintended profile overwrites. Consider basic checks.
1418-1429: Random identity could collide.
UsingRandom()for login identity is fine for testing, but consider more robust generation for production.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
example/ios/Podfile.lockis excluded by!**/*.lock
📒 Files selected for processing (20)
CHANGELOG.md(1 hunks)README.md(1 hunks)android/build.gradle(2 hunks)android/src/main/java/com/clevertap/clevertap_plugin/CleverTapApplication.java(1 hunks)android/src/main/java/com/clevertap/clevertap_plugin/CleverTapPlugin.java(4 hunks)android/src/main/java/com/clevertap/clevertap_plugin/DartToNativePlatformCommunicator.kt(10 hunks)android/src/main/java/com/clevertap/clevertap_plugin/Utils.java(3 hunks)doc/Integrate-Android.md(1 hunks)example/android/app/src/main/AndroidManifest.xml(0 hunks)example/android/app/src/main/java/com/example/clevertap_plugin_example/EmbeddingV1Activity.java(0 hunks)example/android/settings.gradle(1 hunks)example/ios/Runner.xcodeproj/project.pbxproj(8 hunks)example/lib/main.dart(14 hunks)example/pubspec.yaml(1 hunks)ios/Classes/CleverTapPlugin.m(6 hunks)ios/Classes/CleverTapPluginAppFunctionPresenter.h(1 hunks)ios/Classes/CleverTapPluginTemplatePresenter.h(1 hunks)ios/clevertap_plugin.podspec(2 hunks)lib/clevertap_plugin.dart(5 hunks)pubspec.yaml(1 hunks)
💤 Files with no reviewable changes (2)
- example/android/app/src/main/java/com/example/clevertap_plugin_example/EmbeddingV1Activity.java
- example/android/app/src/main/AndroidManifest.xml
✅ Files skipped from review due to trivial changes (2)
- README.md
- pubspec.yaml
🧰 Additional context used
🪛 markdownlint-cli2 (0.17.2)
CHANGELOG.md
3-3: Heading style
Expected: atx; Actual: setext
(MD003, heading-style)
5-5: Emphasis used instead of a heading
null
(MD036, no-emphasis-as-heading)
15-15: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
16-16: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
17-17: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
18-18: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
19-19: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
20-20: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
21-21: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
23-23: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
24-24: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
25-25: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
26-26: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
27-27: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
28-28: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
29-29: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
30-30: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
31-31: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
🔇 Additional comments (69)
ios/Classes/CleverTapPluginAppFunctionPresenter.h (1)
3-7: Good approach for ensuring compatibility with different SDK integration methods.The addition of
__has_includeconditional compilation is a best practice that provides flexibility when including the CleverTap SDK. This approach correctly handles both framework/CocoaPods installations (where header files are in angle brackets) and local header files.This change supports the update to CleverTap iOS SDK v7.1.0 mentioned in the PR while maintaining backward compatibility.
android/src/main/java/com/clevertap/clevertap_plugin/CleverTapApplication.java (1)
11-11: Good migration from Flutter-specific to standard Android application class.Changing from
FlutterApplicationto standard AndroidApplicationis a positive architectural shift that:
- Reduces coupling to Flutter-specific implementation details
- Aligns with the removal of deprecated Embedding v1 support mentioned in the PR
- Makes the code more adaptable to different integration scenarios
The core functionality as a
CTPushNotificationListeneris preserved properly.Also applies to: 13-13
ios/Classes/CleverTapPluginTemplatePresenter.h (1)
9-13: Consistent implementation of SDK header inclusion logic.The conditional compilation approach for header inclusion matches the pattern implemented in
CleverTapPluginAppFunctionPresenter.h, maintaining consistency across the codebase.This provides flexibility for different SDK integration methods while supporting the update to CleverTap iOS SDK v7.1.0.
ios/clevertap_plugin.podspec (2)
6-6: Version number correctly updated for the 3.1.0 release.The podspec version has been properly incremented to match the overall release version in the PR title.
16-16:❓ Verification inconclusive
SDK dependency correctly updated to latest compatible version.
The update to CleverTap iOS SDK 7.1.0 aligns with the PR objective to update SDK versions and replace deprecated APIs with new user-centric event log methods.
🏁 Script executed:
#!/bin/bash # Description: Verify this is the latest stable CleverTap iOS SDK version # Check for the latest version of CleverTap iOS SDK on CocoaPods curl -s https://raw.githubusercontent.com/CocoaPods/Specs/master/Specs/4/d/c/CleverTap-iOS-SDK/7.1.0/CleverTap-iOS-SDK.podspec.json | jq '.name, .version' # Check if there are newer versions available curl -s "https://api.cocoapods.org/api/v1/pods/CleverTap-iOS-SDK/versions" | jq '.versions | sort_by(.created_at) | reverse | .[0:3] | .[] | .name, .created_at'Length of output: 381
Action: Please manually verify the latest CleverTap-iOS-SDK version.
The dependency update in
ios/clevertap_plugin.podspecto version 7.1.0 appears to meet the PR objective. However, the automated version check via CocoaPods did not yield the expected output (the JSON parsing error prevented confirmation). Kindly verify manually—via CocoaPods or another trusted source—that 7.1.0 is indeed the latest stable and compatible version before finalizing the change.
- File affected:
ios/clevertap_plugin.podspec(line 16)- Current dependency:
s.dependency 'CleverTap-iOS-SDK', '7.1.0'- Verification needed: Confirm that version 7.1.0 is the most recent stable release supporting the new user-centric event log methods, as outlined in the PR.
android/build.gradle (2)
2-2: Version Update Confirmation:
The version has been correctly bumped to'3.1.0'on line 2. Please ensure that all modules and dependencies referencing this plugin version are updated accordingly.
59-62: SDK Dependency Upgrade:
The CleverTap Android SDK dependency is updated to version'7.1.2'on line 61. Confirm that this new SDK version is fully compatible with your project and that any breaking changes in the SDK have been properly handled.doc/Integrate-Android.md (1)
55-61: Application Class Update:
The change from extendingFlutterApplicationto extending the more generalApplication(as seen on line 55) is appropriate given the updated integration approach. Make sure that any related documentation or usage guides are updated to reflect this architectural change.example/pubspec.yaml (1)
14-14: Version Consistency Check:
The example’s version remains set as1.0.0+1on line 14 despite the plugin version bump in other files. Please verify if this is intentional for the example project or if it needs to be updated to maintain consistency with the overall3.1.0release.CHANGELOG.md (1)
3-10: Changelog Version Entry:
The new version entry for 3.1.0 (lines 3–10) is comprehensive and well-documented, outlining the new features and upgrades. This level of detail will help users understand the changes in this release.🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
3-3: Heading style
Expected: atx; Actual: setext(MD003, heading-style)
5-5: Emphasis used instead of a heading
null(MD036, no-emphasis-as-heading)
example/ios/Runner.xcodeproj/project.pbxproj (10)
19-19: Ensure correct reference ID
This updated PBXBuildFile referenceslibPods-Runner.awith a new ID. Verify that it matches the file reference ID in the PBXFileReference section to avoid linking issues.
40-40: Check existence of new debug config
Ensure"Pods-Runner.debug.xcconfig"is correctly placed under"Target Support Files/Pods-Runner"and that the file is tracked by your build system.
44-44: New ‘libPods-Runner.a’ reference
TheexplicitFileTypeis set to"archive.ar". This is typically correct for static libraries. Ensure the file is generated as expected.
45-45: Check existence of new release config
Make sure"Pods-Runner.release.xcconfig"is present and properly configured for your release build settings.
49-49: Profile config reference
A new"Pods-Runner.profile.xcconfig"file is referenced here. Confirm that you have a matching file for profiling build configurations.
66-66: Link library in Frameworks Build Phase
The addition oflibPods-Runner.ahere ensures linking with the Pod-provided static library. This looks consistent; proceed with caution on library duplication.
76-78: Updated references to pod config files
The group now includes the new debug, release, and profile xcconfig references. Ensure these files exist and are included in your Pod installation to avoid build issues.
88-88: Additional library reference
libPods-Runner.ais also referenced in the Frameworks group. Redundant references can cause duplication or confusion, but it may be needed for certain build phases. Confirm that it’s only added where necessary.
156-156: Updated Pod check build phase
This new ID references the shell script build phase for validating yourPodfile.lock. Ensure any references to the old ID are removed to prevent duplication.
163-163: New [CP] Copy Pods Resources phase
This additional build phase ensures the Pods resources are correctly copied. No issues observed.android/src/main/java/com/clevertap/clevertap_plugin/Utils.java (4)
12-12: New import for UserEventLog
This import is necessary for newly introduced user-level event log functionality.
83-83: Added @deprecated annotation
Marking this method as deprecated is a clear signal for future removal. Ensure that the codebase has an updated alternative.
111-119: New historyEventLogToMap method
This method iterates the provided map ofUserEventLogobjects to produce a mapped structure. It's consistent with theeventLogToMapapproach and handles null input gracefully.
121-121: Deprecated historyEventDetailToMap
Similar toeventDetailToMap, this reflects a shift toward the new user-centric event tracking approach. Maintain references until it’s safe to remove fully.android/src/main/java/com/clevertap/clevertap_plugin/CleverTapPlugin.java (8)
63-66: Null check before clearing activity
This additional check preventsNullPointerExceptionwhen detaching from the activity. Good job ensuring robust lifecycle handling.
79-82: Similar null check on reattachment
Consistent approach for detaching theActivityreference. Helps avoid memory leaks during configuration changes.
88-88: Simplified onAttachedToEngine callback
ThesetupPlugincall now uses thebinding.getBinaryMessenger()approach, eliminating the older Registrar-based registration.
103-103: Use of BinaryMessenger
Replacing the older approach fosters better integration with Flutter's newer plugin APIs.
105-105: Obtain dartToNativeMethodChannel
A dedicated channel for Dart-to-Native communication improves clarity and maintainability in message handling.
109-109: Assign lastNativeToDartMethodChannel
Storing the channel in a set prevents concurrency issues with multiple isolates. Good strategy for isolate-based messaging.
122-122: New getMethodChannel signature
Removes the older plugin-embedding logic in favor of a simpler approach using theBinaryMessenger.
126-126: Return new MethodChannel
Straightforward instantiation streamlines the code, fully embracing the newer V2 embedding patterns.ios/Classes/CleverTapPlugin.m (6)
314-323: Well-implemented additions for user-centric event logging.The addition of these new method handlers in the
handleMethodCall:result:function properly supports the shift from device-level to user-level event tracking in version 3.1.0. The method names are clear and follow the established pattern of other handlers in this file.
488-505: Properly implemented user event log methods.These methods correctly retrieve user event logs and history using the CleverTap SDK's native functionality. The implementation follows the same pattern as the existing event-related methods, maintaining consistency in the codebase.
507-511: Clean implementation of getUserEventLogCount method.This method properly retrieves the count of a specific user event and returns it to the Flutter side. Error handling is consistent with other similar methods in the file.
607-611: Good implementation of getUserAppLaunchCount method.This method correctly retrieves the app launch count from the CleverTap SDK. The implementation is concise and follows the established pattern in the file.
625-629: Properly implemented getUserLastVisitTs method.This method correctly retrieves the timestamp of the user's last visit. The implementation is consistent with other similar methods in the file.
1000-1003: Enhanced event detail dictionary with additional fields.The
_eventDetailToDict:method has been appropriately updated to includenormalizedEventNameanddeviceIDfields, providing more comprehensive event data to the Flutter side. This enhancement supports the new user-centric event tracking functionality.Also applies to: 1017-1019
android/src/main/java/com/clevertap/clevertap_plugin/DartToNativePlatformCommunicator.kt (6)
16-16: Appropriate import for UserEventLog class.The import of the UserEventLog class is necessary for the new user-centric event logging functionalities being added.
68-69: Good addition of KEY_EVENT_NAME constant.Adding this constant for event name parameter improves code maintainability and reduces the risk of typos when referencing the event name parameter throughout the code.
248-264: Well-structured implementation of new method handlers.The addition of these new method handlers in the
onMethodCallfunction properly supports user-centric event logging. The method names are clear and consistent with their iOS counterparts, maintaining cross-platform compatibility.
1217-1256: Comprehensive implementation of user event log methods.These methods are implemented correctly, with proper error handling and null checks. They provide the Flutter side with access to the CleverTap SDK's user-centric event logging capabilities, aligning with the shift from device-level to user-level tracking in version 3.1.0.
1258-1259: Properly deprecated older event tracking methods.The @deprecated annotations on these methods clearly indicate that they're being replaced by the new user-centric event logging methods. The deprecation messages include the version information ("Since v3.1.0"), which helps developers understand when to migrate to the new APIs.
Also applies to: 1269-1270, 1279-1280, 1289-1290, 1380-1381, 1784-1785, 1809-1810
16-16:❓ Verification inconclusive
Verify that UserEventLog conversion to map works correctly.
The implementation of
getUserEventLogandgetUserEventLogHistoryrelies on theUtils.eventLogToMapandUtils.historyEventLogToMapmethods to convert UserEventLog objects to maps that can be passed to Flutter. Make sure these utility methods include all relevant fields from the UserEventLog class.Also applies to: 1217-1256
🏁 Script executed:
#!/bin/bash # Description: Check the implementation of event log mapping methods in Utils.kt # Search for eventLogToMap in Utils.kt echo "Looking for eventLogToMap method implementation:" rg -A 20 "eventLogToMap" --type kotlin # Search for historyEventLogToMap in Utils.kt echo "Looking for historyEventLogToMap method implementation:" rg -A 20 "historyEventLogToMap" --type kotlin # Check how UserEventLog class is structured (fields) echo "Looking for UserEventLog class structure:" rg -A 10 "class UserEventLog" --type kotlinLength of output: 5561
Attention: Verify Mapping Completeness for UserEventLog Conversion
I reviewed the relevant invocations of the utility methods in
DartToNativePlatformCommunicator.ktand confirmed that bothUtils.eventLogToMapandUtils.historyEventLogToMapare being called as expected. However, the actual implementations of these methods—and thus the details of how fields from the externalUserEventLog(from CleverTap SDK) are mapped—weren’t located within our repository search results. Please ensure that:
Utils.eventLogToMap()correctly converts all pertinent fields of theUserEventLogobject.Utils.historyEventLogToMap()fully covers the necessary fields for the user event log history.- Any updates to the CleverTap SDK’s
UserEventLogstructure are reflected in these utility methods.Manually verify that the mapping implementation includes all relevant fields from the
UserEventLogclass to avoid missing information when sent to Flutter.example/lib/main.dart (12)
4-4: Good import usage.
This new import ofdart:mathis appropriate for generating random values.
428-435: Push AMP payload handling looks correct.
Implementation properly converts the payload to JSON and creates a notification.
437-441: Verify null or malformed payload handling.
Please confirm that the notification payload has the required keys or handle null data gracefully.
443-446: Simple boolean handling is fine.
The code for push permission response is straightforward and clear.
448-471: UI helper pattern is well-structured.
Using an ExpansionTile within a Card improves readability for grouped UI sections.
1299-1308: Retrieving first event time is properly implemented.
Implementation aligns well with the new user event log methods.
1312-1323: Fetching last event time is consistent.
No issues found; logic follows the updated API calls.
1325-1337: Retrieve event count logic is sound.
Null checks and method usage are properly handled.
1339-1350: Fetching event log details seems correct.
Straightforward usage of the newgetUserEventLogmethod.
1353-1357: Event history retrieval is aligned with the new approach.
No issues with callinggetUserEventLogHistory().
1492-1504: User app launch count retrieval is straightforward.
Method invocation and result handling are fine.
1520-1526: User last visit time retrieval matches new APIs.
Implementation is consistent and correct.lib/clevertap_plugin.dart (13)
77-77: Version increment looks correct.
SettinglibVersionto 30100 aligns with the 3.1.0 release.
688-693: Deprecation note is appropriate.
MarkingeventGetFirstTimeas deprecated in favor of the new method is clear.
695-700: Deprecated method references are consistent.
eventGetLastTimecorrectly points to the updated approach.
702-707: Clear shift togetUserEventLogCount.
eventGetOccurrencesis suitably deprecated in favor of user-centric logging.
709-716: Deprecation details remain consistent with refactoring.
eventGetDetailis now replaced bygetUserEventLog.
718-724: Reference togetUserEventLogHistoryis correct.
Deprecation message forgetEventHistoryis accurate.
726-731: NewgetUserEventLogmethod.
Properly returns aMap<String, dynamic>and casts safely.
733-737: Method for event count is well-defined.
Returns an integer count for the specific event.
739-744: Method for retrieving user event log history.
Implementation is aligned with user-level logs.
746-750: User-specific app launch count.
Clearly implements the new user-centric approach.
752-756: Captures user's last visit timestamp.
Method name and logic are straightforward.
918-923: sessionGetTotalVisits properly deprecated.
Directs users to the newergetUserAppLaunchCount.
931-936: Deprecated sessionGetPreviousVisitTime.
PromotesgetUserLastVisitTsfor a user-focused approach.
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
lib/clevertap_plugin.dart (1)
76-1401: 💡 Verification agent🧩 Analysis chain
Verify integration impact across the Flutter application
While the API changes are well-structured, it's important to verify that any existing code using the deprecated methods is updated to use the new ones to avoid potential issues after the upgrade.
You may want to update your documentation and provide a migration guide for developers who need to update their code.
Suggest running the following script to identify any usages of deprecated methods in the example code or tests:
🏁 Script executed:
#!/bin/bash # Check for usages of deprecated methods in the example code and tests echo "Checking for usages of deprecated methods..." # Array of deprecated methods deprecated_methods=( "eventGetFirstTime" "eventGetLastTime" "eventGetOccurrences" "eventGetDetail" "getEventHistory" "sessionGetTotalVisits" "sessionGetPreviousVisitTime" ) # Check example code echo "Checking example code..." for method in "${deprecated_methods[@]}"; do echo "Checking for $method..." rg "$method" example/ -t dart done # Check tests echo "Checking tests..." for method in "${deprecated_methods[@]}"; do echo "Checking for $method..." rg "$method" test/ -t dart done echo "Check complete."Length of output: 4977
Update Deprecated API Usages and Documentation
The API changes look solid overall, but the verification shows that several deprecated methods are still in use in both the example app and tests. Please update these deprecated calls to use the new API methods and adjust the documentation/migration guide accordingly. In particular:
example/lib/main.dart
- The deprecated method
getEventHistoryis used—please migrate this to the recommended alternative.test/clevertap_plugin_test.dart
- Deprecated methods such as
eventGetFirstTime,eventGetLastTime,eventGetOccurrences,eventGetDetail,getEventHistory,sessionGetTotalVisits, andsessionGetPreviousVisitTimeare still being tested. Update these tests to use the new API calls (for example, switching togetUserEventLogwhere applicable).Documentation
- Provide a migration guide detailing the conversion from deprecated methods to the new ones so that developers can update their code without issues.
🧹 Nitpick comments (3)
doc/Integrate-Android.md (1)
52-62: Consider adding note about Application inheritance change.While the sample code has been updated correctly, it would be helpful to add a brief note explaining the change from
FlutterApplicationtoApplicationfor developers who are upgrading from previous versions.} ``` +> **Note:** CleverTap Flutter SDK v3.1.0 and above uses standard Android `Application` class instead of `FlutterApplication` as the base class. + #### Note🧰 Tools
🪛 LanguageTool
[uncategorized] ~52-~52: A comma might be missing here.
Context: ...`` - In your app's Android Application class add the following code. ```java ...(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
android/src/main/java/com/clevertap/clevertap_plugin/DartToNativePlatformCommunicator.kt (1)
1217-1257: New helper methods for user-level event tracking
The newly introduced methods (e.g.,getUserEventLog,getUserEventLogCount) gracefully check for null references and return results via the FlutterMethodChannel.Result.
- Minor note: Consider adding a check for empty
eventNameto provide a more descriptive error or fallback. Currently, onlynullis handled explicitly.lib/clevertap_plugin.dart (1)
688-756: Consistent transition from device-level to user-level event APIsThe changes consistently shift from device-level event APIs to user-level event logging APIs, with proper deprecation notices and new replacement methods. This reflects a well-planned API evolution strategy, making it clear to developers which new methods to use.
However, consider adding documentation comments to the new methods similar to those on the deprecated methods to improve developer experience.
Consider adding descriptive documentation comments to the new methods to match the style of the deprecated methods. For example:
+/// Returns a Map object for the particular event passed. UserEventLog consists of eventName, normalizedEventName, count, deviceID, firstTime and lastTime timestamp of the event. static Future<Map<String, dynamic>> getUserEventLog(String eventName) async { Map<dynamic, dynamic> response = await _dartToNativeMethodChannel .invokeMethod('getUserEventLog', {'eventName': eventName}); return response.cast<String, dynamic>(); } +/// Returns the total count of the specified event static Future<int?> getUserEventLogCount(String eventName) async { return await _dartToNativeMethodChannel .invokeMethod('getUserEventLogCount', {'eventName': eventName}); } +/// Returns a Map of event names and corresponding UserEventLog of all the events raised static Future<Map<String, dynamic>> getUserEventLogHistory() async { Map<dynamic, dynamic> response = await _dartToNativeMethodChannel .invokeMethod('getUserEventLogHistory', {}); return response.cast<String, dynamic>(); } +/// Returns the total number of times user has launched the app static Future<int?> getUserAppLaunchCount() async { return await _dartToNativeMethodChannel .invokeMethod('getUserAppLaunchCount', {}); } +/// Returns the timestamp of user's last app visit static Future<num?> getUserLastVisitTs() async { return await _dartToNativeMethodChannel .invokeMethod('getUserLastVisitTs', {}); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
example/ios/Podfile.lockis excluded by!**/*.lock
📒 Files selected for processing (20)
CHANGELOG.md(1 hunks)README.md(1 hunks)android/build.gradle(2 hunks)android/src/main/java/com/clevertap/clevertap_plugin/CleverTapApplication.java(1 hunks)android/src/main/java/com/clevertap/clevertap_plugin/CleverTapPlugin.java(4 hunks)android/src/main/java/com/clevertap/clevertap_plugin/DartToNativePlatformCommunicator.kt(10 hunks)android/src/main/java/com/clevertap/clevertap_plugin/Utils.java(3 hunks)doc/Integrate-Android.md(1 hunks)example/android/app/src/main/AndroidManifest.xml(0 hunks)example/android/app/src/main/java/com/example/clevertap_plugin_example/EmbeddingV1Activity.java(0 hunks)example/android/settings.gradle(1 hunks)example/ios/Runner.xcodeproj/project.pbxproj(8 hunks)example/lib/main.dart(14 hunks)example/pubspec.yaml(1 hunks)ios/Classes/CleverTapPlugin.m(6 hunks)ios/Classes/CleverTapPluginAppFunctionPresenter.h(1 hunks)ios/Classes/CleverTapPluginTemplatePresenter.h(1 hunks)ios/clevertap_plugin.podspec(2 hunks)lib/clevertap_plugin.dart(5 hunks)pubspec.yaml(1 hunks)
💤 Files with no reviewable changes (2)
- example/android/app/src/main/AndroidManifest.xml
- example/android/app/src/main/java/com/example/clevertap_plugin_example/EmbeddingV1Activity.java
✅ Files skipped from review due to trivial changes (2)
- README.md
- pubspec.yaml
🧰 Additional context used
🪛 markdownlint-cli2 (0.17.2)
CHANGELOG.md
3-3: Heading style
Expected: atx; Actual: setext
(MD003, heading-style)
5-5: Emphasis used instead of a heading
null
(MD036, no-emphasis-as-heading)
15-15: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
16-16: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
17-17: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
18-18: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
19-19: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
20-20: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
21-21: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
23-23: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
24-24: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
25-25: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
26-26: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
27-27: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
28-28: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
29-29: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
30-30: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
31-31: Unordered list style
Expected: asterisk; Actual: dash
(MD004, ul-style)
🔇 Additional comments (80)
example/ios/Runner.xcodeproj/project.pbxproj (9)
19-19: Library reference updated correctly.The reference to libPods-Runner.a has been updated with a new identifier, which is required for proper library linking in the updated version.
40-40: Configuration files properly updated for all build configurations.The Pods-Runner configuration files (debug, release, profile) have been correctly referenced with proper includeInIndex properties and paths, ensuring that all build configurations will work correctly with the new SDK version.
Also applies to: 45-45, 49-49
44-44: Library file reference properly defined.The explicit file type and includeInIndex properties have been correctly added for the libPods-Runner.a file reference, which is important for proper integration with the build system.
66-66: Framework reference correctly updated.The reference to libPods-Runner.a in the Frameworks build phase has been properly updated to use the new identifier, ensuring correct library linking during build.
76-78: Pod configuration files properly organized in groups.The Pods group children have been correctly updated to include all necessary configuration files for different build types (debug, release, profile).
88-88: Framework reference properly updated in Frameworks group.The reference to libPods-Runner.a in the Frameworks group has been correctly updated to the new identifier.
156-156: Build phase correctly configured for Pod manifest checking.The "[CP] Check Pods Manifest.lock" build phase has been properly set up with the correct identifier, which is essential for dependency validation during builds.
163-163: Resource copying build phase added correctly.The "[CP] Copy Pods Resources" build phase has been added to the build phases, which is necessary to include resources from the CleverTap SDK in the app bundle.
238-254: Pod resources copy script properly configured.This new shell script build phase has been correctly added with:
- Proper input and output file list paths
- Correct shell path and script reference
- Environment variable configuration
This ensures that all resources from the CleverTap SDK will be correctly copied into the final application bundle.
example/android/settings.gradle (1)
23-23: Version upgrade for Kotlin Android plugin looks good.The addition of the explicit Kotlin plugin version makes the build configuration more precise and aligns with the overall update to CleverTap Flutter plugin v3.1.0.
android/src/main/java/com/clevertap/clevertap_plugin/CleverTapApplication.java (1)
11-13:✅ Verification successful
Architectural change from FlutterApplication to Application is appropriate.
Changing from
FlutterApplicationto standard AndroidApplicationdecouples the CleverTap implementation from Flutter-specific dependencies, making the code more maintainable and reducing reliance on Flutter's internal architecture. This approach is better aligned with modern Android development practices.
🏁 Script executed:
#!/bin/bash # Verify this change won't affect other parts of the codebase that might expect FlutterApplication rg -p "FlutterApplication" --glob "**/*.java" --glob "**/*.kt" # Check for any references to methods or properties specific to FlutterApplication that might now be missing rg -p "CleverTapApplication" --glob "**/*.java" --glob "**/*.kt" -A 5 -B 5Length of output: 1305
Architectural Update Confirmed: Transition from FlutterApplication to Application is Safe
The verification confirms that:
- There are no remaining references to
FlutterApplicationanywhere in the Java or Kotlin code.- The usage of
CleverTapApplication(extended inMyApplication) continues to work as expected.The change decouples CleverTap from Flutter-specific dependencies without affecting any downstream consumers. The snippet now correctly shows:
import android.app.Application; public class CleverTapApplication extends Application implements CTPushNotificationListener {Everything appears correct and no further modifications are necessary.
ios/Classes/CleverTapPluginTemplatePresenter.h (1)
9-13: Robust conditional import implementation added.The conditional import check using
__has_includeis a best practice for handling framework vs. local imports. This makes the plugin more resilient to different installation methods (CocoaPods vs. manual) and packaging scenarios.doc/Integrate-Android.md (1)
55-55: Documentation updated to align with implementation changes.The documentation correctly reflects the architectural change from
FlutterApplicationtoApplicationin the Android integration guide, ensuring consistency between code and documentation.ios/Classes/CleverTapPluginAppFunctionPresenter.h (1)
3-7: Enhanced SDK import flexibility with conditional compilation!The addition of conditional compilation for the
CTTemplatePresenter.himport improves the plugin's robustness across different integration scenarios. This approach correctly handles both framework-based and direct file imports, making the plugin more adaptable to various project configurations.android/build.gradle (2)
2-2: Version updated to 3.1.0 correctlyThis version bump aligns with the PR title "Release v3.1.0" and matches the iOS version update in the podspec file.
61-61: CleverTap Android SDK updated to 7.1.2The dependency update from 7.0.3 to 7.1.2 brings in the latest features and fixes from the CleverTap Android SDK, which likely includes the new user-level event log tracking APIs mentioned in the PR summary.
ios/clevertap_plugin.podspec (2)
6-6: Version updated to 3.1.0 correctlyThis version bump aligns with the PR title "Release v3.1.0" and matches the Android version update in build.gradle.
16-16: CleverTap iOS SDK updated to 7.1.0The dependency update from 7.0.3 to 7.1.0 brings in the latest features and fixes from the CleverTap iOS SDK. Note that this is a different version than the Android SDK (7.1.2), which is expected as the iOS and Android SDKs may have different release cycles.
example/pubspec.yaml (1)
27-31: Caution: Git dependency on main branch may introduce instabilitySwitching from a versioned dependency (
^0.5.2) to a Git dependency tracking themainbranch could introduce instability as the main branch may contain breaking changes or experimental features.Consider one of these alternatives:
- Use a specific commit hash instead of
mainto pin to a known-good version- Use a release tag if available
- Document the reason for using the main branch in a comment
If this change is necessary, please verify that the current main branch is compatible with your implementation by testing all workmanager-related functionality in the example app.
CHANGELOG.md (4)
3-4: Version number and date format looks goodThe version number (3.1.0) and date format (March 3, 2025) follow consistent conventions with previous releases.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
3-3: Heading style
Expected: atx; Actual: setext(MD003, heading-style)
6-13: Android platform updates are well-documentedThe changelog clearly documents the Android SDK upgrade, removal of deprecated Embedding v1 support, and the new feature for hiding large icons in notifications. The reference to the migration guide is particularly helpful for developers who still rely on Embedding v1.
14-22: New user-level event tracking system is properly documentedThe changelog properly introduces the new user-level event log tracking system with a clear list of the new APIs. This makes it easy for developers to understand the additional capabilities being introduced.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
15-15: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
16-16: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
17-17: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
18-18: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
19-19: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
20-20: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
21-21: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
23-31: Clear documentation of API deprecationThe changelog clearly explains why older APIs are being deprecated and provides direct mapping to the replacement APIs. The explanation of the limitation of device-level tracking versus user-level tracking helps developers understand the motivation behind the change.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
23-23: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
24-24: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
25-25: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
26-26: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
27-27: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
28-28: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
29-29: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
30-30: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
31-31: Unordered list style
Expected: asterisk; Actual: dash(MD004, ul-style)
android/src/main/java/com/clevertap/clevertap_plugin/Utils.java (5)
12-12: Added import for UserEventLog classThe import for the UserEventLog class is correctly added to support the new user-level event tracking functionality.
83-94: Properly deprecating obsolete methodThe method is appropriately marked with the
@Deprecatedannotation to signal to developers that this method will be removed in a future version.
96-109: New method for user-level event log conversionThe
eventLogToMapmethod provides a clean implementation for convertingUserEventLogobjects to maps, maintaining the same pattern as the deprecatedeventDetailToMapmethod while adding additional fields relevant to user-level tracking.
111-119: New method for converting user event log historyThe
historyEventLogToMapmethod follows the same pattern as the existinghistoryEventDetailToMapmethod, providing backward compatibility while supporting the new user-level event tracking system.
121-121: Properly deprecating another obsolete methodThe method is appropriately marked with the
@Deprecatedannotation, consistent with the earlier deprecation.ios/Classes/CleverTapPlugin.m (7)
314-323: Added new user-level event tracking API methodsThe new method handlers for user-level event tracking are properly implemented, providing a clean interface for Flutter developers to access these new capabilities.
488-511: Implementation of getUserEventLog and getUserEventLogHistoryThe methods are implemented following the same pattern as the existing event methods, ensuring consistency in the API. The
_eventDetailToDicthelper method is appropriately reused to maintain consistency in the returned data structure.
507-511: Implementation of getUserEventLogCountThe method correctly delegates to the native SDK and returns the count as expected.
607-611: Implementation of getUserAppLaunchCountThe method correctly delegates to the native SDK method and returns the result.
625-629: Implementation of getUserLastVisitTsThe implementation correctly retrieves the timestamp of the user's last visit and returns it as an NSTimeInterval.
1000-1003: Update to _eventDetailToDict to include new fieldsThe method now includes the
normalizedEventNamefield, maintaining consistency with the Android implementation.
1017-1019: Added deviceID field to event dictionaryThe method now includes the
deviceIDfield, ensuring parity with the Android implementation.android/src/main/java/com/clevertap/clevertap_plugin/CleverTapPlugin.java (5)
63-66: Improved null-safety when detaching from activityThe null check for the
activityreference prevents potential NullPointerExceptions when the activity is already null.
79-82: Consistent null-safety when detaching for config changesSimilar null check for the
activityreference is added when detaching from activity due to config changes, maintaining consistency with the previous change.
88-88: Modernized plugin initializationThe call to
setupPluginis simplified by directly passing the binary messenger from the binding, following modern Flutter plugin architecture.
101-110: Updated plugin setup for modern plugin architectureThe
setupPluginandgetMethodChannelmethods are updated to use the modern Flutter plugin architecture, removing the deprecatedRegistrarapproach.
122-128: Simplified method channel creationThe method channel creation is simplified to directly use the binary messenger, adhering to current Flutter plugin development best practices.
android/src/main/java/com/clevertap/clevertap_plugin/DartToNativePlatformCommunicator.kt (10)
16-16: New import for user event logs
This import is necessary for referencing the newly added user event logs API.
68-68: Constant key introduction
Defining a dedicated key constant for the event name is clear and consistent with the other keys in this file.
248-265: New method calls for user event logs
These new Flutter method handlers properly delegate calls to retrieve user event logs, counts, or related data. The approach is consistent and readable.
1258-1258: Marking eventGetDetail as deprecated
This aligns with the shift toward user event logs.
1269-1269: Marking eventGetFirstTime as deprecated
Deprecation is consistent with the new user event log approach.
1279-1279: Marking eventGetLastTime as deprecated
Deprecation is consistent with the new user event log approach.
1289-1289: Marking eventGetOccurrences as deprecated
Deprecation is consistent with the new user event log approach.
1380-1380: Marking getEventHistory as deprecated
Deprecation is consistent with the new user event log approach.
1784-1784: Marking sessionGetPreviousVisitTime as deprecated
Deprecation is consistent with the new user event log approach.
1809-1809: Marking sessionGetTotalVisits as deprecated
Deprecation is consistent with the new user event log approach.example/lib/main.dart (17)
4-4: Importing 'dart:math'
This import allows generating random user identities or other numeric calculations. Looks appropriate.
242-242: Toast message for file path
CallingshowToast(filePath)here is fine. EnsurefilePathis always defined or handle empty values gracefully.
428-435: pushAmpPayloadReceived method
Nicely handles AMP push payloads by serializing to JSON and creating a new notification.
437-441: pushClickedPayloadReceived method
Properly logs the push payload and delegates deep link handling. Implementation is clear.
443-446: pushPermissionResponseReceived method
Logs whether push permission was granted or denied. Straightforward and correct.
449-458: _buildExpansionTile helper
Creates a reusable expansion tile widget for grouping interactive UI elements. Improves code readability.
459-471: _buildListTile helper
Good abstraction for creating consistent list tiles with optional subtitles.
473-506: _buildDialogSingleInput
Provides a dialog with a single input field, a helpful modular approach for user prompts. No major issues.
508-554: _buildDialogMultipleInput
Offers a multi-field variant for user inputs in a single dialog. Implementation looks fine.
559-581: Reworked build method (part 1)
Wrapping the app in aStyledToastis a neat approach for consistent toast usage. Overall structure is well-organized.
582-685: Reworked build method (part 2)
Extensive use of_buildExpansionTileand_buildListTilecreates a clean, navigable layout. Each list tile triggers relevant CleverTap functions. Overall structure is coherent.
694-702: Multi-Instance expansion
Displaying the multi-instance personalization toggles in a structured tile helps with user clarity.
704-715: Push Templates expansion
Good grouping of clickable actions to send sample push templates. This approach is consistent with the other expansions.
719-727: Input Box Push Notifications expansion
Well-labeled list tile actions for sending input-based push campaigns. Implementation looks fine.
731-733: Push Tokens expansion
Adding separate list tiles for FCM and HMS tokens is user-friendly.
737-740: Client Side InApps expansion
Segmenting fetch and clearing actions under one group clarifies usage. No issues observed.
742-746: Push Primer expansion
Centralizes push primer flows—builds on the structured approach for highlighting relevant features.lib/clevertap_plugin.dart (13)
77-77: Confirmed version update to 3.1.0The library version constant has been updated from 30000 to 30100, correctly reflecting the version increment to 3.1.0 for this release.
688-693: Proper deprecation ofeventGetFirstTimemethodThe method is correctly marked as deprecated with an appropriate message directing users to the newer
getUserEventLog()method. This follows good practice for API evolution by providing a clear migration path.
695-700: Proper deprecation ofeventGetLastTimemethodThe method is correctly marked as deprecated with an appropriate message directing users to the newer
getUserEventLog()method. This follows good practice for API evolution by providing a clear migration path.
702-707: Proper deprecation ofeventGetOccurrencesmethodThe method is correctly marked as deprecated with an appropriate message directing users to the newer
getUserEventLogCount()method. This follows good practice for API evolution by providing a clear migration path.
709-716: Proper deprecation ofeventGetDetailmethodThe method is correctly marked as deprecated with an appropriate message directing users to the newer
getUserEventLog()method. This follows good practice for API evolution by providing a clear migration path.
718-724: Proper deprecation ofgetEventHistorymethodThe method is correctly marked as deprecated with an appropriate message directing users to the newer
getUserEventLogHistory()method. This follows good practice for API evolution by providing a clear migration path.
726-731: New methodgetUserEventLogimplementation is well structuredThis new method properly replaces
eventGetDetailand returns a Map object with event details. The implementation follows the same pattern as other methods in the class, maintaining consistency.
733-737: New methodgetUserEventLogCountimplementation is well structuredThis new method properly replaces
eventGetOccurrencesand returns the count of a specific event. The implementation follows the same pattern as other methods in the class, maintaining consistency.
739-744: New methodgetUserEventLogHistoryimplementation is well structuredThis new method properly replaces
getEventHistoryand returns details of all events. The implementation follows the same pattern as other methods in the class, maintaining consistency. Note that unlike the deprecated method, this doesn't require an event name parameter, suggesting it returns history for all events.
746-750: New methodgetUserAppLaunchCountimplementation is well structuredThis new method properly replaces
sessionGetTotalVisitsand returns the number of times the app has been launched. The implementation follows the same pattern as other methods in the class, maintaining consistency.
752-756: New methodgetUserLastVisitTsimplementation is well structuredThis new method properly replaces
sessionGetPreviousVisitTimeand returns the timestamp of the user's last visit. The implementation follows the same pattern as other methods in the class, maintaining consistency.
918-923: Proper deprecation ofsessionGetTotalVisitsmethodThe method is correctly marked as deprecated with an appropriate message directing users to the newer
getUserAppLaunchCount()method. This follows good practice for API evolution by providing a clear migration path.
931-936: Proper deprecation ofsessionGetPreviousVisitTimemethodThe method is correctly marked as deprecated with an appropriate message directing users to the newer
getUserLastVisitTs()method. This follows good practice for API evolution by providing a clear migration path.
Summary by CodeRabbit
New Features
Platform Updates
Deprecations
Documentation