 So, data states. This is a pretty important topic because if we understand what is behind the data states and how is the SDK handling those states, we can start understanding how the SDK works and how is the workflow really with the SDK. So, the data states are a property of the data objects. That is just read-only states. So, the SDK will fully maintain this property. And there are like, bunch of these states. And we use it for synchronization. So, for example, we have the sync to post, update, uploading, etc. I'm gonna be all of them, I'm gonna see all of them. So, first of all, we have the sync state. That's when the element is synced with the server and there are no local changes for this value. So, you can change it at all and you probably just download the data. The state to post is when you have created this element locally. So, it does not exist in the server and it hasn't been uploaded that far. And the to update state is when you have some data that you have modified in your device, but it exists in the server. So, you have to update it. So, now we're gonna see the flow more or less. When you download the data directly from the server, the currently state is sync. But when you create this data on the database, then you have to post. Then when you make changes in the device, it goes to update. So, now when you try to upload the data, the state is gonna change and it's gonna be uploading. If it's modified before receiving any server response, the state is going to go back to update. So, for example, you try to upload the data, but it keeps uploading. You didn't reach the server because maybe you have some connection issues with the network and then you make some changes of this property in the device. It's gonna turn to update again. So, you have to upload the data again. But if you have a server response, you can have some error or some successful sync. If you have a successful sync, it's gonna change to sync. But you have some error, maybe you have an error or a warning. So, it's gonna change the state. When you have an error from the server, it changes just to the error state and the warning when you reset this warning. When you have those states and you make changes on the property, the state is gonna change again to update. So, you can come back here and upload the data again. Okay. We also have another state, which is relationship state, which the SDK only use this state for full filing a relationship to another TI event or enroll. And this only contains like basic information of this relationship, like for example, main properties, like the code, the name, display name, last updated, but it has nothing like enrollments, events or other relationships. And also it cannot be modified. So, it's just data that is there for full filing the relationship, nothing less, nothing more. And now we are gonna talk a bit about SMS synchronization. Later, we have seen this part, but here instead of going to uploading the state is changed to send via SMS when you try to send all the data by SMS. So, when you make some changes, it goes again to update, but if you have a response for the server, then you can have a successful SMS, which is gonna go to sync via SMS state. And if you make some changes, it's gonna go again to update state. Also, you can receive an SMS with an error and then it's gonna go to error or warning. So, if you compare this slide with the one we have before, we have add this sync via SMS state and we have changed the uploading state for the send via SMS. If you don't have any server that, so if you don't have a server that responds with SMS, you only are gonna have this first like this flow. In the skeleton app, we are just having these three icons. This icon means that you have all your data sync. This orange icon means that you have this data to post or to delete. And this one is saying you that you have an error or a warning in your state. If you are going to create your own application, it's better than you have each of these states linked by different icons. And that's it for data states. Do you have any questions about this? So, now we're gonna talk a bit about dataset instances. dataset instances is the name that we have for those combinations in the SDK of dataset period or unit and attribute option combo. So it's like a handy representation of existing data in the aggregated world. This representation is does not exist in the HS2. It's just a thing that we have in the SDK and it's also not persisted in the database but it's used directly for data approvals and use it in the dataset complete registrations. And it also includes some other information like the sync state, the value count and the display name for some properties. So that is an instance is an object with like this. It's like it has a dataset UIV display name, the period, period type, error unit, display name, also the attribute option combo UIV, the display name of the combo and the count of, so the value of the count. Also, you can see some examples here of that is an instances. So here we have a theory question. So we have this data and metadata, okay? And we have two datasets. The dataset A, we have a data element one and the data element two and the dataset B with a data element two and the data element three. Both of them are the period type is monthly. And here we have the data element table. The data element one has this period. The data element two has another period and the data element three has the same period as the data element two. And the data element one and data element two has the ord unit one and the data element three has the ord unit two. They have the same attribute option combo and those are the values. So the question is, how many dataset instances we will have? And remember that a dataset instance is a combination of a dataset, a period, an ord unit and an attribute option combo. So I'm gonna give you like one minute to think about it and then I'm gonna ask you again. So start thinking. Okay, some of you want to answer my question. There's no saying if we fail. Four maybe. We'll start. Are you, Dario? Yeah, I think maybe four. Okay, do we have any other answer? I can't be sure, but I think it's two. Okay, do you want to answer? Yosef? I think it is four. Four, okay. Nabila? If it is a dataset period for the unit and attribute option combo, then it should be four. So before, do you say? Before. Close. Okay. Julianne? I think four. Okay. So the right answer is four. I'm gonna tell you why. So we're trying to make combinations of those four things. We know that attribute option combo is always the same. So we don't have to take it into account and we have to see for those three dataset period on our unit, how many combinations do we have? Okay, so we start with the dataset. A have two elements. So we have to take into account this combination. For this data element, we have the same odd unit. Okay, so we don't have any, we don't have to take the odd unit into account, but we have two different periods. So we have for dataset A to different periods, it means that there are two combinations. So we have dataset A, the first period, dataset A, the second period, and the same odd units and the default attribute option combo. For the same reason, the dataset B has these two data elements. So we see that we have the same period. So we don't have to take into account this period. The attribute option combo is the same as the default, but we have two different odd units. So that means that we have two different dataset instance for the dataset B. They share the same period, but they have two different odd units. Do you have any question about my explanation? Okay. Question, maybe what will happen if we haven't defaulted the attribute option combo. If you mean, I don't think I get the question, but do you mean that if we have some other attribute option combo here? Yes, we have two options. Okay. If for example, this default was another attribute option combo, for example, we have default default, but the first one is a attribute combo one. Then the dataset A will have here two different attribute combos and here two different periods. So when we try to see the different, the different, sorry, dataset instances that we have, we have to take into account these two. I think that we are gonna have the same result because this data element will have always the same attribute option combo and this period. So we are gonna have the dataset A with a different attribute option combo and the dataset A with another attribute option combo, but it's gonna be the same combination, I would say. Is that right, Victor? Are you? I think it is, but in a particular case, I think so. Yes. If we have like more combinations here and more data elements, it could be like a lot more tricky and have these combinations could be more difficult. But for this, we have a method in the SDK that helps you with this dataset instances. In fact, you have a whole repository for dataset instances when you can just ask for these combinations and you can just print it in your screen. So now we have an exercise that you have to resolve.