I'm trying to decipher/understand the best way to implement Model-View-Presenter architecture for the following Android example app...
I'm attempting to implement a very basic weather app using MVP but I'm hopelessly lost on the best way to implement the pattern. The app consists of two Activities - MainActivity and WeatherActivity. MainActivity has an EditText for the user to input their location manually, a button which the user can press to get the device's current location and a button to fetch the weather data for the location. Once the weather data has been fetched the ViewWeatherActivity is launched and the data displayed to the user.
Heres how I'm thinking about implementing it but I can already see a few problems (more on that at the end) and think I might be either over-complicating things and/or just generally getting it horribly wrong...
I know there's some debate out there about this but I've decided to make the MainActivity the View, as it knows all about the framework and handles UI etc. The View will validate user input (e.g. check they have entered a location etc.) and then ask the Presenter (via an interface) to fetch the weather data. The View will also implement it's own interface to receive the data coming back.
This is a non-Activity class which implements two interfaces. One to receive requests from the View and one to receive data back from the Model. The presenter will, for example, ask the Model to get the raw JSON data for a given location from the weather API. Once received the Presenter will format the data for consumption by the View, then hand it to the View via the View's interface.
The Model will implement an interface to handle incoming requests from the Presenter. It will, for example, respond to a request (passed all the way from the View via the Presenter) to get the device's current location. It is also responsible for communicating with the weather API to fetch the requested data. The data fetched by the Model will be passed back to the Presenter via an interface.
Here's a quick (very basic!) diagram illustrating the above:
The Location Conundrum:
This is a problem I've already identified with the above implementation. The utility I'm using to handle location funtionality is a wrapper around the Google Play Services FusedLocationProviderClient API, which means it needs an Activity context. Having the location functionality handled by the Model would require a reference to the calling Activity to be held - potentially resulting in a nasty memory leak. But, moving the location functionality to the View, for instance, would kind of defeat the object of having only UI logic in the View, wouldn't it? Or in the circumstances is that acceptable? Is there an alternative way to handle for location functionality that fits in with the MVP paradigm more succinctly?
So, what do you think? Am I barking up the wrong tree completely or is there some merit in my planned implmentation? How can it be improved, made more efficient, less complicated etc? Any advice and constructive criticism will be greatly appreciated. Thanks.