See your own channel with videos hosted in your computer!
This Android TV application allows you to watch videos hosted on your own computer on your TV.
This application requires downloading the mo-channel-server executable on the machine where the videos are located in order to be available to the application.
 |
|
| This is the app when you open it for the first time. Since the Server URL is empty, it opens the settings to input the Server URL. If you are running the server on your computer, you'll need to input the IP number the server will tell you, along with the port number. | |
 |
|
| Here is the screen with some content registered. In this example, you can store concerts you've recorded on your computer, run the mo-channel-server, and input the URL in the settings. | |
 |
|
| This is the page when you press on one item. It shows the 'episodes' per 'season'. Episodes are the videos, while 'season' refers to the subfolder where you put the videos. |
| Technology | Purpose |
|---|---|
 Jetpack Compose |
Design UI |
 Exoplayer |
The video player used by this application |
 Room |
Persist application data |
 IconCreator |
Generate application Icon (my own library) |
Please check this repository to learn more about the notation I used to create the diagrams in this project.
This diagram shows all the packages the application has, along with their structures. Some packages are simplified, while others are more detailed.
These diagrams illustrate the relationship between screens from view and viewmodel classes. The arrows from the View Models represent View Data objects (classes that hold all the necessary data for the view to display), primitives, or collections encapsulated by State Flows, which are classes that encapsulate data streams. Every update in the View Data triggers the State Flow to emit these new values to the view, and the view updates automatically. Typically, the methods called from screens in view to classes in viewmodel trigger these changes, as represented in the diagram below by arrows from the view screens to viewmodel classes.
View Datas are classes that hold all the data the view needs to present. They are created from model classes and served by View Models to the view. This diagram represents all the associations among the classes in the view.viewdata.
View Models serve the view with objects made from viewmodel.viewdata classes, collections, or primitive objects encapsulated by State Flows. This diagram represents all the associations among the classes in viewmodel and view.viewdata.
View Models also serve as a façade, triggering methods in model.repository classes. This diagram shows that each View Model has its own Repository class and illustrates all methods each View Model calls, represented by arrows from View Models to Repository classes.
Model classes handle the logic of the application. This diagram represents all the associations among the classes in the model.
These diagrams represent all the associations among the classes in model.repository and model.
Repository classes utilize the Data Source classes to perform the creation, retrieval, update, and deletion of the model objects. The Data Source classes use the database to persist these alterations and the requester to fetch the application data. In this case, the data can come from the database in the case of ServerURL or the API server in the case of TV shows. It can also be sourced from local sources, enabling testing of the application. This diagram represents all the associations among the classes in model.repository, model.datasource, and library. It also demonstrates the communications between each Repository through interfaces located at model.repository.listener package.
- Create Tests.
- Add IconCreator (my own library).
- Work with multiples servers at the same time.