InputDeviceManagementService

[J0EK3R]

After many hours of thinking, refactoring, moving and renaming files - here is my suggestion for a generic handling of inputdevices (like gamecontrollers, MCP server,...).

Now, there is one instance of a InputDeviceManagerService handling all InputDeviceServices (all kinds of inputdevice services like GameControllerService, Gyro, whatever) and all InputDevices (gamecontrollers, gyro and so on).

The central InputDeviceManagerService still raises inputdevice events on button press, axis movement, channel changes and connection/disconnection inputdevices.

An InputDeviceService handles one special kind of inputdevices like gamecontrollers.
(In this branch there are only InputDeviceServices for gamecontrollers).

Now there is common base class InputDevice that replaces the former "Controller" - there was and still is a lot of renaming to do...
All inputdevices are derived from this baseclass.

One interesting part of code is the initialisation of all registered InputDeviceServices in InputDeviceManagementModule - perhaps there is a better way...

builder.RegisterType<InputDeviceManagerService>().As<IInputDeviceManagerService>().As<IInputDeviceEventServiceInternal>().As<IInputDeviceEventService>().SingleInstance()
                .OnActivated(e =>
                {
                    // resolve all registered input device services to trigger their registration
                    e.Context.Resolve<IEnumerable<IInputDeviceService>>();
                });

Please take some time and comment.

[Copilot]

Pull Request Overview

This is a comprehensive refactoring to introduce a generic input device management system to replace the existing game controller-specific implementation. The changes introduce an InputDeviceManagerService to handle all input device types, with InputDeviceService implementations for specific device types like game controllers.

Key changes:

• Replaced game controller-specific classes with generic input device interfaces and base classes
• Introduced a centralized InputDeviceManagerService to manage all input device types
• Renamed events, types, and properties throughout the codebase to use "InputDevice" terminology
• Updated platform-specific implementations (iOS, Android, WinUI) to use the new architecture

Reviewed Changes

Copilot reviewed 53 out of 53 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
Various ViewModels and Services	Updated to use new IInputDeviceEventService interface instead of IGameControllerService
PlatformServices/InputDevice/	New generic input device interfaces and base classes
PlatformServices/InputDeviceService/	New service layer for managing input device types
InputDeviceManagement/	New centralized management service and dependency injection setup
Platform-specific GameController implementations	Refactored to inherit from generic input device base classes
UI and Business Logic	Updated to use new event types and property names

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[vicocz]

Still out of time, therefore left few comments only.

But in general I like Input Device naming. So I guess this will be nice feature to complete, even if it's kind of refactoring only.

[vicocz]

Why is this needed? Why do we need RegisterInputDeviceService method? What's wrong with resolving IEnumerable<IInputDeviceService> as parameter of InputDeviceManagerService constructor?

[vicocz]

Still I need to check this more deeply...

[J0EK3R]

IEnumerable as parameter of InputDeviceManagerService constructor?

That was my first attempt and it crashed - it's the chicken-or-egg problem ;)

The InputDeviceService derivations constructor need the InputDeviceManagerService instance as parameter.
So you can't resolve IEnumerable<IInputDeviceService> as parameter of InputDeviceManagerService constructor.
So we first need to create the InputDeviceManagerService instance and then all the registered InputDeviceService types.

[J0EK3R]

I've startet renaming all the Controller-stuff (types, methods, etc.) to match the more common "InputDevice"-naming...
Does it make sense - yes, I think so.
But maybe we loose the ability to load or shere old stuff (Database?, json serialization...?)

What do you think?

[vicocz]

I've startet renaming all the Controller-stuff (types, methods, etc.) to match the more common "InputDevice"-naming... Does it make sense - yes, I thing so. But maybe we loose the ability to load or shere old stuff (Database?, json serialization...?)

What do you think?

No breaking changes from persistence point of view. So JSON related names should be the same.
Honestly, I will not approve such changes.
The goal is not to make the app nicest but keep it maintained and adding reasonable features.

[J0EK3R]

One interesting part of code is the initialisation of all registered InputDeviceServices in InputDeviceManagementModule - perhaps there is a better way...

builder.RegisterType().As().As().As().SingleInstance()
.OnActivated(e =>
{
// resolve all registered input device services to trigger their registration
e.Context.Resolve<IEnumerable>();
});

It seems, there is a much better solution to instantiate objects at startup: IStartable

https://autofac.org/apidoc/html/5F3C297F.htm

[J0EK3R]

One interesting part of code is the initialisation of all registered InputDeviceServices in InputDeviceManagementModule - perhaps there is a better way...
builder.RegisterType().As().As().As().SingleInstance()
.OnActivated(e =>
{
// resolve all registered input device services to trigger their registration
e.Context.Resolve();
});

It seems, there is a much better solution to instantiate objects at startup: IStartable

https://autofac.org/apidoc/html/5F3C297F.htm

Oh, yezzz - much better:

builder.RegisterType<GameControllerService>().As<IInputDeviceService>().As<IStartable>().SingleInstance(); // ensure it's started as soon as the container is built in Autofac

J0EK3R@0639939

[J0EK3R]

I've startet renaming all the Controller-stuff (types, methods, etc.) to match the more common "InputDevice"-naming... Does it make sense - yes, I thing so. But maybe we loose the ability to load or shere old stuff (Database?, json serialization...?)
What do you think?

No breaking changes from persistence point of view. So JSON related names should be the same. Honestly, I will not approve such changes. The goal is not to make the app nicest but keep it maintained and adding reasonable features.

I have identified these types that must retain their name and the names of their properties - they are used in database and sharing context:

• ControllerAction
• ControllerEvent
• ControllerProfile

I've renamed files and types ControllerTesterPage and ControllerTester and keep my fingers off the rest... ;)

[vicocz]

Just FYI I plan to start looking this week.

[vicocz]

Thank you for your contribution :)

[J0EK3R]

You're welcome. Thank you :)