 So my name is Jose Munoz. I am the Android technical lead. And I'm going to introduce to you what is Android SDK, what we have so far, and what is coming in the coming future. So what the Android SDK, what it is, sorry. It's basically a common good that allows for any Android applications to work offline as it has an internal database. It supports the communication with the H2 instances and facilitates the development of Android applications with sharing some libraries and codes. So basically, we said that the H2 is not only a web application, but it's a platform that has a public API. And then we have the Android SDK that is being implemented by the UIO Android official application. And the communication happens all the time between the Android SDK and the API. So the Android application never goes to the server, never contacts the server, but it always does with the SDK. This is one of the goals. Another goal is allowing the dev community to use the Android SDK in order to build their own custom Android applications. So this is quite a new product, I would say. The first release has been published in December 2019, the 1.0. And then, let's say, every four months, we are publishing a new version in April 2021, August 1.2. We also had a patch release. Patch release means that there is a new version which doesn't contain new features, but mainly backfixing and some improvements there. And the current version that is out there is 1.3. This one is being also implemented now by the current Android application, 2.3. And it's compatible with 2.35. The other 2.35. That's in February. We have released, like a week ago, the 1.3.1 version that is basically 1.3 with some backfixing. The good news is like in April, we are going to have a new one that is 1.4. This is going to be used by the new Android application that is going to be published as well in April. And of course, compatible with 2.36. So basically, we are moving from a four month cycle to a six month cycle. So this means that we are the same as the DHS2 core. So we are trying always to be in sync with the DHS2 core. And making for the users that are the developers that are using SDK fully compatible with the new SDS2 version. So next one in April and next one, 1.5 will probably will be published in October when 2.37 will be released. So what the SDK contains starting from 1.0 going to go a bit fast with this part? But it does many things. But the metadata sync, it don't know all the necessary parts of the DHS2 model, like the programs, datasets, or units, in order to render entry forms to let the app to work in offline mode. So it also downloads as synchronized data, of course, data sync that goes symbol size, downloads data, and upload data as well. And of course, the size of the database, the local database of Android is more limited than the one that we can have in the server. So we have some parameters here in order to play with a little bit with different options. So the most important one is the total number of TI's or events that we can download from the server. This number can be global, or it can be linked to a particular unit or a particular program. So maybe you want to download 200 TI's for a malaria program, and then you can download 400 TI's for an HIV program. Also, as we are going to discuss in a moment, we also have what we call the Android Settings web app for fine tuning different parameters for desynchronization. We're going to see this in a moment. So metadata sync, data sync, and also, of course, we have a lot of database. And then if people, if they're developers, they need to retrieve the data. They don't need to know, like, or to build complex SQL sentences, or they don't need to know the database schema, because it already contains more than 100 tables. So it is quite complex. But we have an access layer that encapsulates all this complexity for you. So basically, it's like an Ivernate layer that, using programming, you can get the information that you need, quite easily. Then it's really important supports for last DHS2 versions. At the very minimum, we are always guarantee the compatibility with the DHS2 current version and two previous versions. But certainly, we're trying to do this with as many versions as we can. So for instance, the first version, 1.0, as you have here, it was compatible from DHS2.229 to 233. This means five DHS versions. And the current one is compatible from 230 to 235, six versions. And when we synchronize, when the SDK synchronize, it automatically detects the DHS2 versions, the core DHS2 version that is syncing to or from. So this is challenging. But I think that we have now a good foundation to continue providing support for many versions. In this case, we're talking six versions that is more or less like two years and a half, or having compatibility with different DHS2 core versions. And what else? Something that is really important, error management, especially when you are syncing data. So as you know, you are developers, so most of you are developers, so you probably know this. There may be some issues with the conflicts that the server may have when you are synchronizing data. And here, we have managing the granularity at different levels. It can be at the PI level, event, enrollment, or attribute, or a conflict in a particular data element. So all this is like a retrieve IDPI and it's stored in the SDK. So in a way that you can, the Android developer, the SDK user can decide how to present that information to the end users. I think that that one is for a particular important integrity check. Sometimes the API delivers data with misindependencies, like for example, the data value is not linked to a data element. Or I can think of as well a program variable that is not linked to a data element or an attribute. So all these misindependencies, we are managing them in the SDK and we're removing all the errors that we may have from the API. Online search, whenever your device is online, connected with internet, we also allow the online search. In this case, we are taking the search of unitary for allowing to do these kind of operations. OK. The separate DI unique attributes, if you are, if the Android user is going to be or flying for a couple of days, a couple of weeks, we are like storing unique attributes as well in the local database. So you don't need to call the API any time you need it, but you can retrieve all this data that is already stored in the database. Database migration is really important. When you are moving from one version to other version, you are not losing data, OK? Because this migration ensures that they are compatible that the database scheme is going to upgrade to a new version, OK? And it works from any version to any version, OK? So in this case, it works from the example here. If someone wants to operate from 110 to 130, it is fine. So if you are building your custom applications and you want to upgrade and you are worried about losing your data when that's the upgrade, I think that this is a good reason to use SDK, OK? And what else? Now, this is quite new. From 1.1, we are also allowing desynchronization using SMS. In the case that you don't have internet, you can use the SMS to sync the IS events and aggregate it. Values. We are using a compression library that is being shared by the DHS2 core as well, and resetting SAP compatible. As I said before, this has been released. This app is in the app app. It's been released in October last year. And then here, you can define different parameters for synchronization. And then something very important, if you want to include your database of your Android devices, OK? So in mind that you are, for example, I mean, there are some programs that are more critical than others. I can think of HIV, for example. So you may need to include that information. So now you can do it, OK? You can do it. We are using an open source, an extension of what we call extension of schoolyt, that is called SQL cipher. And it's like a performance issue of 550% of overhead. Because then, of course, when you are in the data, you have to encrypt the information. But at the end, it's something that is for you here, for the community. If you have to manage very critical data, very sensitive data, you can encrypt now the local database, if you like. Important shared expression parser. We are like, these parsers, it's A and TLR, it's a grammar that is shared between Android and the core, and the VHS2 core. So this means that all the expressions with program indicators are going to be the same. In fact, since 1.1 and 1.2, we are like supporting most of the program indicators variables, most of the VHS2 functions, OK? And so you can define any complex expression in a program indicator that the SDK can handle it and can return a value. Because basically, we are using the same parser. And this is in with the validation rules, OK? In this case, they are only working at a dataset level, but you can trigger an exception, an error, if a validation rule, it delivers a false value. And what else? Utility classes, very important as well. This is coming from 1.3, and it's an ongoing process. The VHS2 may have some kind of logic that is a bit complicated. So before 1.3, all this logic was in the app, but now we are moving more and more of the logic, the VHS2 to the SDK. So for example, I can think of when you have to add an event or modify an event, and then you have all these logics that based on enrollment and the best status or the completion date, all this logic that can be a bit complicated. It can be automatically done if you are using the SDK. The same with rate of write sharing access, OK? You may have access, read access to a resource, but not have write access to all these complexities being managed by the SDK as well. So just like a quick summary, it's a common digital boot. It accelerates the development of VHS2 or flying integrated apps. So use it. It's the user for Android developers. It's written in Java and Kotlin. Users SQL it as the database. And it's a group effort. That's important. We are not working isolated. We're working together with the VHS2 backend team in order to identify what is the most useful endpoints, how we can be sure that we are letting the users, letting the Android SDK users and the app users to use the most efficient calls with the API, OK? So this is a group effort. OK. So this is the SDK, what we have now. And then let me introduce that this is not part of the Android SDK stack, but it's important as well to mention. As I said before, since October 2020, we have something that we call the Android Settings Web App that you can download from the app, the VHS2 app you have. OK, and this has this layout. And basically what this web app does is it defines different operations features, right? So in this app, as I said before, you can define if you want an Android device to have a database that is encrypted. In these settings web app, you specify if you want the SMS settings. In the case you are afraid of not having internet connections and then you need to synchronize using SMS, you can define the metadata scene. How often are you going to do the metadata refresh? Like it can be every day, every week, every hour, for example, and the data sync. In this case, how often as well, but also how much data. OK, we can have, you know, you can specify I would like to, for a particular program, I would like to download 200 TI's. And for other program, I would like to download 300, for example. And then all this configuration is also being stored in the SDK. OK, so I think that this is also very interesting in order to have more flexibility, allowing more flexibility in how the users can synchronize with a server instance. And what is coming now, we are going to have to publish a new version of the Android Settings web app to be released in April 2021. OK, that it will have a new layout, but also it will allow the user to define like other layouts for the Android app, like home screen or programs and datasets. How many filters do the user want to show them? Sorry, can the app show in these screens? Like, for example, in programs you are all interested in North Units or in Periots. OK, you can select that in the filter here in this application. OK, so I think that this will also create some flexibility in how different filters are being rendered in the Android applications. And then analytics. This has been already quite a lot demanded by the community having analytics that works in Android and works offline. OK, so now with the Android Settings web app, you can define this in the TI scope, OK, enrollment scope. So basically, we can define like bar charts, line charts, people tables, what are the data elements that you would like to show or the attributes that you would like to show in bar charts or program indicators in this kind of items. OK, and I'm telling you this because this is being defined in the Android Settings web app, but then it's being consumed in the SDK, OK? So this is the third map. This is what we are going to have in two months, OK, starting by local analytics. So local analytics, they're going to be able, the SDK is going to be able to restore some configuration for performing local analytics in 1.4, coming up in April 2021. In this case, what the SDK does is reading all the configuration that has been stored in the, using the Android Settings web app, it's being stored all the configuration in the server. OK, and here you have some examples. This is something that is already happening in our tests, OK, in which we are showing here, like some program indicator with some values, we are showing here some charts, OK? And this is what it does, it calculates all these values over here, but also stores the information about how to render different items. So in this case, we are rendering this as a line chart. So all this configuration is being stored in the SDK. And the SDK know how to plot these points over here, OK? So all this information is being stored in the SDK. So that I think this has been challenging, but it's going to be there in April 2021. Also calculations across TI sun events. Now it's going to be only again the scope is at TI, but then in 1.5 that is going to be probably released in October 2021, we want to allow also calculations across TI sun events, OK? One thing that is also there is that the set indicators is coming up in 1.4 now in April 2021. And with all the values of an indicator that is linked to that asset. Utility, logic, method classes, it's an ongoing process. We are moving more and more and more logic to SDK to be able to validate that entry. One thing that we believe can be interesting is also offering some kind of ping services in order to let the other application know if a particular server is up and running or not, OK? So we also can plan to have these ones here. Breaking the glass, this is not currently supported in 1.3. It's going to be supported in the next two months. Working list, also it was very demanded by the community. In 1.4, we are going to be supported with one for both event working list and track it into the instances basis working list, OK? And we have an example here, OK? In this case, the working list, you know, that there are working lists at the end is a filter, like a filter that has been defined and stored in the server side, OK? So here we are downloading those filters and storing them in the SDK so then the app can render them. So in this case, we can see there are like three working lists over here with the TI. This is for a malaria program and maybe you would like to have a filter, a working list of these cases that has not been yet assigned or events. Or I would like to, like, filter by the events that has been assigned to my user and so forth, so forth, OK? So coming up in April 2021, authentication, also, we have been very demanded by the community. Not only now, we are only allowing like a basic authentication, but we're going to allow OAuth and here we can. We are working on the backend with the backend team to achieve this also open ID, OK? What is more things that are in the roadmap, multi, but not for now, maybe this one for the multi-user, multi-server, this more for the last milestone of the, sorry, last mile of the 2021 or maybe the beginning of 2022, like when you want. So there are some requirements from the community. They were saying that, OK, there may be like three users that are working at the same facility and they want to share the device without logging themselves or without deleting the database, OK? We are trying to do this as well, probably at the end of this year, beginning of next year, OK? And then the same with different servers. So if you are a user and this happens more and more in different use cases, you have like a server that is to store tracker data and a server that is to store aggregated data, OK? But then there is one other application, there is one user, and then with the same application you would like to have access to both without removing your database, OK? This is also going to be possible. We'll plan through that hopefully by the end of this year. More things that are in the roadmap, widget UI components, in this case everything now is integrated in the app. But now we are planning to have all the widget UI and the UI components separated in a model. So this can be reused by other Android custom applications. So then it means that many of the Android application that implements the SDK, they can have the same or less look and feel, OK? I can see, for example, in the unit three, this can be reused or any data element or attribute type or even the rendering types that we have in the application like checkbox or write the buttons or whatever. Last, what also we have is the metadata granular sync. Right now, we have data can be granular. So you can say, as I said before, I want to download 100 events from this program and 50 for this other program. But the beta data, you download everything, right? So there may be some use cases that you maybe need to download all the metadata the configuration for a particular area, but you don't care too much about others. That is something that we plan to do as well. But it's in 2022. And then something that kind of proof of concept, let's see how it goes, like having the app only working online, OK? In mind that you have that you are in a, I don't know, can be an hospital with a local network. And then you don't have like a constraint regarding the bandwidth. And you can be online, which means all the time, which means that the synchronization in both ways will happen in real time, OK? And instead of like storing in database and then sending the server, when it's like a configuring in the data testing instance, OK? So this is what we have in the roadmap. And I think I don't know if I can use two more minutes. I just want to go very fast with the resource that we have, OK? So we have an skeleton app, OK? So how you can start to build your own custom applications? You don't need to start from the blank activity because it can be a bit overwhelmed. So for that we have, for that purpose, we have created what we call the skeleton app that can be your entry point, OK? It's a very basic application, but already has all the, is connected to the SDK, it implements the SDK as well, OK? So you have the, you have link here, OK? This is the code. And then basically it contains, it has a master branch that is a basic project. It's just use the SDK and only for logging and download the metadata and data, OK? Only does that. But then we have use cases branches that is more advanced. And then you have here data entry forms with program rules. Data entry forms can be for programs or for data sets. And you will see how you can build your own data entry forms using this skeleton app, OK? So you can reuse as much as many code as you need. But then at least, at the very least, you will have an example with how you can do it, OK? And I'm finishing with the resources are here, this link with the source code, the documentation, with the skeleton data, a link to the community. You have new ideas if you are telling us that you need something for your project, just please write to the community. We'd like to have a message in the community, OK? So don't hesitate to write here. And like a final summary. So basically if you want your app to work offline, that is a really big undertaking. If you want the app, your Android custom app to be compatible with many DHS2 versions. And as I said, we are supporting right now like six different DHS2 versions. It's two years and a half of the DHS2 compatibility. Automatically, we're going to the new SDK version. Have the best performance synced with the DHS2 server, OK? Because many people are, OK, I am having a custom application, but then I have some issues when synchronization with the server, OK? If you have those issues, if you like to simplify the role management returned by the API, that can be a challenge as well if you are like using the API, OK? If you need or if you want to have the best support from the Android team, OK, because it's something that we are like working on this every day, OK? And many more features like programming indicators and validation rules. So if you want for your end, if you need, if you're in a project, you need to build a custom application, if you are interested in this, please use SDK. Do it because it may take an effort at the beginning. You need to learn how it works. You need to know how you can use that access layer. But at the end, at the end, it will save you a lot of time. And you will have an application that is going to maintainable for years, OK? So, yeah, I think that's all from my side.