flutter_iap icon indicating copy to clipboard operation
flutter_iap copied to clipboard

[Android] Utilize Java better

Open JackAppDev opened this issue 7 years ago • 14 comments
trafficstars

@FaisalAbid @ened @buraktamturk ?

JackAppDev avatar Aug 02 '18 18:08 JackAppDev

Is there a specific reason for this?

thosakwe avatar Aug 03 '18 05:08 thosakwe

Could end up being simpler 🤷🏼‍♂️

JackAppDev avatar Aug 03 '18 05:08 JackAppDev

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.

JackAppDev avatar Aug 03 '18 05:08 JackAppDev

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.

thosakwe avatar Aug 03 '18 05:08 thosakwe

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

JackAppDev avatar Aug 03 '18 05:08 JackAppDev

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.

ened avatar Aug 03 '18 05:08 ened

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

JackAppDev avatar Aug 03 '18 16:08 JackAppDev

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

ened avatar Aug 26 '18 07:08 ened

@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

ened avatar Aug 26 '18 07:08 ened

What would be the downsides for that?

JackAppDev avatar Aug 26 '18 13:08 JackAppDev

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

ened avatar Aug 27 '18 05:08 ened

Great. Protobuf it is.

JackAppDev avatar Aug 27 '18 05:08 JackAppDev

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

ened avatar Oct 04 '18 09:10 ened

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

JackAppDev avatar Oct 05 '18 21:10 JackAppDev