 Can you see the screen Victor? Yes? Yes. Okay. So, and now in this session, I'm going to talk a bit about direct database interaction. So, well, first of all, the SDK has almost all the accessing that you want to access. So, to all the data that you want to really access, you have a repository for that. But in the case that you need some other needs for your application, some, and now you want to create a new queries for that, the SDK also allows you to directly interact with the database. So, yeah, for that reason, the SDK is exposing a database adapter, and with this database adapter, you're going to be able to query to the database directly. Also, all the models in the SDK include a method with name create. If you pass to this great method a cursor, it will automatically generate the object from the model. Also, the database has the table model, so you are going to be able to check it too. Here, I have the database schema. So, I come here. You can see, well, I think you can see it more or less all of the tables that there are storing are the SDK. If we go near to one of the tables, you can see that, for example, this is the attribute table, and you have the code, you have the name, display name, all these possible columns in the table. And, well, it's just huge, like you have a lot of information stored in your small device. So, to see what is the difference, the DHS2 has 452 tables into .32. Now, I will say that they have more near 500. And the under SDK has now 110 tables with a lot of properties, which is like a lot of information that you can use to show all the information to your clients, to your users. So, here, you can see an example of table info. So, in case that you want to know a bit about the structure, you can find in every class some information. This one is the table info, but you have for each table and object like that. So, you will have the program, table info, the dataset, table info, the attributes, table info. So, in this case, for the table info, you can find the name of the table, you can find some of the columns here, you have that the period have the end date, the start date, the period type, and the period ID. That is just an example. So, you can find all this information in the SDK too. In case that you want to interact with the database, you can access through this module. So, well, it's not a module, it's just the database adapter. So, you write D2, there's that there, and then you can execute all these methods here. For example, if you want to delete a table or you want to delete with a clause or you want to query some information, you want to execute or set a transaction, etc. So, you have here all the methods that this database adapter allows you. And here is a bit of a comparison of what you can do using the SDK repositories and modules, and what you should do if you are using the database adapter. So here in the very first example, we have the program module, and we access to the programs. And here we are filtering by program type using the program type with registration, and then we just call the get met. So that will return all the programs with this program type. If we want to do the same with a direct query, you can query, so go to the database adapter, and then query. Here you have the query, and then you pass the registration string. So, what this query method is going to make is, he will put a word, this is the symbol, the name of the string that you are putting here. So after that you're going to get the cursor, and then if you check that the cursor is not null, you can move to the first row. And then with the method that is in the object program, the create method, you can pass the cursor and you will retrieve a program. So it's more a bit longer, but it's not that complicated, because the SDK provides the create cursor. Without this method, it will be very, very confusing. So just try to use always this create method. And also, do not forget to close the cursor, please. Always close the cursor because if you don't do that, your memory will run out and your application will break. Here you have another query, a bit more complicated. Here we are using the event module to get an event. And then we try to use the Enrollment UID to filter the events, and then inside the equals of the Enrollment UID query we are searching for an enrollment which has this UID and is this program. So at the end, you're going to have the events for this enrollment, for this TI, for this program. So that you can do it in this block here if you're using the repositories, but you also can use a cursor query. But it's a bit dangerous because if you see the query here, just the select event from event, your enrollment on... You see that there is a lot of information here and you could commit some mistakes when taping and just one small character here will end up with a fail. So for that reason, we really recommend to use the repositories if you can do it, but you are free to use the attributes if you need it. In this sample, you are going to have to go to the cursor and then move to the first, loop the cursor and in each loop just create the event using the create method. So yeah, everything that we are talking in this academy is in this documentation, in the page docs.hs2.org. And for the direct interaction with the database, you can follow this link here. I would like to... Sorry. I would like just to remember that this class here, you create a method in all the objects is really, really useful if you are going to use in the modules. And that's it for this session. We are not going to make any... Any exercises? So now let's talk about the DSS2 compatibility. This is something that we mentioned in the first day and that the DSDK is compatible with at least the latest three versions of DSS2. So it means that you can use DSDK and you don't have to care about the version of the server. And probably you don't even know the version of the server when you are developing the application. So it is DSDK who deals with any modification in the web API, like a new parameter or some changes in the endpoints or whatever. So the process of DSDK is to encapsulate the logic, the changes, sorry, as much as possible by sending the data model usually. Sometimes the changes in the server are very big. And it is not enough to... DSDK cannot encapsulate those changes. DSDK has to tell the application that there is some changes that has to be done. Yeah, the one thing here is that if DSDK is responsible to notify those changes, so you don't have to care about unexpected changes that you didn't notice in the web API, it is DSDK who has to deal with that. And of course the changes in DSDK will be properly documented in the upgrade nodes. So in case we have any change in the DSDK that is a breaking change, we will properly document that change. So just for you to know what kind of changes we have had so far in the DSDK in this year and a half. So an example of a small change, a change that can be encapsulated by DSDK, it was a change between versions 229 and 230 in the program object. In the program object in 229 we have the captured coordinates property that was a Boolean, true or false. The coordinates were a point, always a point. And in 230 this property was removed and replaced by feature type. And now the feature type can be a point, a polygon, a multipolygon, or none. So in DSDK we adopt the new feature type and also keep the previous capture coordinates. And we can do kind of a mapping here. So we can map between false and none. And then between true and capture coordinates to point in the feature type. So in this way, we don't force the applications to update to the new feature type. So we have marked the capture coordinates with the deprecated annotation. So it means that this property is going to be removed, eventually, maybe in the next version or in a major version. And it means that you should use the feature type property. And if you are working with a 229 server, you can use the feature type property and DSDK will do the translation. So this is an example of a small change. An example of a breaking change was the change in the relationship model in 230. 229 or up to 229, a relationship where between a TI and a TI always. Now in 230, the model change. And you can have a relationship between TI's enrollment and events and TI's enrollment. So the model is completely different. The approach here was, well, let's suppose we have an application 1.0 that is using that is compatible with 228 to 229. Then 230 appears and the model has changed. So in order to create a new version 1.1, that would be compatible with all of them with 230, 229 and 228. In this transition, the app will be forced to do some changes in the code. In this particular case, the application in 1.1 will use the 230 model, I mean the new model that is more complex. So using that model, DSDK can translate to 230 and then to 229 and 228. So you can use the same model with all the three versions. But it's important here that the change in this case implies some changes in the app. Okay, and this is very related to the strategy to manage upgrades in the server. So let's suppose I mean you want to, you have an application on 1.0 and you are using 232 server. So what would be the approach to upgrade the server? In case you want to upgrade the server because you want to upgrade to 233. In case the process would be in first place, upgrade all the application in the field because you know that upgrading the applications all the end users can take some time. And even if the connection is not very good, maybe it can take some weeks, for example, to update all the devices in the field. If the project is very large that can take a few weeks and it's normal. In first place, you can update the applications. It doesn't matter if there are some users that are using the 1.0 app, other users that have already updated their application and are using 1.1. You are still in 232 so all the users can still work because 1.1 is compatible with 232. And only once all the users in the field have updated their applications, then you can move to the 233 server and the application will continue working because 1.1 is compatible with 233. So there will be no interruptions in the work. So this is the way in the way that the compatibility strategy can help in the server upgrade. Okay, any questions about this? This is just a small regular session for you to know how it works. So now let's talk about the roll map for the next version. We are in 1.4. We have seen that in 1.4, we had some basic analytic features. Now, for the next version for 1.5, we want to extend this functionality because now we only have basic analytics about even line list analytics in the context of a TI, mainly, parameters that are evaluated in the context of an event or a TI. Now we want to have parameters evaluated across all the TI or even indicators for aggregated, evaluated in a wider context. So this is one of the things that are coming. Also, we want to extend the utility or logic method. And we have talked about the event service, the enrollment service, some helpers that are there already. But there are a lot of things that have to do with the VSS2 logic that we, the DSDK should care about that. There are more helpers being in services to identify if the server is connected or not in a more reactive way. Also, validation of the data entry, we are working on that to validate if the value provides for that specific value type is correct or not. What about tracker? I don't know if you are familiar with this functionality, the break the glass. The break the glass, this thing that is, yeah, is an amazing thing because it allows you to hide some TI depending on the context or unit and the access level of the program. But this also introduced some complexity when dealing with permissions. So this is not implemented in the SDK yet. So basically, the TI that are behind the glass are hidden, we cannot see those TI. So this is something that is coming in the next version. This is 1.5. And also it involves all the flow to get a specific consent to download the TI. I mean, a reason why you want to access that particular TI. And also the consent to upload the TI. That's something that is coming. The topic that was mentioned like, well, almost from the beginning of the SDK is the possibility to have support for more than one user. Because now when you are using the application and you log in with a particular user and then you log out and you log in again with a different user or a different server. The previous one is deleted because the SDK only supports one user at the same time. So this is something that we want to introduce, the ability, the capability to have more than one user or the same user connected to more than one server. That is a common use case when you have an instance for aggregated and another instance for tracking. Also, yeah, we want to explore the widget thing. I mean, there are a lot of things that probably any Android application will have to implement at some point. For example, the organization unit B, the organization unit three is probably any application will have to do that. It's a very common thing, or the rendering of the value types, for example, for the date or for the file. There are a lot of things that can be served between applications in the form of widgets or UI components. Yeah, this is something that is in the roadmap as well. Yeah, and also we want to introduce an improvement in the synchronization process. And when it comes to metadata, we have seen that there is just a single method to trigger the load of the metadata and need download all the metadata that is relevant to the user. But maybe even if the user has access to all that metadata, for a particular use case, you only want to download, I don't know, a particular program. You know, in advance, or, I don't know, you have parameters, I have how this program in the server, I don't know, or you want to be more selective in the download. And even think about this online offline thing that may, because maybe we mainly work with the data that is in the database of the device in an offline mode. And we have a repository that combines online and offline that is the tracking things that search, you can search both online and offline. And we have this thought about extending this feature to all the repositories. And maybe you don't want to store tracking entities in your device, because you are sure you have a very good connectivity. You are in a hospital and there is Wi-Fi in all the hospitals, so you can work online always. So maybe this is an option or you want to update the program every time you access the program and keep a local copy just in case you have lost the connection. I don't know, it's something to explore. That's all. Well, last thing I just want to mention is about Kotlin, the Kotlin thing, because the SDK is mainly written in Java, but now we are moving to Kotlin. All this academy has been written in Java, but probably, I don't know, we could be moving to Kotlin at some point. Yeah, that's all for the roadmap. Any question or any comment on any suggestion of new features, we would really like to know our new features, new requests, something that you missed in the SDK. Anyway, if you have any comments or any requests for new features, you can use the Slack channel as well, but it would be nice to know you have more ideas about things that we can add to Kotlin.