I keep getting this error, no explaination in debug console, just takes me to the libobject_patch.dart page in vs code.
Exception has occurred.
NoSuchMethodError: The method 'containsKey' was called on null.
Receiver: null
Tried calling: containsKey("https://virga.in/images/demo/aashirwaad.jpg")
Doctor summary (to see all details, run flutter doctor -v):
[โ] Flutter (Channel master, v0.5.7-pre.62, on Microsoft Windows [Version 10.0.17134.112], locale en-IN)
[โ] Android toolchain - develop for Android devices (Android SDK 27.0.3)
[โ] Android Studio (version 3.1)
[!] VS Code, 64-bit edition (version 1.25.0)
[โ] Connected devices (1 available)
@shashikantx I think our issues are similar.
The problem is something is causing this error on the master and dev branches.
@gunhansancar wich lines should add to pubspec.yaml in order to avoid this isse?
Currently using:
cached_network_image: "^0.4.1"
@marianoarga if you change your flutter channel or branch to beta it works but beta branch is coming from a month or so in the commits but it is more stable.
To change it to beta type in the console:
flutter channel beta
if you type flutter doctor it shows what channel you're on currently as well.
Oh, now I remember, being in the beta channel gave me a couple of problems before, gonna staty away for now. Thank you.
I got the same issue, they cant load the first 2 images on example
[โ] Flutter (Channel dev, v0.5.7, locale en-US)
[โ] Android toolchain - develop for Android devices (Android SDK 27.0.3)

I/flutter ( 9928): The following NoSuchMethodError was thrown resolving an image codec:
I/flutter ( 9928): The method 'containsKey' was called on null.
I/flutter ( 9928): Receiver: null
I/flutter ( 9928): Tried calling:
I/flutter ( 9928): containsKey("https://images.unsplash.com/photo-1520342868574-5fa3804e551c?ixlib=rb-0.3.5&ixid=eyJhcHBfaWQiOjEyMDd9&s=6ff92caffcdd63681a35134a6770ed3b&auto=format&fit=crop&w=1000&q=80")
But when I use Image.network, it's load full of images of the example.
I am also seeing this. I'm using Flutter Channel master, v0.5.8-pre.163
I had to go back beta channel, looks like problem is caused only when we are on master channel.
Currently on 0.5.1
@shashikantx Yeah but beta branch is almost 2-3 months old. I think the problem is no one addressing these issues.
I've been on the dev channel already but now upgraded to the latest dev channel and start seeing this problem too.
I really really hope flutter arrives at a stable v1 release soon - I am so sick of google publishing their awesome frameworks and then keeping them stuck in alpha or beta forever until everybody gets so frustrated that they give up.
โโโก EXCEPTION CAUGHT BY SERVICES โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
I/flutter (11476): The following NoSuchMethodError was thrown resolving an image codec:
I/flutter (11476): The method 'containsKey' was called on null.
I/flutter (11476): Receiver: null
I/flutter (11476): Tried calling:
I/flutter (11476): containsKey("*******************")```
Doctor summary (to see all details, run flutter doctor -v):
[โ] Flutter (Channel dev, v0.5.7, on Microsoft Windows [Version 10.0.17134.165], locale en-NZ)
[โ] Android toolchain - develop for Android devices (Android SDK 27.0.3)
[โ] Android Studio (version 3.1)
[โ] IntelliJ IDEA Community Edition (version 2017.3)
[โ] Connected devices (1 available)
โข No issues found!
I ran into this today. The root cause of my issue (and it's tough to tell if it's the exact same as above without stack traces) was building multiple CachedNetworkImage widgets at the same time, as the _first_ call to the CachedNetworkImage plugin. This exposes an underlying bug in CacheManager, where the singleton cache instance initialization isn't property locked/synchronized, and so the second call to getInstance() comes in before the first is finished, and then containsKey gets called on an uninitialized Map.
That bug is actually already fixed in a PR on flutter_cache_manager, but it hasn't landed yet.
For a workaround, instead of forking, I added flutter_cache_manager as a dependency, and in my root widget called CacheManager.getInstance(). The call needs to complete before any of the CachedNetworkImages build, so depending on the structure of your app, it may need to go somewhere else/in a future builder/whatever.
Now, I'm not sure why this popped up in the dev channel. My best guess is that the process around rendering ListView widgets changed somehow, where some are now rendered in parallel instead of in serial?
Anyway, hope this helps someone.
@wreppun Thanks, that workaround fixed it for me.
Would be great if you could update this issue once its properly fixed and we don't need the workaround anymore.
Thanks
@shashikantx this should be fixed in the newest version of today.
Most helpful comment
I ran into this today. The root cause of my issue (and it's tough to tell if it's the exact same as above without stack traces) was building multiple CachedNetworkImage widgets at the same time, as the _first_ call to the CachedNetworkImage plugin. This exposes an underlying bug in CacheManager, where the singleton cache instance initialization isn't property locked/synchronized, and so the second call to
getInstance()comes in before the first is finished, and thencontainsKeygets called on an uninitialized Map.That bug is actually already fixed in a PR on flutter_cache_manager, but it hasn't landed yet.
For a workaround, instead of forking, I added
flutter_cache_manageras a dependency, and in my root widget calledCacheManager.getInstance(). The call needs to complete before any of the CachedNetworkImages build, so depending on the structure of your app, it may need to go somewhere else/in a future builder/whatever.Now, I'm not sure why this popped up in the
devchannel. My best guess is that the process around rendering ListView widgets changed somehow, where some are now rendered in parallel instead of in serial?Anyway, hope this helps someone.