Skip to content
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

map/dict based approach to Encoding and Decoding channel data #12

Closed
tiholic opened this issue May 7, 2020 · 5 comments
Closed

map/dict based approach to Encoding and Decoding channel data #12

tiholic opened this issue May 7, 2020 · 5 comments
Labels
enhancement New feature or improved functionality.

Comments

@tiholic
Copy link
Contributor

tiholic commented May 7, 2020

To overcome the brittleness of ordered encoding and decoding from iOS, Android and Flutter side, we must follow KVP based serialization and deserialization approach.

Related discussions:
#5 (comment)
#5 (comment)
#6 (comment)

@paddybyers
Copy link
Member

paddybyers commented May 8, 2020

we must follow KVP based serialization and deserialization approach

It's not mandatory to use an encoding in which key names are explicit (ie json or msgpack) if we can avoid the brittleness. For example, if we can have a single file that defines the schema (ie the field names and the types for each member of each class), and we can have a way to ensure that all 3 parts (dart, ios, android) implement the same schema then that's ok.

For example, have you seen https://www.freecodecamp.org/news/flutter-platform-channels-with-protobuf-e895e533dfb7/ ?

@QuintinWillison
Copy link
Contributor

Thanks @paddybyers - that's an interesting approach which would also reduce the amount of code we have to write and transliterate - reducing the "triple-handing" when it comes to serialisation and deserialisation per value.

The last time I played with protocol buffers it always felt a bit turbulent, but then that may have just been the process of building and running the right version of the protoc tooling. That may have improved in the last few years.

Regardless, this approach could work with any schema-based code generator. What other options might there be when it comes to that tooling? Or might we consider writing something ourselves?

@tiholic, what do you think? Have you worked with code generation much, yourself? I haven't particularly but it's an area that does interest me.

@tiholic
Copy link
Contributor Author

tiholic commented May 15, 2020

@QuintinWillison I have worked on json based code generation with a custom generator for java. I feel we can try protoc. I've been exploring on that.

@QuintinWillison
Copy link
Contributor

Great. Thanks! Looking forward to seeing what you come up with. 😀

@tiholic
Copy link
Contributor Author

tiholic commented Aug 18, 2020

We can close this as it is already implemented. We have #28 for switching codec to a more robust solution.

@tiholic tiholic added enhancement New feature or improved functionality. and removed research labels Aug 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or improved functionality.
Development

No branches or pull requests

3 participants