search

JackAppDev / flutter_iap

Flutter iap plugin
MIT License
100 stars 15 forks source link

[Android] Utilize Java better #34

Open JackAppDev opened 6 years ago

JackAppDev commented 6 years ago

@FaisalAbid @ened @buraktamturk ?

thosakwe commented 6 years ago

Is there a specific reason for this?

JackAppDev commented 6 years ago

Could end up being simpler 🤷🏼‍♂️

JackAppDev commented 6 years ago

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.

thosakwe commented 6 years ago

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.

JackAppDev commented 6 years ago

It appears this isn't a clear improvement so I'll let others weigh in.

ened commented 6 years ago

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.

JackAppDev commented 6 years ago

This is now for better coding practices in the android implementation. Less string concatenation, more OOP.

ened commented 6 years ago

@JackAppDev Are you ok if we include a library like https://github.com/square/moshi to generate the JSON responses from simple POJOs?

ened commented 6 years ago

@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

JackAppDev commented 6 years ago

What would be the downsides for that?

ened commented 5 years ago

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).

JackAppDev commented 5 years ago

Great. Protobuf it is.

ened commented 5 years ago

@JackAppDev started this here: https://github.com/ened/flutter_iap/tree/protobuf - happy to hear your comments, thoughts.

JackAppDev commented 5 years ago

Looks great @ened . Can you update the readme to reflect the changes?