2

j2objc is great to develop shared projects across iOS, Android and Web. For me it seems to be clear that it is a good practice to create four projects:

  • shared code
  • web
  • ios
  • android

Also the MVP seems to be reasonable for these kind of projects. When using this pattern I guess that the Model and the Presenter go into the share code project and the view goes into the platform specific projects. From my understanding transport mechanisms should go into the shared project as well or do they belong to each platform specific project?

Are there any best practices or recommended design pattern which are great for these type of projects which share a lot of code?

Michael
  • 32,527
  • 49
  • 210
  • 370

1 Answers1

3

MVP is a great pattern, and you're right about the Model and Presenter being portable. We've found a close correlation between how easy code is to test to how portable it is, and one reason MVP was created is so more component code can be tested with simple JUnit tests.

I'm not sure what you mean by "transport mechanisms", though. Do you mean HTTP requests? If so, URLConnection/HttpURLConnection should be portable on all platforms but GWT.

tball
  • 1,984
  • 11
  • 21
  • By transport I mean http requests. This should be in the shared package you said but why is it different for GWT? What about serialization to and from JSon. Where is this done? – Michael Feb 01 '15 at 11:26
  • 1
    GWT doesn't support for java.net. However, an app-specific lightweight interface for request/responses is relatively easy because with GWT XMLHttpRequest can be used. If the interface is designed to be async, app code that uses it can be completely portable. The same is true for JSON: Android and J2ObjC support the org.json API; GWT doesn't, but eval() or JavaScript JSON libraries are available. – tball Feb 02 '15 at 15:11