Skip to content

Fixed singleton design to fix issues with async initialization. #21

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.

Sign up for GitHub

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

Closed
darthdie wants to merge 1 commit into from
+8 −9
Closed

Fixed singleton design to fix issues with async initialization. #21

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 8 additions & 9 deletions lib/flutter_cache_manager.dart
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,15 +24,14 @@ class CacheManager {

static CacheManager _instance;
static Future<CacheManager> getInstance() async {
if (_instance == null) {
await synchronized(_lock, () async {
if (_instance == null) {
_instance = new CacheManager._();
await _instance._init();

@wr-dh wr-dh Aug 3, 2018

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@darthdie @mockturtl , an alternative fix might be to do something like:

final backingInstance = new CacheManager._();
await backingInstance.init();
_instance = backingInstance;

Delaying the assignment to _instance until after the initialization keeps that initial null guard working as designed.

This way we don't have to worry about initializing _cacheData in #34 (and then re-initializing it with the new Map() call), and then you don't end up with a race condition on which map (initial or re-initialized) is hit.

Hm. After thinking about it, I'm confused as to how #34 happens with this PR (original version) in place. AFAICT, it shouldn't?

Anyway, just some thoughts. I do like how this current PR gets rid of the nested null guards, and I mostly started to write this out of interest on whether the _cacheData initialization is necessary.

}
});
}
return _instance;
return await synchronized(_lock, () async {
if (_instance == null) {
_instance = new CacheManager._();
await _instance._init();
}

return _instance;
});
}

CacheManager._();
Expand Down