Open JackAppDev opened 6 years ago
Is there a specific reason for this?
Could end up being simpler 🤷🏼‍♂️
My thinking was that kotlin seems much more similar to swift and then it could be easier to convert from one to the other later on.
I guess that's fair, but OTOH to develop with Kotlin you need JetBrains (I think?), so that could potentially be a barrier to people who want to contribute to the project.
It appears this isn't a clear improvement so I'll let others weigh in.
It yields simpler code, and is supported by the android tool chain (no need “JetBrains”...) However it also adds a dependency on kotlin runtime environment which may increase app size, compilation is a little slower and it’s a new language which new contributors may or may not know.
If the current plugin works, I’d rather not change language at the moment and instead focus on proper testing and completeness.
If you want more concise code, then switching to java 8 syntax is a immediate step. It’s easy to activate, too - but please test first if flutter has any guidance on this.
This is now for better coding practices in the android implementation. Less string concatenation, more OOP.
@JackAppDev Are you ok if we include a library like https://github.com/square/moshi to generate the JSON responses from simple POJOs?
@JackAppDev Or perhaps even we could switch to protobuf, which is way more efficient than we need, but it would allow us to define all data models at once. Something like here: https://github.com/pauldemarco/flutter_blue/tree/master/protos
What would be the downsides for that?
For including external java libraries like Moshi the apps final binary size will grow. I think we actually might not want to do this in the end. What if every Flutter plugin imports a convenient JSON parser, and one chooses GSON, the other moshi etc.. doesn't make sense.
So, for protobuf, and actually for the protoc
way: It requires another step once the API needs to be extended, and that is to generate the updated models for iOS / Android. I think it can be handled well once we document it.
The benefits for protobuf (and mostly for generating things here), is that the internal API to iOS/Android is equal, and no more need for JSON string handling as we could return objects directly (which in turn get serialized and then deserialized on flutter/dart side).
Great. Protobuf it is.
@JackAppDev started this here: https://github.com/ened/flutter_iap/tree/protobuf - happy to hear your comments, thoughts.
Looks great @ened . Can you update the readme to reflect the changes?
@FaisalAbid @ened @buraktamturk ?