Is this lib deprecated or not?

[lucasjinreal]

Flutter latest update breaks all in this lib, doesn't anyone notice this??

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel master, v1.10.15-pre.405, on Mac OS X 10.14.6 18G71a, locale en-CN)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 11.0)
[!] Android Studio (not installed)
[✓] Connected device (2 available)

[lucasjinreal]

zefyr-0.8.0/lib/src/widgets/input.dart:11:7: Error: The
non-abstract class 'InputConnectionController' is missing implementations for these members:
 - TextInputClient.connectionClosed
Try to either
 - provide an implementation,
 - inherit an implementation from a superclass or mixin,
 - mark the class as abstract, or
 - provide a 'noSuchMethod' implementation.

class InputConnectionController implements TextInputClient {
      ^^^^^^^^^^^^^^^^^^^^^^^^^

[dheerajsarwaiya]

I got the same error as soon as I did flutter upgrade to Flutter 1.10.15-pre.429

[lucasjinreal]

@dheerajsarwaiya I removed this lib since it does not catch up for about 2 months and actually lots of feature doesn't support at all.

[cgestes]

it is not deprecated. 1.10.15 is out since today.
A lot of work has been put in the project, and it works quite nicely. Let's fix issues we find, dont forget this is open source, and people give from their free time to make it happened.

[lucasjinreal]

@cgestes Will it upgrade to pub.dev as well?

[cgestes]

It breaks since this commit: flutter/flutter@97cf355
only in master.

[cgestes]

It may work by adding the following in zefyr/lib/src/widgets/input.dart

 @override
  void connectionClosed() {
    if (hasConnection) {
      _textInputConnection.connectionClosedReceived();
      _textInputConnection = null;
      _lastKnownRemoteTextEditingValue = null;
      _sentRemoteValues.clear();
    }
  }

I dont have time to test with master right now, and I dont know the codebase well enough yet to be sure of my fix.

I believe the fix should not be pushed to pub.dev before it lands in stable. (I am not sure of the policy here). So it has to live in a branch in the meantime. (It doesn't compile without master).

Happy hacking guys

[pulyaevskiy]

Sorry for late reply. This project is not deprecated and I work on it whenever I have some free time.

Note that I stopped trying to support master channel of Flutter repo. If there is a breaking change in Flutter that affects Zefyr it'll be addressed when that change lands into Flutter's stable channel.

That said, I appreciate any hints for upcoming breaking changes.

It looks like as of now, this breaking change hasn't landed yet, but I'll take a look.

@cgestes Thanks for the snippet!

[lucasjinreal]

@pulyaevskiy Thanks for your work!

My advise is, publish stable on pub.dev, and make git master branch catch up with flutter master, so that users can using stable as well as master since flutter master really brings massive features all the time and optimize it's performance.

[cgestes]

@jinfagang what about people following dev?

[pulyaevskiy]

Yeah, I'd basically need to mirror all Flutter channels (master, stable, dev, beta) which is quite a bit of added complexity.

This gets trickier when I need to introduce breaking changes in Zefyr itself.

That said I think majority of requests are coming from people on master channel, so maybe it'd be good enough to only support master. This would also make it a bit easier for me to manage breaking changes in Zefyr.

However, when someone wants to submit a PR to Zefyr they'd normally target master branch. This means that these changes would only land to stable (and Pub) if (a) there is no breaking changes or
(b) when Flutter releases a new stable version. And this is only one edge case.

Basically this workflow quickly becomes hard to understand and follow. Which is why I'm still hesitant.

I do see value in supporting Flutter's master channel though. If anyone has better suggestions I'd definitely like to discuss this issue more.

[TimWhiting]

I think that flutter stable releases happen frequently enough to justify following the master channel of flutter in the master of this repo, and then releasing a new pub.dev version just after the flutter stable lands each quarter. This works well for new features and overall improvements to the library.

I can see an issue with people needing a bug fix in stable before the next flutter stable comes out, but they are free to branch from that commit in the library and fix it themselves in that case, or backport a fix from master into a 'stable' branch, create a pull request, and request an update to the pub.dev version.

However, it would also allow everyone working on the library to add fixes and features, while planning for the future, and making sure it is compatible with future flutter versions. I agree that it would probably be too much to mirror every channel. Just my personal thoughts.

[pulyaevskiy]

FYI: we're trying to track Flutter's master channel in Zefyr's master branch. It is currently compatible, if you find any issues please file separate tickets.

Closing this.