 Yeah, we're going to learn how to make generic applications in the HIS too. Just going to quickly mention that, yeah, what we're going to cover. So for the first part, I'll start off by giving a quick overview of what makes a good generic application. And then I'll talk about what the requirements are. And then I'll briefly mention some of the approaches that you can take as you're developing your application. And then after the break, like I said earlier, Austin will expand on this introduction and talk more about how to actually use these tools that are available to you to be able to build a generic application. So you'll see how to use the Datastore and how to support translations in your application. Yeah, okay. So first of all, why are generic applications important or what does it mean to be generic? So if you have a generic application, it means that it can be used across different instances and use cases. So basically, applications that are flexible and generic are useful for a large audience and can help many DHS2 users and the DHS2 community in general. So that's why this is an important topic. So these are the three most important criteria that are required to have a generic DHS2 application. It should work on all supported DHS2 versions. It can work on any given DHS2 instance and it should support translations. I will talk more about these three points in my next slides. Yeah, version support. Okay, so you have to make sure that the app works in all supported versions. So this means that your users might not be on the same DHS2 version as in your application or as, yeah, they might not be on the same version that you're using. So you will need to test all supported versions to see if it still works. So the current version is supported, of course, and the last three versions before that as well. The current one was released last week. So just recently, which is version 2.36. And the previous ones that are supported are 2.35, 2.34, and 2.33. And you can check more information about this. Just I'm going to quickly show you where you can find. If you go to the websites, the DHS2.org website, you go to resources, and then you go to downloads. This is under court DHS2 software, this is where you can find the release notes and see which versions are supported and which ones are not. You will see that these versions are not. And if you check the release notes, then you can see if there are any breaking changes or any relevant things that could affect your application. So there are notes that you can read on how to upgrade to later versions. So then how do you do that? So if you want to make a generic application that supports all these versions, then you would, of course, start by testing against these versions and see if your application works as expected. And if you do encounter any discrepancies in the API, for example, or features that are not supported in an earlier version, but are supported in a later version. So then you could handle these discrepancies in the code base itself. This means that you keep one single code base for your application. So for example, you have a master branch and you can handle the differences between DHS2 and the application code itself. For example, if there's a particular feature that is not supported in an earlier version, then you could conditionally render this particular feature depending on the version that supports this particular feature. So the advisable thing to do here would be to handle all these differences within a single code base instead of having to maintain three or four different code bases for each version. I hope this was clear. Okay. So like I said before, a generic application should be able to work on any given instance. And here we have some of the best practices and approaches that you can take in order to do that. Maybe not everything, but yeah, I'm just going to touch upon some of them. We will talk more about application configuration after the break, but these are basically some of the dos and don'ts. So like it says there on the left, each instance is backed by its own database and ID, which means that if you hard-code the ID for your instance, this may work for you from your own instance, but it may not work on any other instances. So this is not recommended. As you can see here on the left, it says don't hard-code IDs. And what's recommended or the current best practice is to configure this information programmatically in your application when the application first loads. And this is when the DHS2 data store comes into play. So you can basically use the data store to store your data and configure those metadata IDs for a specific instance. Again, also we'll talk more about this in the second part. In addition to an instance having its own database, it can also have its own individual configuration. For example, one instance might have support for some features and another instance might not support the same features. So it could be great to check whether the instance that the app is currently running on, whether it has the correct configuration in place when the application runs. So yeah, it's better not to assume that things will work. So it will be best to let the user know something is not working on this current instance or allow them to request additional configuration if it's needed. So for an application to be generic, it must have or it must support translations of the interface in your application. And of course, this is a very important aspect of having a generic application as you would want your users to be able to use your application in different languages. And you can do that through the D2I18N package. And this stands for internationalization. This is a difficult word to pronounce and maybe that's why they abbreviate it. So what this tool does is that you can use it to translate strings or all the text in your application from English, for example, to different languages. And this package can also be used to translate dates and numbers into different localities. In the next session, you will learn more about how this package works under hood and more importantly how you can include this package or import it and use it in your application. Second small point here is just a small recommendation when using translations is that the name field is not translated for metadata only display name. So for example, if you use the field name in your metadata like org units, it won't be translated if you have translation set up. Yeah. Okay, I think this is my, yeah, I have two more slides and then I'll be done. So generic applications, they live in the app hub. I can actually show you quickly, but this is, yeah, okay, so the app hub is this is going to change the interface, there will be major improvements. So this is how it looks like today, but you will learn more about the app hub this Friday and what are the, yeah, the new updates and new things. So it's, yeah, you should look forward to it. Yeah, okay, so back to my presentation. So what is the app hub actually? So it's a collection of applications that are generic and that have been published by the DHS2 community. So you can find applications that were submitted by other developers, organizations and the core team as well. So this is where you can go and find applications that you might find useful and also submit your applications, of course. And these applications are reviewed every week with the DHS2 core team. But again, you know more about this and the app hub guidelines and all these things on Friday. Okay, so this is just to introduce some of the tools that we will see the second part. First we have the data store, sorry, yeah, the data store. So as I briefly mentioned, you can configure your application information using the data store endpoint to store specific JSON data for all users. So for example, if you have application, sorry, for example, if your application offers some kind of user preferences, then that would be the ideal place to store that information. And then the user data store endpoint is would allow you to store user specific data for the current user. You can find more information on the DHS2 web API documentation to learn more about this endpoints and things like namespaces, keys and values. And I think, yep, this is just an introduction again. But then there's also the app service data store package that is available to you to interact with both this endpoints. And you will learn how to install it, how to include this in your application later on. And then in addition to this, we have the data store management application, which you can use as well to configure this data using this app, which can be very, very convenient, very handy. And then lastly, I briefly mentioned earlier about the D2I18N package that you can use to support translations. So you can use this library to do that. One thing to note about this tool is that if you have initialized your application using the application platform, or if you started your application using the app platform, then we saw this in the first workshop, then this tool is already included in your application. So if you use D2Obscripts init, the command from your terminal to create a new application, then when you run YarnStart from your terminal, then you will see a folder with the name, a folder that's called I18N in your project that's generated automatically for you when you initialize your application. So you don't need to stall this separately or set this up. It's done for you. Yeah, but you'll be able to see these folders and what's generated when you do that. There's a template that's generated and you will see how to do that during the exercises. And I think this is, yeah, this is all I have.