Need to package generic pieces separate from android pieces

[dalewking]

The Presenter side of things should be packaged as plain Java jars with no android content so that presenter code can be cross platform. For example, I see that MvpBasePresenter is packaged right next to MvpActivity and MvpFragment and packaged into an android library even though it is not Android specific. Items that are android specific like mvp should really be called something like mvp-android since there could theoretically be things mvp-swing or mvp-swt for desktop.

[IgorGanapolsky]

Cross platform? What gave you the idea that this framework is intended for
anything other than Android!
On May 30, 2015 1:54 PM, "Dale King" notifications@github.com wrote:

The Presenter side of things should be packaged as plain Java jars with no
android content so that presenter code can be cross platform. For example,
I see that MvpBasePresenter is packaged right next to MvpActivity and
MvpFragment and packaged into an android library even though it is not
Android specific. Items that are android specific like mvp should really be
called something like mvp-android since there could theoretically be things
mvp-swing or mvp-swt for desktop.

—
Reply to this email directly or view it on GitHub
#44.

[dalewking]

This text from the first Mosby article talks about the theory of Presenters being cross platform and I see no reason not to allow it:

Furthermore, by letting Presenter implement OnClickListener the Presenter is bound to the android platform. In theory the presenter and business logic could be plain old java code, which could be shared with a desktop application or any other java application.

[sockeqwe]

In general I agree that Presenter usually shouldn't have dependencies to android. Actually, the interfaces are packed in a plain old jar file
https://github.com/sockeqwe/mosby/tree/master/mvp-common/src/main/java/com/hannesdorfmann/mosby/mvp

Here you can find MvpPresenter. MvpBasePresenter implements MvpPresenter could be moved in the same jar. It's not a big deal.

However, the question is: Is it worth to make an effort in refactoring/repackaging this things. Next we may should refactor rx package and so on. Is it really worthwhile? Will mosby ever be used on oher plattforms?

[IgorGanapolsky]

I agree with Hannes, people looking for Enterprise Java or Desktop Java
solutions should look elsewhere. Don't bother us - Android devs - with
stuff we don't care about.
On May 30, 2015 2:28 PM, "Hannes Dorfmann" notifications@github.com wrote:

In general I agree that Presenter usually shouldn't have dependencies to
android. Actually, the interfaces are packed in a plain old jar file

https://github.com/sockeqwe/mosby/tree/master/mvp-common/src/main/java/com/hannesdorfmann/mosby/mvp

Here you can find MvpPresenter. MvpBasePresenter implements MvpPresenter
could be moved in the same jar. It's not a big deal.

However, the question is: Is it worth to make an effort in
refactoring/repackaging this things. Next we may should refactor rx package
and so on. Is it really worthwhile? Will mosby ever be used on oher
plattforms?

—
Reply to this email directly or view it on GitHub
#44 (comment).

[sockeqwe]

@dalewking I thought about your suggestions:

1. We are not going to rename packages to mvp-android because the main focus of this library is clearly on android. It should be obvious that all packages are for android. Furthermore, we don't wan't break the current dependencies declaration by renaming packages. If Mosby will ever have first class support for swt or swing the package will be named to mvp-swt to clearly indicate that this one is not an "android package".
2. As already mentioned, MvpView and MvpPresenter are already packed in mvp-common.jar and could be used in the old java world as well i.e. for swt or swing. The question is should we move MvpBasePresenter into mvp-common. On one hand MvpBasePresenter uses WeakReference which is the reason why you have to check if view != null ( or isViewAttached()). From my point of view it doesn't make sense to have a WeakReference to View on a desktop application. You could save all those view != null checks on desktop because the view and the presenter don't have different life cycles (like on android). On the other hand you could share Presenters between desktop and android app if you use MvpBasePresenter and therefore it should be part of mvp-common. What do you think?

[dalewking]

1 is fine. For 2 I would move it and I think it is perfectly valid to use Weak reference on desktop although not as important there.

As far as cross-platform, I am looking at applying Mosby under Kotlin instead of Java which may need some tweaks. For one, Butterknife, Icepick, and probably FragmentArgs do not work with Kotlin (although I have made suggestions to Icepick creator on how to make it work) so to start with I may create a core-kotlin version of core.

[dalewking]

Didn't realize you were also the creator of FragmentArgs. Added the info to that project for supporting Kotlin

[sockeqwe]

I have moved MvpBasePresenter into mvp-common.

Regarding Kotlin support. I have tested Mosby with Kotlin in a small sample project and as far as i can tell Mosby itself "works". As you have already said other third party annotation processors like Butterknife, Icepick and FragmentArgs doesn't work. However, they don't cause any compilation or runtime error, they just do nothing :)

So full Kotlin support will be part of Mosby 2.0 which can be released only after all annotation processors are working properly. See #47