Open postlund opened 4 years ago
One improvement that must be made to the fake devices in general is that state and connection logic must be seperated. Problem now is that encryption and state is combined, so once someone has connected and authenticated, the encryption for that entire device is "fixed" to that single connection. So, when someone else connects (either after the first connection is closed or in parallel), the fake device will assume the generated keys are to be used and the connection will fail.
Usecase logic should modify the state and state changes should trigger updates to be sent by the device (when that is the case).
What to investigate Currently there are three separate "fake devices" used for functional testing (
DMAP
,MRP
andAirPlay
). They implement enough logic to simulate a real device, sopyatv
can be tested on a functional level. These fake devices are extremely basic and unfortunately of quite low quality, but they are still very powerful and I see great potential in them. I would like to see them improved and move them to the real code base, so it's possible to create fake devices that are compatible with the Remote app in iOS.Why? Because this allows for very cool usecases. For example, you can simulate a device the looks and feels like an Apple TV (as seen from the iOS app/control center) but in reality controls for instance another media player, light levels or anything else. Since the fake device would receive all input events and it would programmatically be possible to do anything, the possibilities would be endless. Another interesting usecase is to simplify playing around with
atvremote
, as one can setup a fake device and play around with without even owning an Apple TV.This is a long-term goal and not anything I will focus on soon. Just want to keep this note around as a reminder. First and foremost I need to fix the
MRP
fake device as that basically support nothing all it.Expected outcome An idea on how to do this...