No longer receiving bug reports about crashes on delete devices.

Currently worked on by Stefan Kowalczyk for SoK 2022

Implemented in https://invent.kde.org/network/kdeconnect-ios/-/merge_requests/38

It seems that we can mark this as completed.

README update in: https://invent.kde.org/network/kdeconnect-ios/-/merge_requests/39

I have updated a new commit on KDE Invent GitLab.

I have implemented a rough version of this. Screenshots follow:

Is the content of the acknowledgment screen like what in VLC for iOS, but triggered by one of the settings rows? (a screenshot is attached below)

I think we can consider this done now.

For desktop, we can already see the key of any remote device which is not paired by KCM. Do we still need a button to display SHA256 fingerprints of both devices like that on Android?

In T15164#269736, @apollozhu wrote:

Hi turx, thanks for taking an initiative in solving this! Since we only use Phabricator to keep track of tasks, it would be great if you can start a merge request on KDE Invent GitLab https://invent.kde.org/network/kdeconnect-ios so it's easier for us to review and merge your contribution.

In T15164#269734, @lucaswzx wrote:

Hi turx! I took a look through the diff of the patch and it seems like the idea behind the implementation is sound. Though I'm not sure what potential problems the hard-coded 1 second wait would be.

Have you tested this in an actual broadcasting disabled environment yet? I'm curious how you did it. For your first question, I had some ideas but I haven't tried them out:

• The most realistic approach: go into your router settings (usually 192.168.1.xxx) and literally turn off the broadcast feature. This will test as intended: pop-up shows up, and then adding the remote device's LAN address manually will allow discovery.
• Simulated approach: block UDP port 1716 on the device running KDE Connect/Simulator to prevent it from receiving (or sending) the ID packet. This will test the pop-up properly, but unlike the previous method, adding addresses directly WILL NOT allow discovery since 1716 is just blocked no matter what.
  
  Plz do note that doing either could potentially affect other processes running on your network, so keep in mind of that.

Hi turx, thanks for taking an initiative in solving this! Since we only use Phabricator to keep track of tasks, it would be great if you can start a merge request on KDE Invent GitLab https://invent.kde.org/network/kdeconnect-ios so it's easier for us to review and merge your contribution.

Hi turx! I took a look through the diff of the patch and it seems like the idea behind the implementation is sound. Though I'm not sure what potential problems the hard-coded 1 second wait would be.

Here is my patch based on the most recent commit b2b8673fc301d4fd4d69fef620484efa9daecbdf:

I have implemented a rough version.

I am happy to help solve this problem, and I have macOS/iOS devices with the latest software. Could you please provide me a hint that how to set up a UDP-broadcast-disabled network environment for a connected iOS device or an Xcode simulator?

Opened merge request https://invent.kde.org/network/kdeconnect-ios/-/merge_requests/36, pending testing and review

Device.reloadPlugins does use _incomingCapabilities to add supported plugins, could you please elaborate on the specific parts in which device type is used instead?

Note: currently Backend.swift contains a large number of unrelated functionalities, it might be a better idea to create a new file for each functionality (starting from the new changes, and gradually expanding to existing code)

I believe this should have been fixed in https://invent.kde.org/network/kdeconnect-ios/-/merge_requests/28, could you please confirm?