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
As it stands at v1.0, there are some significant quantities of code duplication between
WelcomeTourCellViewModel and AllToursCellViewModel
WelcomeEventCellViewModel and AllEventsCellViewModel
WelcomeExhibitionCellViewModel and AllExhibitionsCellViewModel
AllEventsFragment, AllToursFragment, and AllExhibitionsFragment
the layout files used by above classes
the navigation paradigms used by above classes
the RecyclerView adapters used by the above classes.
This causes no small amount of overhead when editing related visual elements (c.f. PRs #220, #230, #240, #260, #268, #289, etc).
Where it came from
I harbor no ill will towards the existing structure of these elements. Earlier understandings of the desired screens had less commonality and the development team thus took an apprehensive stance towards consolidation. At this stage in the application development process, though, we can be assured that the degree of deviation is much less than then-anticipated.
Resolution plan
By combining the related files into one module, it should be easier to detect inadvertent inconsistencies and share logic to the greatest extent permissible. The new module's name should represent the shared goal of the files aligned with AllEvents, AllExhibitions and AllTours. Name suggestions are welcome, of course, but I will start work with the working title :content_listing for now.
The text was updated successfully, but these errors were encountered:
The issue
As it stands at v1.0, there are some significant quantities of code duplication between
WelcomeTourCellViewModel
andAllToursCellViewModel
WelcomeEventCellViewModel
andAllEventsCellViewModel
WelcomeExhibitionCellViewModel
andAllExhibitionsCellViewModel
AllEventsFragment
,AllToursFragment
, andAllExhibitionsFragment
RecyclerView
adapters used by the above classes.This causes no small amount of overhead when editing related visual elements (c.f. PRs #220, #230, #240, #260, #268, #289, etc).
Where it came from
I harbor no ill will towards the existing structure of these elements. Earlier understandings of the desired screens had less commonality and the development team thus took an apprehensive stance towards consolidation. At this stage in the application development process, though, we can be assured that the degree of deviation is much less than then-anticipated.
Resolution plan
By combining the related files into one module, it should be easier to detect inadvertent inconsistencies and share logic to the greatest extent permissible. The new module's name should represent the shared goal of the files aligned with
AllEvents
,AllExhibitions
andAllTours
. Name suggestions are welcome, of course, but I will start work with the working title:content_listing
for now.The text was updated successfully, but these errors were encountered: