sockeqwe / mosby

A Model-View-Presenter / Model-View-Intent library for modern Android apps

Mosby

A Model-View-Presenter and Model-View-Intent library for Android apps.

Dependency

dependencies {

  compile 'com.hannesdorfmann.mosby3:mvi:3.1.1' // Model-View-Intent
  // or
  compile 'com.hannesdorfmann.mosby3:mvp:3.1.1' // Plain MVP
  // or
  compile 'com.hannesdorfmann.mosby3:viewstate:3.1.1' // MVP + ViewState support
}

Additional modules:

dependencies {

  // MVP + ViewState + LCE Views
  compile 'com.hannesdorfmann.mosby3:mvp-lce:3.1.1'

  // Null Object Presenter for MVP
  compile 'com.hannesdorfmann.mosby3:mvp-nullobject-presenter:3.1.1'
  
  // Queuing Presenter for MVP
  compile 'com.hannesdorfmann.mosby3:mvp-queuing-presenter:3.1.1'
}

SNAPSHOT:

dependencies {

  compile 'com.hannesdorfmann.mosby3:mvi:3.1.2-SNAPSHOT'

  compile 'com.hannesdorfmann.mosby3:mvp:3.1.2-SNAPSHOT'
  compile 'com.hannesdorfmann.mosby3:viewstate:3.1.2-SNAPSHOT'

  compile 'com.hannesdorfmann.mosby3:mvp-lce:3.1.2-SNAPSHOT'
  compile 'com.hannesdorfmann.mosby3:mvp-nullobject-presenter:3.1.2-SNAPSHOT'
  compile 'com.hannesdorfmann.mosby3:mvp-queuing-presenter:3.1.2-SNAPSHOT'
}

You also have to add the url to the snapshot repository:

allprojects {
  repositories {
    maven { url "https://oss.sonatype.org/content/repositories/snapshots/" }
  }
}

Documentation

See the project website.

For Model-View-Intent check out this blog post series.

Changelog

The changelog can be found in the release section

Migrating

In Mosby 3.0 we have changed the package name from com.hannesdorfmann.mosby to com.hannesdorfmann.mosby3 (note the 3 at the end). Migrating a Mosby 2.x based app to Mosby 3.0 should be straightforward: Just replace all import statements of your app in android studio with Edit -> Find -> Replace in Path ... and set find import com.hannesdorfmann.mosby replace with import com.hannesdorfmann.mosby3. There were also some minor API changes (see changelog), but most apps should be fine by replacing the import statements.

Conductor

Mosby has a plugin for Conductor. You can find it here: https://github.com/sockeqwe/mosby-conductor

License

Copyright 2015 Hannes Dorfmann

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

mosby's Issues

Could Mosby be utilized with viewpager?

Thanks for awesome helper library and even more awesome blog post explaining the LCE pattern. It surely reflects the experience of 3 years digested into one well thought out library !

Your current examples are focused around displaying a lists ( they are common ), in general it is hard for android newbies to wrap their head around viewpager best practices.

Can you create a sample in your repo with dagger1,retrofit,lce that utilizes LCE pattern with view pager ?
--> "A layout that would have pull to refresh functionality and a view pager with one member displayed at at time instead of list..."" <--

For you it might be trivial task being a Mosby author but for others like me it would be a valuable starting point to pickup Mosby with viewpager !

Otto instead of EventBus

Hello,
I see your project heavily relies on EventBus - especially the SchedulerTransformer. If I remove EventBus dependency from my project, and use Otto instead, will the compilation break?

Right now I am seeing a compilation error like this:

Error:(21, 27) error: LoginUtils cannot be provided without an @Inject constructor or from an @Provides-annotated method. This type supports members injection but cannot be implicitly provided.
LoginPresenter.(com.securepreferences.SecurePreferences securePreferences, LoginUtils loginUtils, com.hannesdorfmann.mosby.mvp.rx.lce.scheduler.SchedulerTransformer transformer, com.squareup.otto.Bus eventBus)
[parameter: LoginUtils loginUtils]

Thanks,
Igor

some problem about error view in MvpActivity

I have problem and why the error view is only can be TextView.

Unused methods

Hi,
I'm wondering what is the purpose of onEventMainThread() methods in this class:
https://github.com/sockeqwe/mosby/blob/master/sample-mail/src/main/java/com/hannesdorfmann/mosby/sample/mail/base/presenter/BaseRxMailPresenter.java#L98

It seems that these methods are unused. Perhaps they respond to bus events, but I do not see a @Subscribe or onEvent method annotations?

Thanks,
Igor

Is it production ready ?

All is in the title :) Do you think the framework is production ready for a large app ?
Thanks !

AbsParcelableLceViewState without copying view state.

AbsParcelableLceViewState should work without making a copy of itself. Currently this is a workaround to not specify class loader for Parcelable and Lists. But I'm pretty sure there is a better way.

Problem with gradle:1.2.0-beta1

Hello,
I see in your project's build.gradle file you are using dependency classpath 'com.android.tools.build:gradle:1.2.0-beta1'. However, that does not work in Android Studio 1.2 RC 3 - the project does not build when I import it, and I cannot run any of the module samples. The only way I was able to fix this problem is to revert back to
classpath 'com.android.tools.build:gradle:1.1.3'

Please explain why you are trying to use gradle:1.2.0-beta1 in the mosby project?

Thank you,
Igor

Status code 500 from jcenter server

While trying to sync the project for the first time, on 2 machines I get:

Error:Could not GET 'https://jcenter.bintray.com/com/hannesdorfmann/mosby/core/1.0.0/core-1.0.0.pom'. Received status code 500 from server: Internal Server Error

I have in my build.gradle (plus the apt stuff)

compile 'com.hannesdorfmann.mosby:core:1.0.0'
compile 'com.hannesdorfmann.mosby:mvp:1.0.0'

Any suggestions?

Mail Sample: fix Dagger 2 scopes

Either fix Scopes in MailAppModule or use @Subcomponent. Remove static fields from MailAppModule which is the current workaround.

Add support for DialogFragment

It's almost exactly the same as regular Fragment, I'm not sure if there is an easy way to share the boilerplate code between them.

If anyone does try to add support for DialogFragments, this will keep the dialog on the screen for orientation changes.

    @Override
    public void onDestroyView() {
        if (getDialog() != null && getRetainInstance()) {
            getDialog().setDismissMessage(null);
        }
        ButterKnife.reset(this);
        super.onDestroyView();
    }```

java.lang.RuntimeException: Unable to start activity Bad magic number for Bundle: 0x6f0063

http://crashes.to/s/7ed95959eaa/details

Avoid repetitive checks via isViewAttached() using null object pattern

Hey!

I've been experimenting with mosby a little bit this afternoon. Great framework, thanks!
This really makes creating a clean architecture on Android a lot simpler.

One thing I found slightly annoying are the repetitive checks using isViewAttached() that are required to ensure the MvpView is still attached to the MvpPresenter every time you want to update the view. Obviously these checks are necessary since it's the view's responsibility to attach to and detach from the presenter and any asynchronous callback might only return after the view has already been detached. However, I think this can be simplified.

So a common solution to avoid these null-checks before notifying listeners/callbacks is to use the null object pattern, i.e. providing a no-op implementation of the respective interface. Now this gets a bit tricky if generics are involved like in your MvpPresenter<V extends MvpView>. However, I think I've come up with a reasonable solution by creating dynamic no-op implementations of those interfaces at runtime using Java's dynamic proxies feature and using a default invocation handler.

I've created a MvpBasePresenter2 which makes use of this and also removes the now redundant isViewAttached() method.
Here's the relevant commit in my fork.

I know that this solution is based on reflection. And reflection is baaaaaaaaad. Some people are allergic to it. However, in my opinion, in this case the cleaner code far outweighs the negligible performance penalty.

Please let me know your thoughts.

Metadata annotations

Hi @sockeqwe!

Have you considered annotating all public methods and its non-primitive parameters with the new support annotations?
I find them incredibly useful since Android Studio gives you some nice little hints in the IDE, e.g. getView() in MvpBasePresenter is @Nullable.

Cheers
jenzz

Prevent NPE on getView

If you call getView on MvpBasePresenter and the view is not attached you get a NPE. To prevent that you have isViewAttached. But this is a bad design. There is a potential race condition where if the view got detached between the 2 calls you would get a NPE.

You should change getView to:

protected V getView() {
     return viewRef == null ? null : viewRef.get();
}

isViewAttached can then be implemented simply as getView() != null, but it might be better to deprecate in favor of this idiom:

MyView v = getView();
if(v != null)
{
    v,doSomething();
 }

which will not throw an NPE even if the view gets detached since your local variable is a strong reference to the view.

Mail app back toolbar button

Hello,
the back toolbar navigation button doesn't work when trying to exit the compose message screen.

Thanks,
Igor

Provide sources automatically

I saw that in some library like OkHttp, source code is provided automatically when we have a dependency to the library. As you include lot of code in different module, I want to have sources directly in my IDE it's easier to handle the framework lifecycle with the sources !

Thanks :)

Support for backstack in ViewStateFragments

Hard topic ... At this point Fragments really suck and ViewState and any other instance variables become null. My recomendation is to avoid backstack, however we may could implement a LrUMemoryCache or fragment argument based solution for that problem ...

How could I have multiple fragments in a Mosby Activity ?

I am using Dagger1MvpLceViewStateActivity as you have explained in a MosbyViewPagerDemo app.

I want to create a new fragment that could display "the full story". in the same screen.
How could that be done ?

com.hannesdorfmann.mosby.mvp.viewstate.lce.data.ParcelableDataLceViewState.readFromParcel

[The Most Frequent]
http://crashes.to/s/ac64c0db55d/details

http://crashes.to/s/de64b446301/details

http://crashes.to/s/10ad9ac164c/details

[Recent Crashes]
http://crashes.to/s/144ad441c80/details

Need to package generic pieces separate from android pieces

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.

No presenter in MosbyActivity

Hello,
why doesn't your MosbyActivity have methods for creating a Presenter? I do not want to extend any of the complicated LCE activities in the Mosby framework, I just want to stick to MosbyActivity. What is my option at this point?

Igor

pullToRefresh is always false

Hello,
My Activity is extending MvpLceViewStateActivity. However, loadData(boolean pullToRefresh) method will always have pullToRefresh false. Please explain how I can make it true?

Thanks,
Igor

LINT check for isViewAttached()

Write a custom LINT check that throws a warning if presenter.getView() is used without checking presenter.isViewAttached()

pullToRefresh on error?

Hi,
why do you have the pullToRefresh parameter in ErrorMessageDeterminer here:
https://github.com/sockeqwe/mosby/blob/master/sample-dagger2-rx/src/main/java/com/hannesdorfmann/mosby/sample/dagger2/model/ErrorMessageDeterminer.java#L10

Icepick in MvpLceViewStateActivity

Hi,
I am trying to use @Icicleprimitive variable in an activity which extends your MvpLceViewStateActivity. However, it isn't saving the state. Is this a bug on my end, or MvpLceViewStateActivity?

Thanks,
Igor

MosbyFragment vs MvpLceFragment

Hello,
I am trying to decide on the best use-case between these types of fragments. I have a fragment in my app that will fetch data from the DB and present it in a RecyclerView. There won't be a visible loading state like in your LCE spinner examples (since DB queries are lightning fast).

So, can you please tell me which type of fragment is better for my use-case? In your samples, I see your AboutFragment extends MosbyFragment, and CountriesFragment extends MvpLceFragment.

Thanks,
Igor

Can't build samples

Today I cloned your repo and now I'm trying to run samples. I don't know why, but gradle can't build them. I'm receiving following errors:

e.g. sample project

/mosby/mvp/src/main/java/com/hannesdorfmann/mosby/mvp/MvpActivity.java
Error:(20, 32) error: cannot find symbol class MosbyActivity
Error:(29, 67) error: cannot find symbol class MosbyActivity
/mosby/mvp/src/main/java/com/hannesdorfmann/mosby/mvp/layout/MvpFrameLayout.java
Error:(7, 19) error: package butterknife does not exist
/mosby/mvp/src/main/java/com/hannesdorfmann/mosby/mvp/layout/MvpLinearLayout.java
Error:(7, 19) error: package butterknife does not exist
/mosby/mvp/src/main/java/com/hannesdorfmann/mosby/mvp/layout/MvpRelativeLayout.java
Error:(7, 19) error: package butterknife does not exist
/mosby/mvp/src/main/java/com/hannesdorfmann/mosby/mvp/lce/LceAnimator.java
...

I'm using Android Studio 1.2 Build 3. Why can't I build them? Can you help me?

RestoreableViewState

Hello,
I have an Activity which extends MvpLceViewStateActivity. However, when I try to launch it, I get this Exception:
java.lang.IllegalArgumentException: Only RestoreableViewState are allowed

Please advise,
Igor

annotated with @ViewType.

Hello,
I am getting the following compilation error:

Error:(30, 37) error: mHousecalls in HistoryListAdapter is not public. Only final integer fields with public visibility can be annotated with @ViewType.

This does not make sense to me. Please elaborate...

Igor

Correct typo

Im Sample APK, you type download word wrong.

You can donwload the sample apk from here

Sample Mail App crashes

Hi,

The sample app crashed when the developer option "Don't keep activities" is on.
I don't have time to investigate on it so I notify you :)

PS: However the sample app is really nice!

RetainingFragmentLceViewState and fragment recreation

Hi !
I've been using your RetainingFragmentLceViewState and it works great on device rotation.
But I have a problem when the fragment is recreating because of low ram or long stay in background:

• Turn on "Don't keep activities" in developer options
• create a 2 activity app, the first one having a fragment using a RetainingFragmentLceViewState.
• start activity 1, from there start the activity 2.
• press the back button, the activity one is getting recreated, the view state also and it don't care about its previous state. However, everything which is saved without using the view state (views, Icicle) are getting saved and reapplied in the view.

I'm using the 1.1 version of your mvp framework

An error during assembly

I have java version "1.8.0_45", mac os 10.10.3.

...
:sample:compileDebugJava
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:sample:compileDebugNdk UP-TO-DATE
:sample:compileDebugSources
:sample:preDexDebug
UNEXPECTED TOP-LEVEL EXCEPTION:
com.android.dx.cf.iface.ParseException: bad class file magic (cafebabe) or version (0034.0000)
at com.android.dx.cf.direct.DirectClassFile.parse0(DirectClassFile.java:472)
at com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)
at com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIfNecessary(DirectClassFile.java:388)
at com.android.dx.cf.direct.DirectClassFile.getMagic(DirectClassFile.java:251)
at com.android.dx.command.dexer.Main.processClass(Main.java:704)
at com.android.dx.command.dexer.Main.processFileBytes(Main.java:673)
at com.android.dx.command.dexer.Main.access$300(Main.java:83)
at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:602)
at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)
at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)
at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)
at com.android.dx.command.dexer.Main.processOne(Main.java:632)
at com.android.dx.command.dexer.Main.processAllFiles(Main.java:510)
at com.android.dx.command.dexer.Main.runMonoDex(Main.java:280)
at com.android.dx.command.dexer.Main.run(Main.java:246)
at com.android.dx.command.dexer.Main.main(Main.java:215)
at com.android.dx.command.Main.main(Main.java:106)
...while parsing com/hannesdorfmann/mosby/mvp/MvpPresenter.class
1 error; aborting

:sample:preDexDebug FAILED

FAILURE: Build failed with an exception.

• What went wrong:
  Execution failed for task ':sample:preDexDebug'.

  com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/bin/java'' finished with non-zero exit value 1

• Try:
  Run with --info or --debug option to get more log output.

• Exception is:
  org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':sample:preDexDebug'.
  at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)
  at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46)
  at org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:35)
  at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:64)
  at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
  at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:42)
  at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
  at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53)
  at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
  at org.gradle.api.internal.AbstractTask.executeWithoutThrowingTaskFailure(AbstractTask.java:305)
  at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.executeTask(AbstractTaskPlanExecutor.java:79)
  at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:63)
  at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:51)
  at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:23)
  at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:88)
  at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:29)
  at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:62)
  at org.gradle.execution.DefaultBuildExecuter.access$200(DefaultBuildExecuter.java:23)
  at org.gradle.execution.DefaultBuildExecuter$2.proceed(DefaultBuildExecuter.java:68)
  at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)
  at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:62)
  at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:55)
  at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:149)
  at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:106)
  at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:86)
  at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:80)
  at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:33)
  at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:24)
  at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:36)
  at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26)
  at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:51)
  at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:171)
  at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:237)
  at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:210)
  at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35)
  at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
  at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:206)
  at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169)
  at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
  at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
  at org.gradle.launcher.Main.doAction(Main.java:33)
  at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
  at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:54)
  at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:35)
  at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
  at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:33)
  at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:130)
  at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:48)
  Caused by: java.lang.RuntimeException: com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/bin/java'' finished with non-zero exit value 1
  at com.android.ide.common.internal.WaitableExecutor.waitForTasksWithQuickFail(WaitableExecutor.java:116)
  at com.android.ide.common.internal.WaitableExecutor$waitForTasksWithQuickFail$0.call(Unknown Source)
  at com.android.build.gradle.tasks.PreDex.taskAction(PreDex.groovy:106)
  at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:63)
  at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$IncrementalTaskAction.doExecute(AnnotationProcessingTaskFactory.java:235)
  at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:211)
  at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$IncrementalTaskAction.execute(AnnotationProcessingTaskFactory.java:222)
  at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:200)
  at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80)
  at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61)
  ... 47 more
  Caused by: com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/bin/java'' finished with non-zero exit value 1
  at com.android.build.gradle.internal.process.GradleProcessResult.assertNormalExitValue(GradleProcessResult.java:42)
  at com.android.builder.core.AndroidBuilder.preDexLibrary(AndroidBuilder.java:1296)
  at com.android.builder.internal.compiler.PreDexCache.preDexLibrary(PreDexCache.java:122)
  at com.android.builder.core.AndroidBuilder.preDexLibrary(AndroidBuilder.java:1248)
  at com.android.builder.core.AndroidBuilder$preDexLibrary$7.call(Unknown Source)
  at com.android.build.gradle.tasks.PreDex$PreDexTask.call(PreDex.groovy:150)
  at com.android.build.gradle.tasks.PreDex$PreDexTask.call(PreDex.groovy)
  Caused by: org.gradle.process.internal.ExecException: Process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/bin/java'' finished with non-zero exit value 1
  at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:365)
  at com.android.build.gradle.internal.process.GradleProcessResult.assertNormalExitValue(GradleProcessResult.java:40)
  ... 6 more

BUILD FAILED

Total time: 46.363 secs

Annotated adapter exception

Hello,
I keep getting an exception from the AnnotatedAdapter in the ViewHolder:

android.content.res.Resources$NotFoundException: String resource ID #0x1

This doesn't make sense because other views in the ViewHolder can be set just fine. It is this one view that is causing the problem.

Please advise,
Igor

null view state

Seeing this issue sometimes. All my createViewState functions have been implemented creating new instances of states.

java.lang.NullPointerException: ViewState is null! That's not allowed
       at com.hannesdorfmann.mosby.mvp.viewstate.ViewStateManager.saveInstanceState(ViewStateManager.java:103)
       at com.hannesdorfmann.mosby.mvp.viewstate.MvpViewStateFragment.saveViewStateInstanceState(MvpViewStateFragment.java:79)
       at com.hannesdorfmann.mosby.mvp.viewstate.MvpViewStateFragment.onSaveInstanceState(MvpViewStateFragment.java:70)
       at android.support.v4.app.Fragment.performSaveInstanceState(Fragment.java:1936)
       at android.support.v4.app.FragmentManagerImpl.saveFragmentBasicState(FragmentManager.java:1654)
       at android.support.v4.app.FragmentManagerImpl.saveAllState(FragmentManager.java:1722)
       at android.support.v4.app.FragmentActivity.onSaveInstanceState(FragmentActivity.java:527)```

Travis CI

• Build and run tests on every commit
• Release SNAPSHOTS to maven central

Migrate to Butterknife 7

Provide base classes that do not extend from support library

It would be a nice enhancement to provide alternative classes that do not use support library.

Production app with Mosby : RuntimeException: Parcel android.os.Parcel Unmarshalling unknown type code 47068 at offset 304

I can not reproduce it, As it was one some random users device, I just caught it in Crashlytics.
Here is the crashlytics report ( with whole exception and other device/android details )
http://crashes.to/s/de64b446301/details

Does it have anything to do with ParclablePlease ( or it's pro-guard configuration )?
Or Any other Mosby components ?

This is the first time such error has occurred and it doesn't see on a new device. it is a kind of old device. App works fine in many devices as I can see in the analytcis and crashlytics.

Some discussion in similar Stack Overflow with similar question
http://stackoverflow.com/questions/13997550/unmarshalling-errors-in-android-app-with-custom-parcelable-classes

Pasting the stack trace here as well

java.lang.RuntimeException: Unable to start activity ComponentInfo{com.timesbuzz.news/com.timesbuzz.news.MainActivity}: java.lang.RuntimeException: Parcel android.os.Parcel@40da0ad0: Unmarshalling unknown type code 47068 at offset 304
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2205)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2240)
at android.app.ActivityThread.access$600(ActivityThread.java:139)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1262)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:156)
at android.app.ActivityThread.main(ActivityThread.java:4987)
at java.lang.reflect.Method.invokeNative(Method.java)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
at dalvik.system.NativeStart.main(NativeStart.java)
Caused by: java.lang.RuntimeException: Parcel android.os.Parcel@40da0ad0: Unmarshalling unknown type code 47068 at offset 304
at android.os.Parcel.readValue(Parcel.java:1926)
at android.os.Parcel.readMapInternal(Parcel.java:2098)
at android.os.Bundle.unparcel(Bundle.java:223)
at android.os.Bundle.getParcelable(Bundle.java:1158)
at android.app.Activity.onCreate(Activity.java:900)
at android.support.v4.app.FragmentActivity.onCreate(FragmentActivity.java:255)
at android.support.v7.app.ActionBarActivity.onCreate(ActionBarActivity.java:122)
at com.hannesdorfmann.mosby.MosbyActivity.onCreate(MosbyActivity.java:38)
at com.hannesdorfmann.mosby.mvp.MvpActivity.onCreate(MvpActivity.java:34)
at com.timesbuzz.news.MainActivity.onCreate(MainActivity.java:58)
at android.app.Activity.performCreate(Activity.java:4538)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1071)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2161)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2240)
at android.app.ActivityThread.access$600(ActivityThread.java:139)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1262)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:156)
at android.app.ActivityThread.main(ActivityThread.java:4987)
at java.lang.reflect.Method.invokeNative(Method.java)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
at dalvik.system.NativeStart.main(NativeStart.java)

AndroidRuntime NullPointerException

Hello,
when using your MvpViewStateFragment in my app and rotating the device, I get this crash:

java.lang.NullPointerException: ViewState is null! That's not allowed
at com.hannesdorfmann.mosby.mvp.viewstate.ViewStateManager.saveInstanceState(ViewStateManager.java:103)
at com.hannesdorfmann.mosby.mvp.viewstate.MvpViewStateFragment.saveViewStateInstanceState(MvpViewStateFragment.java:79)
at com.hannesdorfmann.mosby.mvp.viewstate.MvpViewStateFragment.onSaveInstanceState(MvpViewStateFragment.java:70)
at android.support.v4.app.Fragment.performSaveInstanceState(Fragment.java:1936)
at android.support.v4.app.FragmentManagerImpl.saveFragmentBasicState(FragmentManager.java:1654)
at android.support.v4.app.FragmentManagerImpl.saveAllState(FragmentManager.java:1722)
at android.support.v4.app.FragmentActivity.onSaveInstanceState(FragmentActivity.java:527)
at com.hannesdorfmann.mosby.MosbyActivity.onSaveInstanceState(MosbyActivity.java:44)

Please advise,
Igor

Error in Mail Sample if i try to write a new Mail on a 4.3 Android

Hey Hannes,

if i try to start your Mail Sample on a Android 4.3 Version (Genymotion Google Nexus 4 - API 18) the i got an Error if i try to send a Mail. If i try the same on a 5.0 (also Genymotion Google Nexus 4 - API 21)... everything is fine...
I got this:

6-25 17:25:12.703 2221-2221/com.hannesdorfmann.mosby.sample.mail E/Event﹕ Could not dispatch event: class com.hannesdorfmann.mosby.sample.mail.model.event.MailSentEvent to subscribing class class com.hannesdorfmann.mosby.sample.mail.write.WritePresenter
java.lang.NoSuchMethodError: com.hannesdorfmann.mosby.sample.mail.write.WriteActivity.finishAfterTransition
at com.hannesdorfmann.mosby.sample.mail.write.WriteActivity.finishBecauseSuccessful(WriteActivity.java:187)
at com.hannesdorfmann.mosby.sample.mail.write.WritePresenter.onEventMainThread(WritePresenter.java:54)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:525)
at de.greenrobot.event.EventBus.invokeSubscriber(EventBus.java:498)
at de.greenrobot.event.EventBus.invokeSubscriber(EventBus.java:492)
at de.greenrobot.event.HandlerPoster.handleMessage(HandlerPoster.java:67)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:5103)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:525)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:737)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:553)
at dalvik.system.NativeStart.main(Native Method)

Create Github pages

Create github pages:

• Copy the most content from my blog to have all resources in one place.
• Generate javadoc

Work in progress.

MvpBasePresenter and a Retained MvpFragment, reference to view will always be null after rotation

Subclassed MvpFragment and in onCreate() setted it to retain instance. after rotating the device isViewAttached() returns false even though attachView() was called.

logs: (when device is rotated)
without retainInstance:

detachView()
dropReference()
attachView(v): view is null? false
isViewAttached() -> true=true and ?
getView()```

with retainInstance

detachView()
dropReference()
attachView(v): view is null? false
isViewAttached() -> false=false and ?
isViewAttached() -> false=false and ?

log: Log.d("isViewAttached() -> " +isAttached + "=" + (viewRef != null) + " and ?");
The ? is viewRef.get() != null but it would crash since viewRef is null

Suggested proguard configs ?

I have already used Mosby to make one app live.

https://play.google.com/store/apps/details?id=com.timesbuzz.news

Unfortunately I am a naive Android Developer and made classic mistake.
The released apk doesn't work. I have messed up the proguard config.

Most of the heavy lifing is done by Mosby ( and its components like dagger1, retrofit, fragmentargs,Icepick etc)

So what is the most appropriate proguard config for any project which leverages the mosby ?

It's a kind of blocker issue and I humbly request if it is possible to provide the proguard config for mosby and it's components based project.

MvpViewStateFragment<MvpPresenter> vs MvpViewStateFragment<MvpView, MvpPresenter>?

In the samples and your blog post I see you used a version of MvpViewStateFragment that takes a View and Presenter, but in the library v1.0.0 it only takes a presenter. Am I doing something wrong?

@Scope usage

Hi,
why don't you use @scope from javax.inject.Scope in your project. I thought Dagger2 implementations should have things like @ApplicationScope or @ActivityScope.

Thanks,
Igor

request - update blog post

I know you are currently working on a new blog post for the mail sample. I think since the initial mosby blogpost is the main source of documentation for this issue, it would be nice if that was updated to reflect changes from 1.1.0 (delegates). A better long term solution would be to start using the github wiki.

ReposAdapterBinder

Hello,
here you have ReposAdapter that implements ReposAdapterBinder: https://github.com/sockeqwe/mosby/blob/master/sample-dagger2-rx/src/main/java/com/hannesdorfmann/mosby/sample/dagger2/repos/ReposAdapter.java#L18

However, I cannot find ReposAdapterBinder anywhere in the project. Please explain.

Thanks,
Igor

ViewState access from Presenter

Hi, great library. I'm familiar with this pattern and I'm glad to see a good library and community around it. But I can see an serious issue, or I'm missing something. ViewState is created by View and only View has access to it. In your samples Presenter call method on View and it changes itself and sets proper State.
Lets imagine that Presenter is doing some background job. After finishing want to call View and change it's State. But screen rotation is happening in the same moment. So when Presenter want to update View between onDetach() and onAttach() this State is lost forever. Maybe it would be better to store ViewState in Presenter? It's not destroyed if fragment has retain flag on. Only problem is when Activity is killed by system in case of memory shortage. Maybe we can save Presenter with ViewState in Bundle to survive recreation by low memory clean up?

Kotlin Support

☑ Mosby itself seems to be ready to be used in Kotlin. A little sample project already works as expected.

❑ Third party annotation processors don't work right now, but I haven't tested them with kotlins annotation processing support introduced lately.

      ❑ Butterknife: Probably Butterknife could be replaced with Kotterknife, but it's not clear if Kotterknife will ever see version 1.0 . However, adding Kotterknife's dependency should be done in the end users app project which uses Mosby and not in Mosby itself. So supporting Kotterknife is not needed in Mosby itself.

      ❑ FragmentArgs: May need an improved Annotation Processor for Kotlin. However, the goal should be that the dependency to Kotlin's FragmentArgs annotation processor should be added in end user application project. See this issue: sockeqwe/fragmentargs#21

      ❑ Icepick doesn't work right now. See this issue: frankiesardo/icepick#47

Mosby 2.0 can only be released after all annotation processors work properly and don't conflict with their java counterparts.