In CategoryImagesListFragment, the code tries to cast the Context to 4 different activities and calls viewPagerNotifyDataSetChanged on each of them. This pattern is present in a few more classes. Does this have any advantages as opposed to implementing an interface?
try {
((CategoryImagesActivity) getContext()).viewPagerNotifyDataSetChanged();
}catch (Exception e){
e.printStackTrace();
}
try {
((CategoryDetailsActivity) getContext()).viewPagerNotifyDataSetChanged();
}catch (Exception e){
e.printStackTrace();
}
try {
((ExploreActivity) getContext()).viewPagerNotifyDataSetChanged();
}catch (Exception e){
e.printStackTrace();
}
No this doesn鈥檛 have any advantage. Infact its a very bad way of handling the scenarios.
IMO it would be great if media details could be a separate activity and could maintain its own life cycle.
Maybe they should be rewritten in MVP after Nearby activities are done.
There are usages similar to this throughout the code. It shouldn't be too hard to refactor them.
I'd like to be assigned on this one.
Aside from implementing an interface, what else should be done?
Maybe they should be rewritten in MVP after Nearby activities are done.
Could you give me more details about this?
I'd like to be assigned on this one.
Sorry for the late reply :) You're assigned!
Maybe they should be rewritten in MVP after Nearby activities are done.
The current architecture of these categories are not great. I meant that as a long term side note. If you would like to refactor these classes completely, I would advise you to make some smaller contributions and become more familiar with the project before taking on such a big task.
Most helpful comment
No this doesn鈥檛 have any advantage. Infact its a very bad way of handling the scenarios.
IMO it would be great if media details could be a separate activity and could maintain its own life cycle.