-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: refactor dart call forwarding #183
chore: refactor dart call forwarding #183
Conversation
Sample app builds 📱Below you will find the list of the latest versions of the sample apps. It's recommended to always download the latest builds of the sample apps to accurately test the pull request.
|
7e4fd34
to
ad14375
Compare
} | ||
|
||
/// Access in-app messaging functionality | ||
CustomerIOMessagingInAppPlatform get inAppMessaging => _inAppMessaging; | ||
static CustomerIOMessagingInAppPlatform get inAppMessaging { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to match with initial proposal and with pushMessaging
lib/customer_io_method_channel.dart
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file has been moved to lib/data_pipelines/customer_io_method_channel.dart
below. But due to significant content changes (because of extension), GitHub shows it as a deleted file.
import 'customer_io_platform_interface.dart'; | ||
|
||
/// An implementation of [CustomerIOPlatform] that uses method channels. | ||
class CustomerIOMethodChannel extends CustomerIOPlatform { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated implementation of lib/customer_io_method_channel.dart
using extensions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, we dont need to make all methods Future
its only for those where we need to make sure native code is executed before the dart code, e.g initialize
for rest we are okay to use just void.
Discussed on call, and we decided to stick with |
part of: MBL-660
Changes
inAppMessaging
a static property to align with the initial proposalFuture
, reflecting asynchronous nature of native calls