 Voitko nähdä laittaa? Joo. Hyvä. Joten luulen, että katsotaan sitten. Mitä katsotaan? Tämä on 2 minuuttia. Joten tämä puhutaan, mitä on tapahtunut ilmastossa iOS-appan. Tällä kertaa, että minä olin hyvää, että olin kerrottunut tämän vuoksi tai ensimmäisenä ymmärtää minulle, että olen tullut ymmärtää lippuksi, jossa on aika paljon aikaa, ja kun puhuttiin, olen tullut tullut tullut tullut kurskompilatioita aika paljon aikaa, ja sitten enemmän tai järjestelmät. Joten nyt on myös sen jälkeen. Tässä on meidän järjestelmä. Ensimmäinen kokemus on EOS-appu. Se on ollut app-storeiden jälkeen jäi vuosien jälkeen, että se oli järjestelmätä tai järjestelmä tai järjestelmä. Se oli yleensä järjestelmä, koska se on järjestelmä tai järjestelmä järjestelmä. Meillä ei järjestelmä järjestelmä, mutta järjestelmä järjestelmä järjestelmä on vain yksi järjestelmä. Järjestelmä ja tämä oli järjestelmä järjestelmä, joten kuitenkin kiitos, että niitä on järjestelmä. Järjestelmä on järjestelmä, järjestelmä on yksi UI yksi koko koko online ja se on koko koko online siellä on koko ja se on myös käyttänyt appin ja tietysti paljon librauskoorot. Tämä kaikki on linkkiin yksi eri ympäristö. Ja UI on järjestelmäskryttä ei ole eri ympäristö. Ja sitten me otamme samaa ympäristökin asioita asioiden Collabora online as well in the app and also the improvements to core LibreOffice. The core code is currently using a 6.2 based vendor branch but it will soon switch to 6.4 and of course we also have like a lot of cherry picks from more recent upstream work and I guess I need to point out that even if it's based on Collabora online there is like no online aspect of this. It all happens, all the editing happens locally on your device and there is no server as there is for Collabora online. But the documents that you edit they can be on a server if you want to use iCloud or next cloud or some other file provider extension there are a few ones I don't remember which they are now but that are probably quite well known. Then again the next cloud iOS app when you use that and in that edit documents with Collabora online then you are actually using the a normal Collabora online server and the Collabora online JavaScript code is inside the next cloud app. I'm talking to the server but that's the different thing. Here is a picture from London, the canal there. So the first thing I'm talking about is keyboard things. The handling of the keyboard in this JavaScript is quite complicated and hard to get right. There were several issues with it and it was like an endless endless struggle to get it to work the right way. So the solution then was to write a small piece of native iOS code in Objective-C that we came up with this long name for. And the background about keyboards in general. You can have several types of keyboards. You can have an on-screen keyboard which on iPhone of course is quite small. Basically just the letters and space bar and that's it. And on iPad it's much larger there you have a Do you see my cursor, by the way if I move the cursor so I can point out something. On iPad you have this toolbar or whatever it should be called here above where you have some buttons for undo and redo and paste and copy. And there is also this button here or key here in the right lower hand corner for dismissing the keyboard. And above the keys you also get these word competition suggestions that you can tap if you type some word partially. Then you can also have hardware keyboards. You can have these Bluetooth keyboards that there are lots of models to choose from and they all work more or less equally well. And then you can have the hardware keyboard that is actually electrically attached to the iPad. It uses a so-called smart connector which is a it's not the lightning or USB-C thing that you otherwise connect other things to iPad through but it's a smaller connector on the back side. And Apple has two models. The one in the picture is the cheaper one. Smart keyboard folio and then they have this new magic keyboard which is much more expensive and and I'm supposed to be better but I personally think I like this model better. Now the on-screen keyboard in less complex cases it's supposed to work so that when you like tap in some text field the on-screen keyboard shows up and you then type into it. But the collaborative online is quite complicated both when you use it in a browser and when you use it in the collaborative app. So there were all kinds of issues. One very common thing was that you got the keyboard showing even if you didn't actually do any text input and that was a bit distracting because it takes so much space especially on on the iPhone. I must tell my wife to turn down the music. On the iPad it is also quite large so it takes much space so you don't want it if it's not necessary and on the iPad you can easily dismiss the on-screen keyboard. It's not so easy on an iPhone. I guess there is something but I haven't looked it up actually. And also even more annoying was when you didn't get the keyboard even if you needed it. Usually if you just tapped around in the UI in different places you got it eventually but it's a bit painful and the collaborative online JavaScript code handles the keyboard so that it it has this text field that is not visible but still there on the page and it calls the focus and blur functions of that to get the keyboard to show and go away. And it works to some extent but not always and there was a never ending struggle to keep this working as intended. So now for the iOS app we don't do this focus on the blur dance anymore. We instead call this native iOS code this collaboration online review keyboard manager to display or hide the keyboard and this is a separate thing, a separate repository because our idea was that it would be used also by the next cloud iOS app. In theory this piece of code is quite simple but in practice there were some some complications for instance the JavaScript code sends quite a lot of these display and hide requests. It does that also when using online in a web browser but I guess typically it works out well anyway and you don't notice it. But in the in the iOS app the end result was that you could see the keyboard like appearing for a split second and going away and then appearing again and stuff like that. And this piece of code uses a thing called the UI text view that an iOS control and it calls that to display the on-screen keyboard. One benefit of using this UI text view is that you get this word competition suggestions. It's based on what you have typed only into that keyboard instance because we don't send any information about the text context where you are typing the code yet but we could do that. Another benefit that was actually not even expected was that handling of these keyboard shortcuts on a hardware keyboard is much easier now. On a software on-screen keyboard you don't have these but hardware keyboards have them. It used to be that the handling of these command A, command C, etc. was often broken because it's hard to prevent stuff from regressing when you don't test on all platforms all the time. But now we actually these shortcuts in the native iOS code and do the right thing there and we actually could add more of them like command W to close the document and what other ones there might be. There is a picture of both masks. Then another thing that I recently worked on was supporting password protected documents. This uses NSS and until recently we hadn't built NSS at all for iOS or for Android because we didn't realize what it was really used for. We didn't think about it and it seemed to work well enough even without it and also the way NSS built this so complicated and painful to modify that we didn't want to cross compile it unless necessary. But then it became necessary and had to look into that like Kenti mentioned for Android also for iOS. We built the whole delivery of the score and the external libraries. Static libraries, archives. That's because originally like back in when this work started you couldn't include dynamic libraries in your iOS apps in the app store. Now it is you can but they would anyway would need to be repackaged a bit into frameworks. That's not hard but it's like a bit pointless complication for no real gain. But the NSS special snowflake couldn't be built completely statically because it insisted on loading a few libraries dynamically in any way even if it doesn't make any sense because you know in a use case like this because you can't have any alternative what you call this. Whatever it is whatever the thought is that you can use this dynamic loading for have alternative what's the term they use I don't remember. Anyway that requires some patching of NSS to link to these two libraries also statically. Here is a picture from my drone of an island and then multitasking. This was also funded by ad finish so thanks to them. In the current or I mean previous version of iOS Apple came up with this multitasking UI. It means that you can have a split view on iPad. You can have two apps at the same time or two documents in the same app but like separately. Or you can also have the same app open like in several. I think they are called workspaces. The thing you get when you swipe three fingers from one side to another. It's like virtual desktops on Linux. And this was in theory easy but in practice hard to implement. iOS specific code is not complicated you just had to add some new entries to the info.plist file and change the name of some methods in your code. But the hard problem was that this C++ code in Kolabora online was not prepared to handle such a case at all. Because in Kolabora online web based Kolabora online you have a separate process for each document that is open. That process then handles all the users that are editing at the same time. And this means that the code hadn't really been written so that it would preferably handle multiple documents at the same time. And also whenever nobody is editing a document anymore the process just goes away so it doesn't need to do any cleanups really. And on the Kolabora online server there are also these WSD process and a fork it process. But in the iOS app all the code for these processes well the relevant code for them is inside the same app process and the app process lives until the OS kills it. If it's not used and its resources are needed. And the way this works in the iOS app and in the Android app is that we have lots of threads which communicate with each other in a way that kind of emulates the way these processes communicate with each other using sockets on Linux. And this is quite fragile but it worked amazing well anyway. But now then with multitasking when you have multiple documents open this didn't really work that well anymore. Because there were some global variables for the current document being edited and there was just one current document at each time and things like that. And we used some Boolean flag to indicate that we are shutting down and that then closed the document but if you have several documents you don't really want to close them all when you close one. And also inside LibreOffice Core there were similar problems in LibreOffice Kit. And that's it. I hope you haven't all left and now you are still there. So if you have any questions, please repeat to ask them now. No questions. Okay well thank you then and I think there is a pause now until 1400 hours.