You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The workflow of NAPPA is complicated. For instance, the class Nappa has far too many responsibilities.
My suggestion would be to refactor this class, making it an access point to NAPPA and extract data management to other classes. These classes would be self-contained and have a single responsibility/purpose.
In addition to having many responsibilities, NAPPA frequently invokes secondary threads. This is due to Android development nature, as network requests and database accesses must be performed in secondary threads. In NAPPA, these threads are created using ScheduledThreadPoolExecutor.
All these aspects make the workflow of NAPPA difficult to follow and debug.
In PR #99 a first attempt to improve the readability was performed by extracting database accesses to Handler classes. The introduced flow consists of a caller, a handler and an executor. The caller is the class that needs to perform an access to the database or issue a network request. The handler will take the desired action, instantiate its executor and schedule it to run in a secondary thread. The executor then executes the given action and, if applicable, returns a callback to the caller, with the operation result. Each action is implemented with handlers and executors pairs. A handler may be invoked by another handler. The handler abstracts the calls to threads and execution. The caller only needs to provide the data and, if applicable, provide a callback.
There are more candidates to be extracted into handler/executor pairs. You can verify the existent handlers and executors here
The text was updated successfully, but these errors were encountered:
The workflow of NAPPA is complicated. For instance, the class Nappa has far too many responsibilities.
My suggestion would be to refactor this class, making it an access point to NAPPA and extract data management to other classes. These classes would be self-contained and have a single responsibility/purpose.
In addition to having many responsibilities, NAPPA frequently invokes secondary threads. This is due to Android development nature, as network requests and database accesses must be performed in secondary threads. In NAPPA, these threads are created using ScheduledThreadPoolExecutor.
All these aspects make the workflow of NAPPA difficult to follow and debug.
In PR #99 a first attempt to improve the readability was performed by extracting database accesses to Handler classes. The introduced flow consists of a caller, a handler and an executor. The caller is the class that needs to perform an access to the database or issue a network request. The handler will take the desired action, instantiate its executor and schedule it to run in a secondary thread. The executor then executes the given action and, if applicable, returns a callback to the caller, with the operation result. Each action is implemented with handlers and executors pairs. A handler may be invoked by another handler. The handler abstracts the calls to threads and execution. The caller only needs to provide the data and, if applicable, provide a callback.
There are more candidates to be extracted into handler/executor pairs. You can verify the existent handlers and executors here
The text was updated successfully, but these errors were encountered: