8

Model-View-Presenter (MVP) is a well known design pattern for GUI applications. For Android, implementing the business logic in a plain Java module facilitates testing without requiring an Android emulator.

However, I am having difficulties implementing the pattern on Android because of special requirements to the GUI of Android applications:

  • An Activity may be destroyed at any point (incoming call, user presses home button, ...), and when recreated it should be in the exact same state as when it was left. This is unlike most other GUI applications.

  • An Activity can go through many lifecycle states. It may be paused in which case the UI of the Activity should not be modified. If for example some data is being loaded in the background, it cannot be delivered to the View part of MVP (Activity) if it is in a paused state. Again, this is an unusual requirement.

I have read the blog post MVP for Android and looked at the example source code. The end goal I am trying to achieve by using the MVP pattern is to be able to translate all business logic to Objective-C using the transpiler j2objc, such that the business logic can be reused while implementing the same app on iOS.

Is there anyone that have implemented the MVP pattern for Android successfully, and in that case, what am I missing?

Community
  • 1
  • 1
foens
  • 8,642
  • 2
  • 36
  • 48
  • What I'm wondering: if you business-logic module is plain java without the need of a `Context`, why does your `Activity`-lifecycle matter? In other words, why are those special GUI requirements a problem? – Blacklight Jul 11 '14 at 13:10
  • If the `View` part of MVP may not be updated at certain points (when it is paused), should the `Presenter` or the `Model` not know? And should the `Model` not be created such that it can be restored at a later point? – foens Jul 12 '14 at 10:22
  • 1
    One might argue that the Activity is responsible for managing lifecycle and setting up/pausing/tearing down the presenter as needed. The presenter is none the wiser to your system dependent UI framework quirks. – dcow Sep 06 '14 at 18:52

2 Answers2

4

I suggest implementing the MVP component without involving Activity, perhaps conceptually thinking about what would be useful on both Android and GWT. Create the component using test-driven-development with a mocked View interface, adding tests until the business logic is fully implemented and verified. TDD helps keep the component's API lean (why write tests for stuff you don't need?), which makes porting the component easier.

The Activity requirements you describe can be generalized to be platform-independent: the component should be serializable (small 's', not specifically Java serialization), and needs to accept lifecycle state events. Those, too, can be fully tested using mocks for system features. As you go through this step, you'll likely notice that few of the Activity requirements are necessarily Android-specific, and may be useful on other platforms. Avoid creating huge service APIs; to support serialization, for example, all that's needed are store/load methods, not something like the Parcel API. I've found describing such service APIs to another developer on a whiteboard to be a great way to find unnecessary fluff.

Next, port the component to Android, perhaps by creating an Activity that delegates to the component and provides Android-specific implementation classes for the mocked interfaces. It should all "just work" the first time, but in reality, some requirements may have been missed, so add them to the platform-independent part and repeat.

When you're ready to port to iOS, reimplement those previously mocked interfaces. If these interfaces are lean, it will probably be easier to create them directly in Objective-C, importing the protocol headers generated by j2objc. For example, j2objc's NSDictionaryMap class implements java.util.Map with an NSDictionary implementation -- no need to write and translate a Java version since its just using iOS APIs.

tball
  • 1,984
  • 11
  • 21
  • Hi and thanks for the ideas. I'm not entirely sure what the `component` is. Are you talking about the presenter? In your post I feel you are actually describing the implementation process called [Presenter-First](http://atomicobject.com/files/PresenterFirstAgile2006.pdf), am I correct in this? Views should be interfaces (without platform specifics) and these should be implemented by an Activity on Android. I feel it will take a considerable effort to implement the save/load procedures, which also effectively is a re-implementation of the Android recreation process. – foens Jul 12 '14 at 10:02
  • I was calling the combined MVP "unit" a component, is there a better name? All the available terms seem overloaded. You're right about Presenter-First, thanks for the link as I hadn't read that paper. The save/load should be called externally from a platform-specific archiving service like Parcel or Java's serialization -- all the component should handle is its own store/restore. By making it a service, Android-specific code would use the same code an Android app would normally. – tball Jul 13 '14 at 17:51
1

I find that the MVP variant Android is built around is a step in the right direction for isolating the business logic in a app. However, if you want to achieve a better separation of concerns, and as a result more reusable domain/business logic, I recommend using the Presenter First pattern (which you briefly mention yourself in the comment). Aside from decreasing coupling it lends itself well to TDD and allows you to unit test all your business logic.

I recently started a GitHub repo with Presenter First examples for Android. Due to the complexity of the Android architecture it's not straightforward to implement the pattern The views tend to be "fatter" than what seems to be acceptable in a normal Presenter First app, mostly because of the activity lifecycle and other oddities as you mention yourself. I've done my best to decouple the business logic from the platform but there's definitely room for improvement. You can find the examples at:

http://github.com/olerass/presenter-first-android

Maybe you can use some ideas from there? Or even better contribute some of your own.

olerass
  • 410
  • 2
  • 4
  • 8