New sample proposal

I'd like to create a new sample to illustrate the Model View Intent pattern. Full Android examples for MVI are hard to find. It's a pattern that has seen wide adoption in the Javascript and .NET world. Target audience include, but not limited to:

• Developers making the pivot from an imperative to declarative style of programming.
• Developers looking for best-practices in functional or reactive programming on Android.

Here are some articles/examples explaining the core principles of MVI and unidirectional flow:

• http://hannesdorfmann.com/android/model-view-intent
• https://cycle.js.org/model-view-intent.html
• http://thenewstack.io/developers-need-know-mvi-model-view-intent/

Proposed stack

I'm hoping to use specific libraries to achieve this in the cleanest possible way. A requirement with the android-architecture samples is to use accepted industry standard. A few of these libraries are new as of this year, but I believe they still fulfill that requirement. I've taken the time to establish a small 'pedigree' for each.

The following are battle-tested libraries. Battle tested here means that they have documented use, in production, at major companies with a large user base. Places such as Square, Groupon, Trello, Shopify, etc. One notable exception is RxJava2. RxJava 2 has major community backing, and will see a production release later this month.

Also, the following all have well-know, senior maintainers with established track records. Below a detailed list with rationale/credentials:

• RxJava 2
  • Great talk by Jake Wharton outlining usage & benefits
  • Observable and Flowable clears up the muddled semantics around Backpressure in RxJava 1.
  • Better type safety.
  • Improved Subscriber model.
  • Currently RC4, General availability planned for 29/10/2016
  • Contributors include Jake Wharton and David Karnok
  • IMO deprecates RxJava 1.
• Retrofit
  • Battle tested, used in other samples.
  • RxJava 2 adapter currently available, built by JakeWharton.
• Toothpick
  • Lightweight DI library.
  • Full-featured, runtime based, but reflection free, implementation of JSR 330.
  • Performant and much less code overhead / complexity than Dagger 2.
  • Great presentation outlining usage & benefits.
  • Audio for the talk
  • Primary maintainer is Stephane Nicolas, senior engineer at Groupon.
• Retrolambda
  • Lambdas are necessary for readable functional / reactive code.
  • Retrolambda routinely used in production for big projects (Square, Trello, etc.)

This pr updates the Dagger sample to now us modern best practices such as subclassing DaggerApplication as well as the new @ContributesInjector construct.

I'd like to create a sample that demonstrates the power and elegance of Kotlin coroutines. It will use MVVM, Data Binding and Architecture Components (ViewModel and possibly LiveData). I plan to branch it off dev-todo-mvvm-live-kotlin. The suggested new branch name is dev-todo-mvvm-live-kotlin-coroutines.

The primary objective is to select and consistently apply a small subset of essential Kotlin coroutine idioms.

Because new version has strict check for null-ptr of context or activity in fragments. It would be nice to have new and early experience with this new gradle feature.

I was surprised to see the rxjava example still uses rxjava 1. Has there been any work related to an example using rxjava 2 or are there plans on doing this ?

At the moment there is only TravisCI configuration file. Adding those for CircleCI would be fairly easy to do and Jose said it could be a nice addition to the project. I am willing to do it if welcomed. In the case I need to merge on all projects, do I need to create a PR for each or one would be enough for the merge-master to pass it on the others?

Error:Entities and Pojos must have a usable public constructor. You can have an empty constructor or a constructor whose parameters match the fields (by name and type).

I want to integrate the latest architectural components (ViewModel, LiveData, LifeCycleOwner) into the todo-mvvm. Should there be a new branch with the name [todo-mvvm-{newandroidarch/somethingelse}] or should I start editing in this branch only?

Hi everyone,

I decided to try making a sample that only uses a single Activity architecture using the Conductor library.

I've put the branch up here and I'd really appreciate any feedback!

It turned out to not be too difficult, the Activities and Fragments became Controllers and everything else stayed the same. I had to do some interesting code around getting the DrawerLayout working and constantly changing the ActionBar to have new stuff in it.

The main thing left to do is that it broke a few of the Espresso tests and also made most of them super flakey. The problem is that the test no longer knows that it needs to wait while the next Controller loads (I guess Espresso is usually aware of Activity transitions and I no longer have that crutch). I had a look at using IdlingResource to solve this, but I'm not experienced with Conductor or Espresso, I'll keep working on it. Also, the hermetic UI tests of individual Activities will probably never work hermetically since I don't think I can jump into a specific Controller like you can with Activities, you need to navigate there.

Hi,

Could you please review this ?

This patch makes the unit test method calls order sensitive.

I guess the transition from 'true' to 'false' is important for the test. mTasksView).setLoadingIndicator(true); mTasksView).setLoadingIndicator(false);

I've built a small example of how we could use RxJava across the View/Presenter bridge. Benefits include the possibility of writing Presenter tests as observable chains, cleaner observable chain building in the presenter (allows for debouncing, more sophisticated UX behavior, etc.)

Small note on the change to the Contract, I've moved the emitting Observable to the view side. I believe this still respects the MVP model, based on this model:

Notes:

• Changes to contract to reflect View's emitter/consumer nature when using Observables.
• Example of using RxRelay to hide implementation details / lifecycle issues from presenter.
• Example of using RxBindings on View side.
• Added RetroLambda support.

Similarly to older issues that have since been either closed or fixed such as https://github.com/android/architecture-samples/issues/370 and https://github.com/android/architecture-samples/issues/123 and https://github.com/android/architecture-samples/issues/731 and https://github.com/android/architecture-samples/issues/663

This bug seems to have been long-standing, but with MutableStateFlow(UiState) it still persists - as on this screen, SavedStateHandle is used only for transferring screen arguments to the ViewModel, but is not actually used to preserve user inputs across process death.

https://github.com/android/architecture-samples/blob/7e9d96d808a0d25a689d14099ecf0eb3ea7d5b1f/app/src/main/java/com/example/android/architecture/blueprints/todoapp/addedittask/AddEditTaskViewModel.kt#L39-L40

On the other hand, TasksViewModel correctly persists the current filter state using savedStateHandle.getStateFlow.

https://github.com/android/architecture-samples/blob/7e9d96d808a0d25a689d14099ecf0eb3ea7d5b1f/app/src/main/java/com/example/android/architecture/blueprints/todoapp/tasks/TasksViewModel.kt#L64-L65

Filtering state on the tasks screen was originally fixed by setting it on the SavedStateHandle in this commit: https://github.com/android/architecture-samples/commit/cfb5ac6ea6a5c888b171d88d7ea4287a33af5cb9#diff-631edb6efa01767b52856a0e498dc3987e8a2f0e8ba02837377dfbc5684af0cfR111

Therefore, AddEdit screen should also correctly save/restore user inputs across process death.

• Updated dependencies that don't require updating the compileSdkVersion
• Moved repository info to settings.gradle file (changed in AGP 7.1)
• Turn off Jetifier check to optimize build
• Enable configuration cache to optimize build

When my activity is opened the first time I can collapse by dragging on the image but after switching to other tabs I can't collapse the layout by pulling on the image view. Once the view pager is scrolled, I can Collapse the toolbar using the top image view.Please look at the GIF on the link below. I think this is because of the view pager nested scrolling. I don't know the cause. but Why can't I drag the top Image view once the tab is switched?https://stackoverflow.com/questions/74611210/collapsingtoolbar-not-working-on-tab-switch

<?xml version="1.0" encoding="utf-8"?>
<androidx.coordinatorlayout.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    android:nestedScrollingEnabled="false"
    tools:context=".MainActivity">

<com.google.android.material.appbar.AppBarLayout
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:nestedScrollingEnabled="false"
    android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar">
<com.google.android.material.appbar.CollapsingToolbarLayout
    android:id="@+id/collapsingToolbarLayout"
    android:layout_width="match_parent"
    android:nestedScrollingEnabled="false"
    android:layout_height="256dp"
    app:titleEnabled="false"
    app:layout_scrollFlags="scroll|exitUntilCollapsed">
    <ImageView
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:src="@drawable/tool_bg"
        android:scaleType="centerCrop"
        app:layout_collapseMode="parallax"/>
    <View
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:background="@android:color/black"
        android:alpha="0.3"/>
<androidx.appcompat.widget.Toolbar
    android:id="@+id/toolBar"
    android:layout_width="match_parent"
    android:layout_height="48dp"
     app:layout_collapseMode="pin"
    android:background="@drawable/fade"
    app:title="hello"



    android:layout_marginTop="4dp"
    android:layout_marginStart="5dp"
    android:layout_marginEnd="5dp"
    app:menu="@menu/three_line"
    android:layout_marginBottom="48dp"
    android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar"
    />
    <com.google.android.material.tabs.TabLayout
        android:id="@+id/tabLayout"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_gravity="bottom"
        android:background="@android:color/transparent"
        app:tabSelectedTextColor="@color/white"/>
</com.google.android.material.appbar.CollapsingToolbarLayout>
</com.google.android.material.appbar.AppBarLayout>
<androidx.viewpager2.widget.ViewPager2
    android:id="@+id/viewPager"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    app:layout_behavior="@string/appbar_scrolling_view_behavior"/>
</androidx.coordinatorlayout.widget.CoordinatorLayout>

Hello, suppose we are building a vpn client, in which layer should the business logic and service class be placed? In the ui layer corresponding to its feature, or the domain layer