Issues with Deserialization After Upgrading

[TheRedPanda17]

First of all, thank you so much for making this package. It's a very important part of my app.

I started using this package in 2020 and am on version 2.2.3. I am trying to upgrade dependencies, but it breaks at version 3.0.0 because of serialization. Right now, the data is stored like this in Firebase

{
  "codePoint": 59453,
  "fontFamily": "MaterialIcons",
  "fontPackage": null,
  "matchTextDirection": false
}

When I deserialize that now with the default version, I receive null because of this line: https://github.com/Ahmadre/FlutterIconPicker/blob/master/lib/Serialization/iconDataSerialization.dart#L83. How do I get my data working with the new versions so I can upgrade this package? I have several thousand monthly users that will all lose their selected icons otherwise :(

[TheRedPanda17]

I also saw that the old codePoints changed. Is there anything in here that maps the old ones to new?

[Ahmadre]

Thank you so much for your issue!

It's also for me very important, that developers can use this package in nth-years (because I use it in productions by myself).

Honestly I've built the serialization methods as "helpers" for developers not to care for the serialization itself for their related backend.

But because Flutter (and Material-Icons especially) are changing constantly their codePoints, what I really don't like, it's not fun to always use Icons.camera and get a different codePoint!

That's why we switched from codePoint's (especially for Material-Icons) to always actual mapped codePoint's as actual as possible (because Flutter doesn't have their Icons mapped in a Map -> this package exists for devs).

Now for your case (and also my case, because I also use this package in one of my productions apps):

1. Update at first all your Flutter-Projects dependencies (especially Flutter and Dart itself)
2. Migrate your database entries to actual codePoints by running your an app that uses latest flutter_icon_picker and update all db-entries where icons are used to get the latest codePoint's.

It's not fun, but I am thinking about to either remove serialization completely from this package, or discontinue this package, because I don't know if this is really a benefit, if Flutter is constantly changing codePoints 🤔

[TheRedPanda17]

I have done step 1, but I am a bit confused how to do step 2. All my entries are stored via Hive on device. When I run the version with upgraded dependencies, all of the entries are mapped to null because of the formatting issue I mentioned above. Are you saying to write my own method to convert between the old format and the new? And if so, what do I do about the changed codePoints? I'm struggling with the details of this step.

I think the package is great and will work well, I just need some help with this step.

[Ahmadre]

I have done step 1, but I am a bit confused how to do step 2. All my entries are stored via Hive on device. When I run the version with upgraded dependencies, all of the entries are mapped to null because of the formatting issue I mentioned above. Are you saying to write my own method to convert between the old format and the new? And if so, what do I do about the changed codePoints? I'm struggling with the details of this step.

I think the package is great and will work well, I just need some help with this step.

It's not that easy 🤔

At first: which IconPacks did your users use? Material? Cupertino? Custom?

Then we have to identify which Icons (for example "camera") had which codePoint in the past 🤔

If you look into version 2.2.3, we're in minimum Flutter 1.12.*:

FlutterIconPicker/pubspec.yaml

Line 10 in db37124

flutter: ">=1.12.0"

So I've found this in flutter-repository for v.1.12.*:
https://github.com/flutter/flutter/blob/v1.12.13-hotfixes/packages/flutter/lib/src/material/icons.dart

This file contains the old codePoint's I think 🤔

So compare the codePoint's here with actual flutter version:
https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/material/icons.dart

Then you can develop a kind of mapping from codePoint's to new ones if for some reason an icons cannot be displayed (any kind of error handling).

[TheRedPanda17]

Oh man. The problem is that users pick the icons from material. So potentially every icon in material might be using the old one...

[Ahmadre]

Oh man. The problem is that users pick the icons from material. So potentially every icon in material might be using the old one...

Exactly! That's why I would recommend for the Flutter Team to either stick to codePoint's or provide a way of iterating and searchable icons by their name...it's an old discussion from 2019 actually :D

[Ahmadre]

CodePoint from Flutter 1.12.*:

CodePoint from actual master-branch:

[Ahmadre]

Added a new version and disclaimer:

https://github.com/Ahmadre/FlutterIconPicker#disclaimer-important

[TheRedPanda17]

Thanks for adding the disclaimer. I've decided to go the route of downloading the iconData maps manually. The only problem is that showIconPicker only takes on customIconPack. I have three: 1) MaterialIcons 2) outline_material_icons 3) A new custom pack. How can I get all three to display?

[TheRedPanda17]

I've solved most of the problem by just using my own serialize and deserialize and downloading the .tff for the outline_material_icons. I want to download the .tff for the MaterialIcons, but I can't find the right version anywhere. Do you know where I could find the .tff from before the code points changed? @Ahmadre

[Ahmadre]

I've solved most of the problem by just using my own serialize and deserialize and downloading the .tff for the outline_material_icons. I want to download the .tff for the MaterialIcons, but I can't find the right version anywhere. Do you know where I could find the .tff from before the code points changed? @Ahmadre

Oh, I've never tried that.

You could look after the history of this place: https://github.com/google/material-design-icons/tree/master/font

maybe you'll find in the history an older version.

[sero583]

I'm thinking about using this package either in my production application and do not want to run into any kind of issues. As I see, the project is still maintained, there is no threat of discontinuing this - or?