SoK/2022/StatusReport/Stefan Kowalczyk

Improving UX for KDE Connect iOS Internal Error and Alerts

KDE Connect for iOS is a currently developed version of KDE Connect, that allows iDevices to communicate with KDE desktops. A lot of information is communicated to the user using system alerts. iOS is limited to displaying only one alert at a time and doesn't have any native system for queuing them.

This project aims to make this aspect of the app better for end-users. By queuing the alerts it protects the user from losing information.

Mentors

Lucas Wang, Apollo Zhu

Blog Posts

• First month of KDE SoK 2022
• Second month of KDE SoK 2022

Merge Request

The merge request can be found here.

Results

• Alert queuing with iOS 14 compatibility
• New IP configuration screen

I have somewhat deviated from the original proposal, as some solutions proposed had to be changed to better reflect the app's needs (things like how is data about alerts is stored and the types of alerts, as only one, was needed in the end). Also due to an initial miscalculation in the time, it would take to complete different tasks the timeline had to be readjusted.

Timeline

January

I had to start the project two weeks later due to exams, so my actual work began in February.

February

I was working on a proof of concept for the alert manager, and the queuing system. As I wasn't really experienced with swift. some aspects of it out took me a while to understand properly. The first thing that had to be figured out was the data structure in which alerts were going to be stored. After that, I worked on implementing the system that actually displays the alerts one after another. In order to do that I had to learn about bindings in swift. With that completed, and the correct data structure in place, it was now possible to display multiple alerts in a queue.

March

Having a working system in place I switched all alerts to it. There were some issues along the way but I managed to fix them quickly. Moving AlertManager to a top view and a related binding inside it has proven to be more difficult than expected. I had to change the way the state of the alert was represented. That was the moment I learned a lot about Combine, a Swift API that manages data over time. It was probably the hardest concept for me to understand about Swift, but with some help from my mentors, I wrapped my head around it. Armed with that extra knowledge I moved everything to its proper place and fixed any bugs that might have cropped up. The last big thing was replacing the text alert that was present on the manual IP configuration screen, with a more modern editable list solution. It was a great way to put things I learned to the test.

April

The last two weeks were spent finalizing both iOS 14 support and the new manual IP configuration view. Everything that was left was to rebase my changes, add documentation and clean up some code.

Results of my work can be seen in the second blog post and in the MR.

All of that wouldn't be possible without the help of my Mentors. It was great working with them.

Future directions

This system should be used across the app, as doing otherwise could interfere with background alerts coming through. Here is a bit of documentation about that.

queueAlert(prioritize:title:content:buttons:)

Parameters:
    - prioritize: If true, adds the new alert to the begging of the queue. Should be used when an alert is shown as a direct result of user interaction.
    - title: Title of the alert.
    - content: Content (message) of the alert.
    - buttons: Buttons for the alert.
   

And here is a practical example:

alertManager.queueAlert(title: "Pairing Complete") {
    currentPairingDeviceName(id: deviceId).map{
        Text("Pairing with \($0) succeeded")
    }
} buttons: {
    Button("Nice", role: .cancel) {}
}

Other than that in the future it might be a good idea to switch the alerts for something less obtrusive that looks better. This system could be adapted for that purpose, but I think that's pretty low on the priority list.