[device_info_plus] make toMap() json compatible

[iapicca]

Description

rename toMap() as toJson() to improve compatibility with dart:convert
see jsonEncode

If toEncodable is omitted, it defaults to a function that returns the result of calling .toJson() on the unencodable object.

updated: makes toMap compatible with json parsing

Related Issues

fix #949

Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See [Contributor Guide]).
• All existing and new tests are passing.
• I updated the version in pubspec.yaml and CHANGELOG.md.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (flutter analyze) does not report any problems on my PR.
• I read and followed the [Flutter Style Guide].
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• [] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
• [x ] No, this is not a breaking change.

TODO:

after publishing,
bump device_info_plus_platform_interface to ^2.3.1 in device_info_plus's pubspec

[miquelbeltran]

Thank you! I am positive about this change. The only issue is that this would be a major version bump, so the platform plugin should be increased to 3.0.0, and all its dependencies as well. The change should be well documented in the respective Chanelogs.

Any thoughts? @vbuberen

[vbuberen]

Any thoughts? @vbuberen

I am not sure why do we need it.

[iapicca]

@miquelbeltran
thanks for looking up the PR

@vbuberen
besides the originally stated reason,
during the implementation I also noticed that in some platform toMap is "broken"
more specifically
jsonEncode(info.toMap()) throws because toMap doesn't always return json compatible types (eg: enum)
this PR address this problem as well

[miquelbeltran]

during the implementation I also noticed that in some platform toMap is "broken" more specifically jsonEncode(info.toMap()) throws because toMap doesn't always return json compatible types (eg: enum) this PR address this problem as well

mmhhh... I am more inclined now to make toJson() a new method rather than modifying the toMap(), that way this is not going to be a breaking change.

What do you think about that @iapicca ?

[iapicca]

mmhhh... I am more inclined now to make toJson() a new method rather than modifying the toMap(), that way this is not going to be a breaking change.

What do you think about that @iapicca ?

@miquelbeltran
no problem, I re-added the toMap() straight from the current upstream main
in most cases I can just toJson() => toMap(), but the web platform interface was messed up (not by me)
and there is a different behavior for both toJson and fromMap
please take a look

[miquelbeltran]

I am sorry, I am not sure anymore if we need this. If a user wants to serialize the contents of a DeviceInfo object, they should do it on their own app data model. We shouldn't be maintaining a toJson implementation on our side, even if convenient, it is not our job. Like, I am not even sure why are we providing a toMap method even, I guess that's the legacy from when we got the plugins from Google.

[iapicca]

I am sorry, I am not sure anymore if we need this. If a user wants to serialize the contents of a DeviceInfo object, they should do it on their own app data model. We shouldn't be maintaining a toJson implementation on our side, even if convenient, it is not our job. Like, I am not even sure why are we providing a toMap method even, I guess that's the legacy from when we got the plugins from Google.

@miquelbeltran
can I at least fix the web implementation?
It's literally the only case where it cannot be use as jsonEncode(info.toMap())

[miquelbeltran]

@miquelbeltran can I at least fix the web implementation? It's literally the only case where it cannot be use as jsonEncode(info.toMap())

Yes, I agree with that.

The Readme.md says:

You then use it's toMap method to serialize all known properties to a Map. Your backend service should be prepared to handle new properties, which can be added to this plugin in the future.

If the serialization using toMap doesn't work because it uses enums, then it must be fixed!

[iapicca]

I did merge properly before, now it's up to date

[...] can I at least fix the web implementation? It's literally the only case where it cannot be use as jsonEncode(info.toMap())

Yes, I agree with that.

The Readme.md says:

You then use it's toMap method to serialize all known properties to a Map. Your backend service should be prepared to handle new properties, which can be added to this plugin in the future.

If the serialization using toMap doesn't work because it uses enums, then it must be fixed!

@miquelbeltran
that's good to hear!
So I removed the toJson and ported the fix for the web implementation
I think this way is more than usable and if someone (like me) really wants toJson
can just do

extension BaseDeviceInfoToJsonX on BaseDeviceInfo {
  Map<String, Object?> Function() get toJson => toMap;
}

[miquelbeltran]

Thanks! can you cleanup the PR, and limit the changes to the web plugin implementation?

[miquelbeltran]

All changes not related to the fix should be reverted

[iapicca]

Thanks! can you cleanup the PR, and limit the changes to the web plugin implementation?

All changes not related to the fix should be reverted

@miquelbeltran
I think we have to option for the web plugin implementation:

a) remove browserName from both toMap and fromMap

b) keep browserName in both toMap and fromMap ensuring consistency with userAgent data

b is the current implementation and requires the committed changes,
I'm not sure what changes you wish to be limited