 We're actually one minute early. So we can wait another minute or two for make sure everyone gets there. Sorry, you just recorded. Great. Get me dancing. Dance. Dance. Yossin, I'm going to probably say we can kick off now. Sounds good. Let's get started. Hello, everyone. Welcome to this session on DHS2 as a platform. It's titled DHS2 Is the Platform? I'll get into what that means in just a minute. But we're going to go over a number of the tools that are provided by DHS2, as well as the guiding principles that we try to embody and are trying to build more and more capacity around in order to make DHS2 the foundation for extensibility and extensions to be adaptable to local contexts, as well as different use cases, because it is used in many different contexts around the world. So with that, I'm going to go ahead and share my screen. I'm going to kick you off, Grant. There we go. OK. Should be able to see my screen now. Yes. So we're going to talk a little bit. First, I will introduce designing for extensibility. This will be just a very quick overview of what it means to design for extensibility in the DHS2 core team. And some of this is relatively new, but it's a concept that we've been trying to embed into our development practices for the last several years. And it actually was one of the kind of founding principles of DHS2, as well. I will then turn it over to my colleague, Deborah, who will talk about the community, developer community initiatives that we have launched in order to support and connect with the community of developers around the world who are building on top of DHS2 using our tools, as well as extending and integrating with other systems in different contexts. Then I will introduce some of the updates and the roadmap for our application platform, which is targeted at web apps building on top of DHS2. And Kai, who is my colleague on the front end team, will also introduce some specific exciting new updates that we have there around offline applications for DHS2. Then I'll turn it over to my colleague, Victor, who will talk about the Android SDK and what has happened and what's coming soon there. And then I will come back to myself just to show a little bit of what's coming down the line in DHS2. We'll learn more about that in the what's next session, plenary session on Friday for the last day of this conference. And then we'll open it up for questions. So if at any time during this presentation your questions, feel free to put them into the chat or in the community of practice post. We'll try to address them live. Or if we don't get to them or don't have time, we will respond to them on the community of practice after the session. So I'm going to start by talking just quickly about mining capability and what this means. Generally, platform is an overloaded term, meaning that we use it for too many things, especially in DHS2 world. We have a platform team. We have a platform product, which is encompassing a number of different web applications and the server backend and a number of other things. We have an application platform upon which other web applications can be built. And these are all accurate terms, but they're a little bit confusing because they all refer to slightly different things. And they're all part of the bigger picture, which is that DHS2 itself is the platform. DHS2 is the platform meaning that it is the foundation upon which you can build whatever you want. And it provides some of the foundational structure that can be used to build a system for addressing maternal health in routine surveillance or it can be used to administer COVID vaccinations across an entire country and deal with things like certification of those vaccination events. It can do a lot of different things. It can also be used in education, in logistics, in a number of other realms that are not directly related to health. And those are all enabled because DHS2 itself is designed as a platform. And some of the key goals for embedding this concept of DHS2 as a platform into the work that we do to build DHS2 as the UIO core team is that we design for extensibility and we try to design for extensibility first, meaning that we build features certainly that are used and useful for the health use cases that are most prevalent for use of DHS2. But we also build in a way that can be adapted and extended to many other use cases, many other contexts that we cannot address from the kind of global platform level because they are specific to certain contexts or certain use cases. And one of the goals that we were not quite there yet but that we're trying to work towards is that everything that UIO as the core team can do should also be possible in third party modules. Right now it's a little bit more difficult to build a full featured analytics application on top of DHS2 without building your own custom backends and things like this. It can also be difficult to build integrations with other systems if you don't have the infrastructure available in DHS2 itself. And so that's a goal that we're working towards. And we'll talk a little bit more about that later. But first I'm going to turn it over to my colleagues to present some updates about the different pieces of what we currently do for towards making DHS2 extensible. And I will first turn it over to Deborah who will talk about our developer community initiatives. Deborah, go ahead and take it away. And feel free to introduce yourself. I'll introduce myself in a minute at the start. Hi, sorry. Okay, yes, I can share my screen. I think you should be able to see my screen now. Yeah. Yes, we can. Okay, great. Right, thank you. Yeah, thank you, Austin, for the introduction. So hello, everyone. My name is Deborah Galliano and I joined DHS2 in January this year as a developer advocate. And yeah, okay. So in other words, my job is to basically foster or build on the existing DHS2 developer community and to promote developer outreach initiatives. So today I'll be talking about these initiatives and activities that we have been working on over the past months. So these are the things that I'll cover today very quickly, which are all part of creating a better experience for new and existing DHS2 developers in terms of one having resources or documentations available for developers. Also having or offering learning material or online workshops. And third, having a community or connecting with the entire DHS2 developer community. So I'll go over some of this topics now. Yeah, so as for developer resources, we wanted to create a more centralized documentation system where developers can find all the information that they need in one place. So in March, we relaunched the developer portal, which is an improved version of the one that we had before. And this new website offers several improvements on documentation mainly, and it offers also a better interface and other interesting developer focused information. So that's the goal to have a developer portal that provides better documentation and that offers more developer resources in general, like how to guide tutorials and information about events, community related activities. So this is a working progress. I will show you in a little bit, but we're planning on adding more content or more documentation there for sure. And I just wanted to give you like a quick tour. So I'll just, I'll have it here. Okay, so if you go to developers.dhs2.org, you will get to our websites, the developer portal. If you go to the documentation page, you will see that is, of this page is well organized. And the sidebar here is divided into different types of documentation like tutorials. We will add more, but this is for developers who are new to dhs2 web app development and who wants to get started using the app platform, using the UI library and communicating with the web API using the app runtime. You can check this tutorials. We will again, continue adding more code documentation here and also the, oh yeah, okay. So if you go to the guides section, you would have a step-by-step guides on the specific topics. So this is how to set up your local environment. I'm not going to go through every topic, but you can check this on your own, the app hub as well that we mentioned yesterday if you were there in our session about the new app hub websites. If not, make sure to check the video that was shared on the community of practice. We will add more guides on the reference and the conceptual guides and this will be a more specific documentation on the API and like an overview of concepts about the HIS too. So in the blogs, what's new is that we added a way, this is one of our most popular blog posts and you can easily comment on this post here by using, you only need a GitHub account. You just log in and you can comment there. We will add more blogs. This is where we post things about announcements or what's new on our libraries and tools and things like that. So yeah, just stay tuned for the next blogs. The events page or tab is divided by the type of events that are relevant to developer community. We had hosted the last one, the last webinar in February. You can check information here. I will cover this in a little bit more. The academy that we hosted in March and in May but I'll talk about it in a little bit and the annual conference right now and I'll just update this information in a bit. Sorry, and then this is a very important page because this is where you can find more information about the community of DHS to developer community. And I'm sure you're familiar with the community of practice. We have also added or created, I guess, a slug workspace for the developer community and I will talk about it a little bit later too but yeah, make sure that you check this but I will talk about this in my next slides. Yeah, so about the web and Android Academy and workshops one and two. Yeah, this year we hosted two online workshops as part of the DHS to Academy level one was held in March and level two in May. And now the goal of this academy is to make sure that the DHS to developers become familiar with our tools and technologies. That are available to the community out of the box whether it's mobile or web application. So the purpose of this is of course to share the most up-to-date and modern tooling that the DHS to core team is also using and share this knowledge with the entire DHS to developer community and to make the most out of this tools and make the life of developers a bit easier when they're developing their applications. So the new thing this time was that we had two parallel sessions, so the web track and the Android track. So for the web app in this workshop, the participants first learned how to get started building a DHS to web app from scratch using the app platform. Also learn how to use the UI library, the DHS to UI library, how to communicate with the DHS to way with the AI using the app runtime. We had a session on testing how to make applications more secure, performant and much more. And on the Android track, the participants learned how to use the Android SDK to build custom mobile applications and how to sync metadata and data, how to use validation rules and program indicators to perform data quality and analytic tasks and much more. So if you didn't have the chance to participate in the academy this year, don't worry because all the sessions were fully recorded and they are all available in the developer portal. And I'm again, going to quickly show you this. I did show you this page, but I'm going to show you how to find, if you want to follow along starting from workshop one, you have the Android track, and you have the links to the video. So these are links to the videos and also some slides. And then you have more advanced topics here, also divided in tracks, the one that we had in May. If you want to follow along some of the exercises, we have the web app repository here and you can follow along. So it's a great way to get started or, yeah, to get started using the DHS tools and yes. So if you have any questions, just feel free to contact me. And I think, yeah. So my next topic is about the developer community meetups. And, yeah, what are these meetups? So the online meetup is a series of online informal meetings with the DHS to developer community. And the idea is to get together and discuss any topic that's of interest to the community. And it's also a great way to get to know each other, virtually, of course, but it's a great way it's also a place where developers feel free to ask questions and chat with the DHS to core team and other fellow developers. We normally host this meetings twice a month and we choose the topic of discussions based on the feedback that we receive from the community through surveys that I share. And so far we have hosted five meetups since March this year and these are the topics that we covered during those meetings. So first it was about the newly renovated DHS to UI library documentation that uses Storybook to showcase these components. It was presented by Kai from the platform he's going to make a presentation a bit later so you will get to meet him. And the next one was, yeah, what makes a good generic DHS to application and how to use the data store that was presented by Austin, sorry. And the last two meetings were about, yeah, it was a demo of the Ab Hub and that was done by Wilk Janssen from the platform team as well. And the last one was about how to use Cypress and Cucumber and our DHS to utilities and commands to test applications. That was done by Yan Garga from the app platform as well, DHS to. So this is a very interesting developer outreach initiative as we've seen an increasing number of participants since we started in March. So we hope that the interest will continue to grow and you're all invited, of course, to come to our meet-up next month in July, which will be announced in the community of practice like the picture here shows on the right. And on the DHS developer Slack workspace that I'll talk about it a little bit. So yeah, keep an eye on those posts in the coming days. Yeah, so the Slack workspace, I have been mentioning this so many times and now finally I get to that. So why do we have Slack and what's the purpose? So in addition to the community of practice that we already have, this workspace is a good place to quickly share content. That's again of interest to the developer community, DHS developer community. So we share announcements that were also posted in the community of practice, events, some resources and other updates like the meet-ups, for example, it's also used for getting feedback. So to share surveys and to get anonymous feedback from the developer community to see what you would like to see, what you want to discuss or any features that you want the core team to work on maybe in future versions, et cetera. So this is a great way and it's also easy to communicate with everyone because developers are used to using Slack. So it's just easy to write direct message to get in touch. So we're very proud that we have a good number of 221. So today it's still growing. And of course this includes the DHS2 core team, but external developers are increasing every day. So I'm proud to say that this is the number as of today and how to join. I will be sharing the link, the invitation link on the chat or in the chat and Zoom. And if you are watching this recording, you can go to this link and on the developer portal, you can find the title here is Slack Workspace and you can fill out this form. And then I get an alert and then I send an invitation very quickly. So just make sure that you do that. If not, I will share the link in the chat and you can join the Slack Workspace as well. So what's next? So this is my last slide. And before I wrap up, I just wanted to share what we will be working on and ask for the developer portal. As I mentioned, we will be adding more guides, more tutorials, more documentation and also add more functionalities like search bar and translation functionalities. And we're planning on adding more Android documentation as well. So that's coming up. Contributions are welcome. This is something that I will be sharing Slack or in the community of practice. It will be very easy to contribute to the developer portal if you want to. If you find something that is not clear or you want to add a guide that you think it will be useful to the community, you have to feel free. The only thing you need is a GitHub account. You create a full request on our repository and we will review those and then add it to the developer portal. So feel free to do that. I will share a guide on how to contribute as well in the Slack workspace in the community of practice. And then as for meetups, yes, we're planning on having more Android topics. So far we only have been talking about web applications. So we were looking forward to having more Android things and also we're working on having self-paced courses in addition to live and virtual workshops that I spoke about earlier. So this will be a great way of introducing new DHS to developers to our community. So we are working on that. And then other initiatives, again, we highly encourage you to share your opinion and feedback during, I don't know, these meetings or on Slack about anything that you think could benefit the developer community if there's anything that you would like us to cover. Feel free to let us know. And then with that, I think I hopefully I covered everything I wanted to say. And I think I'm not sure who's next, but I will stop sharing my screen and feel free to contact me on Slack or the community of practice or by email. You can see my email there. And yes, I look forward to seeing you next time. Thanks a lot, Deborah. Really great to see all the growth of the community of developers and especially the material that we have to support that community. And we would love more feedback on that as well. So please share your feedback, join the community. We'd love ideas for how we can better share resources, what resources are missing and all of that as well. So please reach out to Deborah and join the Slack group to learn more about that and to share your ideas. I'm going to now move on to talking about the application platform. And I did see that there was a question in the chat that will hopefully be addressed by this next presentation slightly, but I'll address it directly in the questions section at the end as well. Here is, there we go. Let me make sure that you can see this. Okay, so Kai and myself will present some updates on the web application platform and where it's going from here. I'm not going to spend too much time on the platform itself. There have been some great updates that have come out in the last year since the last annual conference. I talked about a few of them in the opening what's new section on Monday, which was very quick, but I will go over them quickly again. And then I'll turn it over to Kai who has the more interesting presentation. I think you all enjoy what he has to say. First off, just a very quick review. What is the application platform? Generally it is trying to extract as much as possible of the common elements of DHS to web applications. So that those applications can be easier to develop, easier to maintain, more consistent to use for DHS to users, easier to update, easier to interact with other applications on that platform. In technical terms, we have what's called an app shell that provides a lot of common services to an application. And then we have the core kind of functionality of that application itself, which is getting smaller and smaller as the app hub gets more and more robust. And we use that application platform not only for our own core applications, but also for applications that the developer community creates and shares with either uses for specific implementations or shares through the app hub to be used in other implementations around the world. There are three major components of the app platform. The first is what we call app scripts, which is developer kind of build time tools for developing, building and publishing an application. We have a runtime that is used to talk to the DHS to server, show alerts in a consistent way and interact with other components of the DHS to ecosystem in the browser in the application itself. And we also have an extensive UI library in React that is implementing the DHS to design system and has a comprehensive set of building blocks that you can use to build up your application and build it in a way that is familiar and accessible to users of DHS to so that you don't have different interfaces for every single app that is on the DHS to platform. And we'll talk a little bit more about some of the new things that have been developed in all three of these in a moment. I also wanted to quickly mention the new DHS to app hub. It's been completely redesigned and we also have redesigned the app management application which will be released shortly. The app hub now supports organizations. It now supports continuous delivery from continuous integration pipelines so that applications can be more quickly deployed and published to that app hub and used by implementations of DHS to in the wild. It has GitHub authentication. It also has a lot more and better more accessible details about the apps that have been updated uploaded there where their source code lives, what versions are available, who the developer is, what this application does, all of those types of things. This gets into addressing a little bit the question that was asked in the chat but we also have a review board that reviews submissions to the app hub on a weekly basis. And we have published a set of guidelines that we analyze those applications against. Those applications are, or those guidelines are available at developers.dhs2.org. They're also linked, I believe, from the submission page on the app hub itself. And the key requirements or guidelines that we use to analyze applications that are submitted to the app hub is that the apps should be useful and generic, useful and appropriate, apologies. They should be generic and open source and they should be well-designed and documented and they should be secure and performant. I'm not gonna get into too much of this specifically. I talked a bit more about it in the session yesterday about the new app hub and the app management app and continuous application delivery, which we're also utilizing in the core team to more quickly release fixes and features for applications on the DHS2 platform. You can watch that video if you want to learn more. There have also been many improvements to the platform itself. I'm highlighting here a number of new components to the UI library that have been released. One that isn't mentioned here that was just released very recently is the data table. And we have some new ones coming very soon, like an updated sharing dialogue updates to the org unit tree and a few other exciting new UI components as well. We have also introduced standardized application alerts so that the alerting mechanism used in every application should be consistent. And this is a pretty big one that we're rolling out but we've introduced server version detection which allows a single version of an application to support multiple versions of DHS2 and to turn on and off different parts of the application based on the functionality or the features that are available in the core DHS2 server version that it's talking to. So this is a really powerful tool to reduce the maintenance cost of maintaining server or application versions over time because you can support multiple versions with just a single application rather than needing a separate version of the application for each DHS2 server version. These are a more comprehensive list of some of those features that have been introduced to the application platform. I mentioned yesterday that we also have a deploy and publish commands available in the command line interface for the application platform app scripts. This allows you to just with a single command publish your application directly to the app hub which now supports API keys for continuous integration. I mentioned several of the UI components that we've introduced recently. We also have a number of runtime improvements that make it easier and more consistent to interact directly with the API. There's a number of things coming soon. This is a non-exhaustive list but we will soon be introducing native plugin builds alongside applications so that applications can expose a plugin as well as a full-blown web application. Initially that will target analytics plugins for the dashboard but we're also working on allowing those plugins to serve as tracker capture or capture widgets to be able to support custom ways to do data entry for particular use cases. And that should be using a common technology to push that forward. We're improving our support for feature toggling which I mentioned earlier, progressive web apps which Kai will introduce in just a moment. We also are working on data caching and offline data. Kai will talk a little bit about offline data but we'll also have data caching within memory within a particular session for an application which should significantly improve performance and have some benefits for the usability of an application as well. More UI updates are coming soon and a big one is token authentication as well which will remove the need for cookie-based authentication for applications and it'll also hopefully allow for more fine-grained control of what certain applications can do. If you're familiar with OAuth or using something like connecting to Facebook oftentimes you give certain permissions to Facebook or to GitHub when you authenticate a separate application against that core authentication system. And so in this case, you could say I want to install this application and I want this application only to be able to read these certain types of objects or write to this configuration maybe to be able to write system settings for instance and that will allow even if an administrator user can log into an application it will allow that application to have fine-grained permission controls based on what that application is designed to do. With that, I'll turn it over to Kai to do a very cool presentation on progressive web apps and what that means for DHS2 web applications. Kai, do you want to share your screen or do you want me to continue here and you can just tell me when to move? I'll share. Okay. Yeah, thank you for the introduction and I'll try to be pretty quick be conscious of the time. Let's see, I think I'll share my whole screen. All right, here we are. Let me see if I can hide this. Great. So yeah, my name is Kai. I'm a front-end developer on the platform team. I've been working on some features to enable progressive web app features in the application platform. And so a progressive web app is an app that is a web app that is installable like kind of like a native app. You might, it's kind of like installing an app on a phone, for example. On a phone browser, you might have seen the option like save this app to my home screen. That's a progressive web app feature. And the main thing that we're supporting is offline capability. So you'll be able to visit the app and look at data while you're offline, which can be a big thing for users who often need to go out into the field where there's no network connection. So these features are enabled by a web manifest, which is just a file that has some metadata about the app that is used for its installation information and a service worker, which is it's like a program that runs alongside the app that has access to the network traffic that goes to and from it. And it has the ability to cache data and serve that from offline. So like source data in the user's browser storage. So in the platform, we're adding support for those features. All apps will get a web manifest for the installability. And you can opt in to using a service worker to provide offline caching. You'll opt in using the d2config.js file in your D2 app. There will also be cacheable sections, which I'll describe more, but they'll be used for caching particular sections of an app without caching all of them at once. And there'll also be a tool for accessing the online status of the app, which will be useful for providing different features if you're online or offline when you're making an app. So just to describe the details of how the apps are cached for offline use, when you opt in to the PWA features, the service worker will install when you run the app and it will download all of the static assets that are included in the built app. And those will be served directly from the service worker, which will provide a significant performance benefit on loading the app up. And that'll be things like scripts to run the app and style sheets. And other data that's used to run the app, like say, for example, system information or a user's dashboards list will be fetched over the network. And whenever that happens, it will be added to the offline cache. So you'll get the most up-to-date information possible, but then if you go offline, it will still be there in the cache and you'll still be able to access those things. So I wanna talk about the dashboard app because that will be the first core app that uses these PWA features and has a kind of unique requirement that informs the cacheable section features that we're adding with a suite of PWA features in the platform. And so I'll just go to the dashboards app now and show that currently an offline capable dashboards app is under construction. And what that will look like is that you'll be able to load this app and you'll see the shell of the app available here and the dashboards list. And those will be cached by default, but the dashboards themselves and the content within them won't be cached until a user requests to do so. That's to save storage from caching all of these dashboards. And so normally when you do that, if you know all the data dependencies for this section, you just fetch all that data, save it in the cache and it's good to go. But the dashboards app is a little bit different because it doesn't know all the data yet. It needs to load these plugins and plugins will make their own requests. So we've made a React API for a cacheable section component and a company hook that adds some controls for those components that will wrap this component. And when you click to save it offline, it will reload that component. I'm sorry, let me log in. And it'll tell the service worker to start listening to all the network traffic that comes as it reloads that component. And so it'll capture all of that data for that section and cache it online or cache it for offline use. And then when you load the app again and request this dashboard, all of that information will be there. So the dashboards app with that feature is currently under construction right now, but I have this little demo app here that kind of emulates that kind of behavior. I have this little list of visualizations that reloads or that loads incrementally, kind of to emulate the incremental requests that come from plugins and then the plugins make more requests. And it's running a service worker here and we can see the online status. Right now we have this information cached. And so if we go offline, we can still see we have the app and all of the information. If we go back online and remove that from the cache and try to reload. Oh, sorry, let me describe some other things about this app first. So the service worker is storing and serving the app shell here. In the D2 config for this app, we have PWA is enabled and to emulate the kind of behavior that we would use for the dashboards and omitting content until it's requested by a user to save offline, we're not caching visualizations by default. So when we look at the app and go offline and the section isn't cached, we can see that we get the whole app, but not the visualizations yet. They haven't been cached. And if we disable the service worker, we can see what happens when you're normally offline, which is that you don't get anything. And so if we go back to using the service worker, we get this status. When we're back online, we can record this section for offline. So we use that cacheable section API to signal that we want this offline. We cache it, we see the last updated time and then we can go offline and we have all of this information like a dashboard that we might wanna take out into the field. So that's great. Pretty soon we'll release a beta version of the dashboard's app with those features to test out. And I'll just recap a few of the features that we're providing. So we'll have the service worker that provides offline caching if you opt into it, the web manifest for installability. We'll have the cacheable sections and recording mode API that serve from the runtime. You can filter out URLs that you don't wanna cache until a user specifically requests to do so. And you'll have that online status hook. Those are the things that'll be available. And coming up next, we'll have this dashboard app that uses those features to give you the ability to take dashboards offline and use them without a network connection. We'll add some improvements to caching, including normalization, which will reduce the amount of storage requirements for the data that's stored. It'll increase performance and potentially enable sharing data between apps. We'll also add encryption so that these features are suitable to use for sensitive data. And then maybe in the future, we'll add some more PWA features like syncing the saved data in the background. If you come back online, the app will fetch the newest information that you need so that you don't necessarily need to look at it to have the most up-to-date stuff when you go back offline. And then preloading content, maybe so that you can visit an app and the whole thing will be available without having to browse to each page, for example. So that's all that I have for the PWA things. I'll be happy to answer any questions about those things if you post questions on the community of practice and I will hand it off to the next presenter. Thanks. Thanks, Guy. Really cool. We are running a little bit short on time, so I'm just gonna turn it straight over to Victor to talk to us about the Android SDK. Remember that if you post any questions in the chat or in the community of practice thread that has been linked by grant, we will get back to them after the session as well. So please post any questions that you have there. This is exciting stuff. Go ahead, Victor. Okay, thank you. So I think you can see my screen, otherwise please send me. I'm Victor Garcia, I'm from the Android team. I'm from the Android, I'm from the SDK component. So now I'm going to talk about what is new in the Android SDK in this last year. But first of all, just in case you don't know what the Android SDK is, I just have a few words about what it is. So if we take a look at the big picture and we have the server here and the Android SDK here and then the official Android application. So the Android SDK is the part of the Android application that interacts with the server. So it means that all the interaction with the API all the changes in the metadata and the compatibility with different ADS2 versions are managed by the Android SDK. So all this is offered by the University of Oslo. They are products that are available for you. So on the purpose of the Android SDK because it's a separated library within the Android application is to facilitate the development of new Android application using the Android SDK. Oh, sorry, yes, to the end. So if we take a look at the timeline, the Android SDK was released like one year and a half ago. And in the meanwhile, we have had four versions. And since the last year, we are aligned with the core team. So we release a major version every time the core team release a major version to ensure the compatibility. So now we are in version 1.4, then this one is going to be 1.5 in the next semester of this year. So very quickly, just a minute to explain what it is. And then we will, I will talk about the updates in since the last Android conference. So what it does, it manage the synchronization of both metadata and data. So the application is able to work completely offline. It also offers the data in a developer friendly way. So it means it has handy methods to read the data, to create the data and type safe also. Or the compatibility with different VHS versions because in every VHS version, there are changes in the metadata in the model and the API. So all of that is encapsulated by the Android SDK. So the application does not have to care about that. Also error management in synchronization and integrity check. And in some cases, online interaction because the application is intended to be used in an offline mode, most of the cases. But for some particular functionality, it offers the capability to work online. So what is new since the last conference? We have the support for the Android Settings app. This is a web app. If you don't know about this app, it gives you the opportunity to control certain parameters in the application. Like for example, the number of TI that you want to synchronize, the periodicity of the synchronization or also if you want to encrypt your database or not. So all these parameters can be configured here in the Android Settings app. This is a web app available in that app. And they are consumed by the Android SDK. Encryption as well. So by default, the Android application already had quite a strong security. The applications are isolated from each other. But in case you need an extra level of security, you have the chance to encrypt the local database, the device. Also the parser, this is quite a big thing. And there is a library, the parser library that is served between the backend and the Android team. So it ensures that all the expressions are parsed in the same way. And I'm talking about from indicators or validation rules or a data set indicator. So this is quite a big improvement in the quality of the application in both sides. Local TI analytics, this is more or less the same kind of analytics. Well, quite similar to analytics that you can get from the event report web application. But in the scope of a single TI. So using this functionality, you can, for example, see the evolution of an indicator or another data limit in a repeatable state in our TI. Working list support as well. And OpenID, this is quite new and will be available when 236.2 is out. And is there the ability to authenticate in the test using Google. So far, just Google accounts. And what is coming? I said that we have some kind of analytics in the scope of a single TI. In next version, we're wanting to improve the local analytics and give analytic values across programs and also for aggregated data and also give support for visualization. So a certain kind of visualization can be evaluated using the SDK. Some utility methods to evaluate logic that is just pure due to logic. Like, for example, when an enrollment or an event can be edited or not. Think of that, break the glass, support. That is an extra work. Yeah, and in the roadmap, more in the meeting term, we have multi-user, multi-server, because so far, the SDK can only be used by one server, one user at a time. And also, widget or UI component for Android. Because there are so many things like there are three or value type forms or the rendering types that are common for all the Android applications. So it could be good to have a common library for that. Yeah, so this is the Android SDK. This is the new things that have come in the last year. So the key idea here is, yeah, the Android SDK is a product that is evolving quite fast. Now we are focused on incorporating more kind of analytic features inside that. So, yeah, if you are thinking about building a custom application for any, because you need that, please consider the Android SDK as an option for that. And I think, yeah, we are almost running out of time. So that's all from my side. I don't know if we have some time for questions or we are. I think we're pretty close to out of time, unfortunately. Thank you very much, Victor. That was a great presentation on the Android SDK. Hopefully we have some people that are interested in using Android for data collection or anything else. And building on top of that Android SDK for extensibility in the field. Just wanted to quickly close and say that we do have a number of additional initiatives to kind of bring extensibility into the core development, not only building these platform tools upon which other application can be built, but you'll see more of that coming soon. And I'll talk a little bit about that in the session on Friday. And we also want to work towards building more sustainable models for generic applications to be shared among different instances or implementations and how the maintenance of those applications is addressed over the long term. Again, we'll address questions that come up in the community of practice. But with that, I think we have to wrap up to give time for people to move on to the next session, which I believe is a meet and greet in gather. So Grant, does that sound right? Is that the next step? Absolutely. Yep, I was just gonna share my screen. Wrong thing. Yep, so it is now the expert lounges and meet and greets all over in gather. If you haven't used gather yet, please do. You can come and find me. I'll be hanging around the Tetris battle. If you wanna come and have a game at Tetris battle with me, or if you wanna come and join all of the different sessions we've got going on. So we've got some on LMIS, we've got some on predictors and advanced indicators, and then tracks or aggregate and program rules there as well. So do you come and pop in? Or if you just wanna come in and chat with some of the other participants on the conference, please do. I'll post the link to gather just in the chat now as well if you haven't had the chance to use it yet, then please do come on in. If I can open the chat up. And we're brilliant. And if we were in a conference, actual conference setting now, I'd ask everyone to give a hand to present us today to Victor, Kai Debra and Austin as well. So thank you very much everyone. There we go. Thank you, Peter. Thanks guys.