-
Notifications
You must be signed in to change notification settings - Fork 6
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
Change API to be closer to the Android/D-Bus spec ? #40
Comments
We can also not break the API, but this is going to be ugly, with some weird names for the new methods. |
I made a prototype of linux flutter without having to change this library, though I never completed my implementation so I might be missing something. Do you want to discuss in UnifiedPush/flutter-connector#45 first? I'll post some more info about my experiments there soon |
Actually the token identifies [edit: quote removed, irrelevant] [edit: that is an implementation discussion]
[edit: I mixed up implementation and specifications in this comment] |
I am not sure we should add in the spec another identifier to the connection mainly for ease of use, it feels to me like it's an implementation detail and mainly cosmetic. It will add complexity to it, while it's currently pretty minimal and I find that great. In my flutter prototype, for the platform interface, I have ditch some other interfaces (saveDistributor, registerAppWithDialog, ...) that are not in the spec (cross-checked against D-Bus one) and can be abstract in the plugin API or dealt with in the user code instead, here is the end result:
With that you can even register on several distributors at the same time and all should work fine. This is the platform interface only however, I am currently trying to mostly not break the actual API by adding support for We could also do the same in the Android code, separate the code in 2 layers for example. |
Sorry, I probably answered too late yesterday ! And I've got mixed up implementation and specifications. So, the android-connector follows the specifications. The Instance and tokenThere are 2 reasons we wanted the developers never have to deal with the token :
Therefore, token generation will definitely not be given to the user. Nevertheless, what you are describing can be very easily tweak :
Actually, that is what is already done, but we named the I have edited my previous post, I am sorry for the previous misleading answer. I hope it is more clear now. Multi-DistributorThe instance/token said, there is still something different on your implementation :
So today saved a single distributor for the app and you suggest to set a distributor per connection. ( That was also an implementation choice so end user won't have to choose the distributor for each account, to make it a bit more user friendly (which is not totally 😅 ). It wasn't obvious to do it this way, we discussed about it. Do you think we should allow multi distributor per app, and why ? |
Ahhh cool then we are basically in sync :) Happy to keep that in the implementation for ease of use. I'll ditch Thanks a lot for the feedback, you should have a PR pretty soon on |
Ah and for multi distributors, I don't really know if there is a use case. I guess a fallback one ? But it would be a bit complicated since the app will have to deduplicate the pushes. As long as it stays a possibility in the spec in case of I am happy :) |
Thanks a lot for your contribution, we will try to review it asap :) |
And here it is: No rush, this is a sizable one, and thanks for the nice welcoming around ! |
Can we close this issue (since it follows the specs 😄) and continue on the flutter-connector PR ? |
Indeed let's close that :) |
I am working on adding support for D-Bus as a Linux backend to the flutter connector.
I am running into troubles because the Android API exposed here hides the token behind an
instance
chosen name instead, and store a mapping for that.It complicated a lot of things when trying to abstract it, and I think staying closer to the specification and letting this to be handled by the user, or to some helpers instead, is perhaps not a bad idea.
What do you think ? The main problem is that we would break the API. I am however happy to propose something.
The text was updated successfully, but these errors were encountered: