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
Currently, the view(namely QRDialog.java and CardsAdapter.java) are tightly couples with the ical types. The ical types are not necessarily View types, they can be used however. I can see us running into issues with this at the moment. I propose making types specifically meant for the View layer, and leaving the ical types for the implementation layer, and the viewmodel is to map them in between.
Consider QRDialog's constructor: It requires a context(perfectly fine), a QrBitmapGenerator(maybe fine), and a FileManager type(probably not fine). Internally, it has member variables that use ICalSpec and EventSpec types. Go ahead and make a ViewEvent/ViewICal that has ONLY the data you need to view, and keep it as a primitive type. Assume we can map over from the EventSpec and ICalSpec so as to leave things decoupled. This way, you don't have to assume the ICalSpec will have the data you need and you won't need to manually yank from implementation details( ical.getEvents().get(0) ).
I'll move the ical package into it's own library that addresses this.
The text was updated successfully, but these errors were encountered:
Currently, the view(namely QRDialog.java and CardsAdapter.java) are tightly couples with the ical types. The ical types are not necessarily View types, they can be used however. I can see us running into issues with this at the moment. I propose making types specifically meant for the View layer, and leaving the ical types for the implementation layer, and the viewmodel is to map them in between.
Consider QRDialog's constructor: It requires a context(perfectly fine), a QrBitmapGenerator(maybe fine), and a FileManager type(probably not fine). Internally, it has member variables that use ICalSpec and EventSpec types. Go ahead and make a ViewEvent/ViewICal that has ONLY the data you need to view, and keep it as a primitive type. Assume we can map over from the EventSpec and ICalSpec so as to leave things decoupled. This way, you don't have to assume the ICalSpec will have the data you need and you won't need to manually yank from implementation details( ical.getEvents().get(0) ).
I'll move the ical package into it's own library that addresses this.
The text was updated successfully, but these errors were encountered: