Search

EP-4735998-A1 - SYSTEM AND METHOD FOR CLEAN BLOC ARCHITECTURE STATE MANAGEMENT

EP4735998A1EP 4735998 A1EP4735998 A1EP 4735998A1EP-4735998-A1

Abstract

The present disclosure provides a system and a method for clean bloc architecture state management. The system receives one or more inputs from one or more users. The one or more inputs are triggering events based on actions of one or more users. The triggering events are button clicks or form submissions. The system processes the triggering events to perform one or more logic operations for different use cases, maintains a current state of the application and produce updated states based on the received events and the current state. The new updated states are sent back for UI updates and the process repeats as the one or more users interacts with the application, triggering new events and resulting in updated states.

Inventors

  • BHATNAGAR, AAYUSH
  • BHATNAGAR, PRADEEP KUMAR
  • Sankaran, Sundaresh
  • AMBALIYA, Haresh B
  • VALAKUNDE, Nandakishor
  • BARGAL, Yogeshwar
  • CHUNDAWAT, Surya
  • MALVIYA, Gunjan

Assignees

  • Jio Platforms Limited

Dates

Publication Date
20260506
Application Date
20240528

Claims (14)

  1. 1. A system (108) for performing architecture state management in a software architectural pattern that follows a bidirectional data flow, the system comprising: a user interface (UI) widget (305) configured to receive a plurality of events corresponding to one of a plurality of applications performed by a user on the UI widget (305); the UI widget (305) configured to display current state of the application; a business logic unit (322) configured to receive the plurality of events corresponding to the application from the UI widget (305); in responsive to receiving the event from the UI widget (305), the business logic unit (322) configured to perform a plurality of business logic operations for a plurality of use cases; the business logic unit (322) configured to maintain the current state of the application; the business logic unit (322) configured to produce an updated state based on the received events and the current state of the application; the business logic unit (322) configured to send the updated state of the application to the UI widget (305); the UI widget (305) configured to reactively update the UI based on the updated state of the application; and a repository (340) configured to access and modify data from a plurality of data sources (352).
  2. 2. The system claimed as in claim 1, wherein the plurality of business logic operations comprises transforming events, managing application programming interface (API) requests, accessing a plurality of local databases, and performing data-related operations.
  3. 3. The system claimed as in claim 1, wherein the plurality of events comprises user interactions, button clicks, submission of forms.
  4. 4. The system claimed as in claim 1, wherein the plurality of data sources (352) includes remote APIs, local databases, or external services.
  5. 5. The system claimed as in claim 1, wherein the repository (340) configured to handle retrieval of data from the data sources, data storage, modification of data, encapsulating implementation details of the data sources.
  6. 6. The system claimed as in claim 1, wherein the repository (340) configured to communicate with the business logic unit (322) by sending data through callbacks, futures, and observables.
  7. 7. A method for performing architecture state management in a software architectural pattern that follows a bidirectional data flow, the method comprising: triggering, by a view layer (310), an event corresponding to one of the plurality of applications based on user interactions on a user interface (UI) widget (305) of the view layer (310); displaying, by the UI widget (305), a current state of the application; receiving, by a business layer (320), the event from the UI widget (305); in responsive to receiving the event from the UI widget, performing, by a business logic unit (322) of the business layer (320), a plurality of business logic operations for a plurality of use cases; maintaining, by the business logic unit (322), the current state of the application; producing, by the business logic unit (322), an updated state of the application based on the received event and the current state of the application; sending, by the business logic unit (322), the updated state of the application to the view layer (310); reactively updating, by the view layer (310), the UI based on the updated state of the application; and accessing and modifying, by a repository (340), data from a plurality of data sources (352).
  8. 8. The method claimed as in claim 7, wherein the plurality of business logic operations comprises transforming events, managing application programming interface (API) requests, accessing a plurality of local databases, and performing data-related operations.
  9. 9. The method claimed as in claim 7, wherein the plurality of events comprises user interactions, button clicks, submission of forms.
  10. 10. The method claimed as in claim 7, wherein the plurality of data sources (352) includes remote APIs, local databases, or external services.
  11. 11. The method claimed as in claim 7, wherein the repository (340) configured to handle retrieval of data from the data sources, data storage, modification of data, encapsulating implementation details of the data sources.
  12. 12. The method claimed as in claim 7, wherein the repository (340) configured to communicate with the business logic by sending data through callbacks, futures, and observables.
  13. 13. A user equipment (UE) (104) communicatively coupled with a system (108), the coupling comprises steps of: receiving, by the system (108), a connection request; sending an acknowledgment of the connection request to the UE (104); transmitting a plurality of user inputs in response to the connection request to the system (108), wherein the system is configured for performing architecture state management in a software architectural pattern that follows a bidirectional data flow as claimed in claim 1.
  14. 4. A computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method for performing architecture state management in a software architectural pattern that follows a bidirectional data flow, the method comprising: triggering, by a view layer (310), an event corresponding to one of the plurality of applications based on user interactions on a user interface (UI) widget (305) of the view layer (310); displaying, by the UI widget (305), a current state of the application; receiving, by a business layer (320), the event from the UI widget (305); in responsive to receiving the event from the UI widget, performing, by a business logic unit (322) of the business layer (320), a plurality of business logic operations for a plurality of use cases; maintaining, by the business logic unit (322), the current state of the application; producing, by the business logic unit (322), an updated state of the application based on the received event and the current state of the application; sending, by the business logic unit (322), the updated state of the application to the view layer (310); reactively updating, by the view layer (310), the UI based on the updated state of the application; and accessing and modifying, by a repository (340), data from a plurality of data sources (352).

Description

SYSTEM AND METHOD FOR CLEAN BLOC ARCHITECTURE STATE MANAGEMENT RESERVATION OF RIGHTS A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and/or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner. FIELD OF DISCLOSURE [0001] The embodiments of the present disclosure generally relate to management of software applications. More particularly, the present disclosure relates to a system and a method for clean bloc architecture state management. BACKGROUND OF THE INVENTION [0002] The following description of the related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section is used only to enhance the understanding of the reader with respect to the present disclosure, and not as admission of the prior art. [0003] In software development, state management refers to the management and manipulation of data that represents the current state of an application. This data can include user input, system settings, or any other relevant information necessary for the application to function correctly. [0004] Traditionally, many applications have relied on approaches like setState to manage their state. The setState method is typically used in frameworks and libraries that provide a way to update component state, such as React's setState function. While this approach can work for simple applications, it can lead to several disadvantages as the complexity of the application grows. [0005] One of the main drawbacks of using setState is that it often results in stateful components. Stateful components are those that manage their own internal state and handle state updates within themselves. This can lead to complex code that intertwines UI rendering and state management logic, making it harder to understand and maintain. [0006] Another challenge with setState is that it can introduce unexpected side effects and make it difficult to reason about state changes. Asynchronous updates or complex dependencies can further complicate the management of state, leading to potential race conditions or inconsistencies in the application. [0007] There is, therefore, a need in the art to provide a system and a method that can mitigate the problems associated with the prior arts. SUMMARY [0008] In an exemplary embodiment, a system for performing architecture state management in a software architectural pattern that follows a bidirectional data flow is described. A user interface (UI) widget configured to receive a plurality of events corresponding to one of a plurality of applications performed by a user on the UI widget. The UI widget configured to display current state of the application. A business logic unit configured to receive the plurality of events corresponding to the application from the UI widget. In responsive to receiving the event from the UI widget, the business logic unit configured to perform a plurality of business logic operations for a plurality of use cases. The business logic unit configured to maintain the current state of the application. The business logic unit configured to produce an updated state based on the received events and the current state. The business logic unit configured to send the updated state of the application to the UI widget. The UI widget configured to reactively update the UI based on the updated state of the application and a repository configured to access and modify data from a plurality of data sources. [0009] In some embodiment, the plurality of business logic operations comprises transforming events, managing application programming interface (API) requests, accessing a plurality of local databases, and performing data-related operations. [0010] In some embodiment, the plurality of events comprises user interactions, button clicks, submission of forms. [0011] In some embodiment, the plurality of data sources includes remote APIs, local databases, or external services. [0012] In some embodiment, the repository configured to handle retrieval of data from the data sources, data storage, modification of data, encapsulating implementation details of the data sources. [0013] In some embodiment, the repository configured to communicate with the business logic unit by sending data through callbacks, futures, and observables. [0014] In another exemplary embo