Computer Science Project - Proyecto Ingenieria Informática - UNED

 PFG: Recopilación de perfiles difusores de noticias en redes sociales

Hace más de un año que finalice la II en la UNED y acabo de hacer público el repositorio en Github https://github.com/culexjj/TLProfilesCreator

El proyecto aborda el fenómeno de la difusión de noticias en redes sociales y su impacto en la sociedad.

El objetivo principal del proyecto fue diseñar y desarrollar una herramienta software capaz de recopilar datos sobre usuarios que comparten noticias en Telegram. La aplicación permite recuperar noticias desde Internet identificar mensajes en chats de Telegram que contengan esas noticias, y extraer información pública de los perfiles que las han difundido. Con estos datos se generan datasets estructurados en formato JSON, listos para su análisis o uso en modelos de aprendizaje automático.

El sistema ofrece funcionalidades como filtrado, ordenación y visualización de resultados, así como gráficos estadísticos. Además, soporta dos modos de operación: uso interactivo mediante GUI o ejecución por lotes a través de una API. Entre sus retos técnicos destaca la integración con la API de Telegram y la gestión de las restricciones de búsqueda impuestas por la plataforma.

Aparte de la integración con la API de Telegram, la configuración de TDLib y la sincronización de procesos que fue necesaria para gestionar su modo asíncrono de funcionamiento, otro aspecto interesante es la gestión de la concurrencia de procesos en entornos Swing. La aplicación ejecuta en paralelo tareas que pueden mucho tiempo, como la recuperación de noticias en buscadores o la búsqueda de mensajes en Telegram. Para evitar que la interfaz se bloquee y asegurar una experiencia fluida, se emplean hilos de ejecución separados del Event Dispatch Thread (EDT), utilizando mecanismos como SwingWorker. Esto permite que procesos se ejecuten en segundo plano, mientras el usuario sigue interactuando con la aplicación sin interrupciones.

Con este trabajo terminó una etapa de formación exigente (la UNED es muy dura), pero también apasionante. El proceso fue un reto que me permitió consolidar conocimientos, explorar nuevas tecnologías y aportar una solución real a un problema actual.

Lo comparto por si puede ser de ayuda a algún compañero.

Enjoy

Culex

+ 90000 VISITAS

 Muchas gracias a tod@s

Culex. 

TDLib & Process synchronization

Telegram works based on asynchronous RPC calls, so interacting with the API implies sending the payload that represents the call to the function and receiving a result. This mode of operation avoids blockages, but implies the need to correctly manage communication between processes.

 To implement a correct operation on my Bachelor's Degree Final Project,it was necessary to divide the API call management logic into two different actions. On the one hand, the result of the call is handled in class Telegram.java, and on the other hand, a spinlock is used to synchronize communication between processes.

HANDLE THE ANSWER:

To handle client-server interactions, the Telegram.java class adds a DefaultHandler object to each API call. The onResult(TdApi.Object object) method then receives the response when it is available.

The original functionality of the onResult() method was limited to printing the result of the call, a TL (Type Language) object such as the following, through the standard output of the system.

This functionality did not meet the requirements of the project since it was desired to natively retrieve the types of objects handled by Telegram: FoundMessages, Chats, User, etc.

To obtain the desired functionality, a feature of the TDLib design was taken advantage of.  Each type of object has a unique identifier defined in its constructor. For example, in the following figure it can be seen that the identifier -448050478 corresponds to an object type 'photo message'

The implemented solution modifies the onResult() method by adding a switch-case structure where the value of the constructor of the received object is used as a parameter in the switch and then the response is handled according to the corresponding needs. Here's an example.

After the response is captured and the received object is handled successfully, the value of the control variable is set to true to inform the calling method that it can end the spinlock. If there is a problem with the call, the default case is executed and the active wait is terminated.

Once the spinlock is finished, the corresponding object is retrieved and the lock variable is rearmed for the next request. If the result of the call is not as expected, the situation is handled appropriately.

Enjoy, 

Culex