Skip to content
This repository was archived by the owner on Feb 22, 2023. It is now read-only.

Conversation

@bubunyo
Copy link

@bubunyo bubunyo commented Aug 5, 2019

Description

Currently, the ConnectionResult is an enum type with 3 values and no information on the type of mobile connection. With the PR, the ConnectionResult type is changed to an Object with two fields, type and subtype with type retaining previous ConnectionResult enum values and subtype providing information on the subtype of the connection if it is on mobile. (ie. EDGE, HSDPA and LTE.)

Related Issues

fix for flutter/flutter#37618

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

  • I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
  • My PR includes unit or integration tests for all changed/updated/fixed behaviors (See [Contributor Guide]).
  • All existing and new tests are passing.
  • I updated/added relevant documentation (doc comments with ///).
  • The analyzer (flutter analyze) does not report any problems on my PR.
  • I read and followed the [Flutter Style Guide].
  • The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
  • I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy].
  • I updated CHANGELOG.md to add a description of the change.
  • I signed the [CLA].
  • I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

  • Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
  • No, this is not a breaking change.

@bubunyo bubunyo requested a review from cyanglaz as a code owner August 5, 2019 14:45
return "none";

switch (info.getSubtype()) {
case TelephonyManager.NETWORK_TYPE_1xRTT:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a source for this info? How about a link to it?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i dont get you. Care to explain a bit more?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How someone is supposed to know the mapping you did here? Do you have an http link that could be used as documentation for this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to fully expose each type as a enum to dart. So we don't lose any information here. Same for iOS.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed some updates. I added reference links for the mobile broadband speeds.

@cyanglaz
Copy link
Contributor

cyanglaz commented Aug 5, 2019

@bubunyo Seems like the same thing has been worked on #1727
Do you mind following up with this other PR? Maybe help the author of the other PR a bit to finish up the PR?

@bubunyo
Copy link
Author

bubunyo commented Aug 5, 2019

@cyanglaz sure. I will close the PR and merge this with his

@cyanglaz
Copy link
Contributor

cyanglaz commented Aug 6, 2019

As discussed in #1727; we are going to work on this PR instead of that one.

Copy link
Contributor

@cyanglaz cyanglaz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. Did a first round scan. Left some comments.
Basically I want to make 2 suggestions:

  1. Could we keep the subtype more detailed by returning whatever we get from the platform, instead of translating them into different categories.

  2. To avoid breaking change, let's keep the old API to just return the main type. And the new API to return the subtype.

return "none";

switch (info.getSubtype()) {
case TelephonyManager.NETWORK_TYPE_1xRTT:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to fully expose each type as a enum to dart. So we don't lose any information here. Same for iOS.

///
/// Instead listen for connectivity changes via [onConnectivityChanged] stream.
Future<ConnectivityResult> checkConnectivity() async {
Future<ConnectivityResult> checkConnectivity(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

checkSubtype seems not used. Also add some doc to link to the [getNetworkSubtype] for people who wants to check the subtype.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i added some docs. Please review and let me know if they are up to standard.

/// Return none if there is no connections
///
/// Return unknown if it is connected but there is not connection subtype info. eg. Wifi
Future<ConnectionSubtype> getNetworkSubtype() async {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more doc to point users to the [checkConnectivity] for who wants to check the main type.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i added some docs. Please review and let me know if they are up to standard.

@bubunyo bubunyo requested a review from cyanglaz September 20, 2019 06:49
@sante85
Copy link

sante85 commented Oct 14, 2019

hi, any news?
when you able to merge?

Best regards

@sante85
Copy link

sante85 commented Oct 14, 2019

@bubunyo you can review?

@sante85
Copy link

sante85 commented Oct 14, 2019

we can definitively able to merge?

@sante85
Copy link

sante85 commented Oct 14, 2019

we need for this pull request. thanks

@sante85
Copy link

sante85 commented Oct 14, 2019

+1

@sante85
Copy link

sante85 commented Oct 17, 2019

@cyanglaz @bubunyo please can merge and review?

best regards

@sante85
Copy link

sante85 commented Oct 17, 2019

@cyanglaz why build-ipas fail?

@cyanglaz
Copy link
Contributor

Seems there are some merge conflicts.

@bubunyo
Copy link
Author

bubunyo commented Oct 17, 2019

I am trying to resolve the conflict but a lot of other things have been added, it will take some time to for me to get this working properly.

@sante85
Copy link

sante85 commented Oct 19, 2019

@cyanglaz @bubunyo when merge is scheduled?

@sante85
Copy link

sante85 commented Oct 24, 2019

any news?

@cyanglaz
Copy link
Contributor

cyanglaz commented Nov 7, 2019

@bubunyo It was on hold since we were migrating plugins to a new Android embedding. Now that the migrating is done with connectivity, I can help with merging this PR in. There are some conflicts with this PR, could you rebase and resolve them first?

@bubunyo
Copy link
Author

bubunyo commented Nov 7, 2019

Definitely, I can work on that tomorrow.

julianscheel pushed a commit to jusst-engineering/plugins that referenced this pull request Mar 11, 2020
Migrate the cloud_firestore core plugin to use the platform_interface package. All the "method channel" implementation now lives in the platform_interface package.

The plugin is now ready to support federated implementations.

Co-authored-by: David Iglesias <[email protected]>
Co-authored-by: Collin Jackson <[email protected]>
@demsey2
Copy link

demsey2 commented Apr 22, 2020

Any update on this? Thanks

@canthelou-xyz
Copy link

Did someone still work on this useful feature ? Thk

@KohlsAdrian
Copy link

Still wanting so bad this feature on the official plugin

@Extazx2
Copy link

Extazx2 commented Sep 14, 2020

Hello here, any news on this feature ?

@KohlsAdrian
Copy link

Connectivity 2.0.0 with breaking changes released and this is still not yet approved?

@stuartmorgan-g
Copy link
Contributor

We apologize for the long delay in following up on this PR. We’ve made the decision to no longer accept non-critical PRs for this plugin, as we hope that in time we’re able to transition users to the corresponding plugin in the Flutter Community Plus Plugins repository, so we encourage you to submit your PR there. I realize it's not ideal that this decision is happening after there has already had some initial review here, but hopefully that feedback will still be useful for a Flutter Community Plus Plugin version of the same change.

We’re in the process of overhauling our PR triage system to respond much more quickly to avoid this kind of delay going forward. (Transitioning plugins like this one to the Flutter Community group is in fact part of that effort.)

@stuartmorgan-g stuartmorgan-g added the plus-transition PR closed due to the goal of transitioning to Flutter Community Plus Plugins label Feb 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

cla: yes p: connectivity plus-transition PR closed due to the goal of transitioning to Flutter Community Plus Plugins

Projects

None yet

Development

Successfully merging this pull request may close these issues.