[Question] locating several implementations of a common type?

[tiloc]

Is there a function or a best practice how I can register several implementations of a common type and then later locate all of them? For instance, I have common type called "Gadget" and several derived types, like "AGadget", "BGadget", "MockGadget", etc. What I want is to register "AGadget" and "BGadget", and then later locate both of them with something like GetIt.I.list() which should return both of them, so I can loop over them and invoke a method on them.

It seems that the registration and get methods in GetIt are only applicable to a single instance per type?

[escamoteur]

You can register multiple instances of one type and probably create a workaround for this by using the 'name' parameter when registering and getting of objects. This has been asked before but I wasn't sure I completely understand the use case for something like that. Can you elaborate a bit on why you need it? Am 3. Juni 2022, 16:23 +0200 schrieb Tilo ***@***.***>:

…

Is there a function or a best practice how I can register several implementations of a common type and then later locate all of them? For instance, I have common type called "Gadget" and several derived types, like "AGadget", "BGadget", "MockGadget", etc. What I want is to register "AGadget" and "BGadget", and then later locate both of them with something like GetIt.I.list() which should return both of them, so I can loop over them and invoke a method on them. It seems that the registration and get methods in GetIt are only applicable to a single instance per type? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tiloc]

My use-case is an app which can simultaneously talk to multiple devices through proprietary protocol drivers. I have bundled each driver into a Dart class with a common parent type. Depending on licensing, regional regulations, demo mode, unit test mode etc. I want to register the applicable devices during startup of the app and then later use the locator in all other places of the app to determine the registered devices. Kind of like this:

main.dart:

if (expensiveDeviceLicensed) {
  GetIt.registerMultiple<DeviceDriver>(ExpensiveDeviceDriver);
}
if (inUnitedStates) {
  GetIt.registerMultiple<DeviceDriver>(AmericanDeviceDriver);
}

later_in_app.dart:

final drivers = GetIt.list<DeviceDriver>();
for(final driver in drivers) {
  driver.talkToDevice();
}

[escamoteur]

So you indeed need multiple device drivers simultaneously when the app is running? Am 3. Juni 2022, 18:55 +0200 schrieb Tilo ***@***.***>:

…

My use-case is an app which can simultaneously talk to multiple devices through proprietary protocol drivers. I have bundled each driver into a Dart class with a common parent type. Depending on licensing, regional regulations, demo mode, unit test mode etc. I want to register the applicable devices during startup of the app and then later use the locator in all other places of the app to determine the registered devices. Kind of like this: main.dart: if (expensiveDeviceLicensed) { GetIt.registerMultiple<DeviceDriver>(ExpensiveDeviceDriver); } if (inUnitedStates) { GetIt.registerMultiple<DeviceDriver>(AmericanDeviceDriver); } later_in_app.dart: final drivers = GetIt.list<DeviceDriver>(); for(final driver in drivers) { driver.talkToDevice(); } — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[tiloc]

yes, it is listening to multiple devices through various drivers fully in parallel.

[escamoteur]

Intuitively I would say that's not the job of a service e locatator and I would register an DeviceNanager object that contains a List of Devices. IMHO that would make the code more readable. On the other side, maybe it is a nice additional feature for get_it Am 3. Juni 2022, 19:19 +0200 schrieb Tilo ***@***.***>:

…

yes, it is listening to multiple devices through various drivers fully in parallel. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[tiloc]

Thanks for sharing your views with me. So yes, I think I will go with the device manager approach for now.