Migrate to gradle the build system of the remaining demo projects:

• MultipleContacts
• MultpileActivityTabHost
• PinchZoomDetector
• PushNotifications
• simperAudioStreamer
• sms
• TabHostExample
• TabHostMultipleActivityBrowsing
• TabHostSelfContainedTabBrowsing
• wizard

And update compileSdk and targetSdk versions to the last available.

This PR adds the task updateDemos that verifies

• that the application id follows the pattern com.novoda.demo.<path>
• that a readme exists for all demos
• that all demos are listed in the global readme file.
• ~~that all demos use the android-command plugin.~~

A change log file is also added.

Spritz is a new library for seamlessly animating a Lottie view by swiping in a ViewPager.

Documentation

The root directory of the project has a README that explains how to use the library with a detailed list of all methods. The library doesn't have a Javadoc yet.

GIF

The outcome is shown in the demo app:

Next steps

As soon as this library is merged on master, I'll add the publish plugin so we can release it as an open source library on maven.

Tracked in JIRA by PT-257

Scope of the PR

Adds a recipe which talks about how to change the Locale of a Device for instrumentation tests using a TestRule.

Adds a demo showing how to implement a 'chips' view using 2 libraries:

• Chips library from EyeEm: Doesn't seem to be flexible enough for us so didn't do much on this one.
• Splitwise TokenAutoComplete: Decided to see if I was able to implement what we need with this library (entry of tags but we need to show the hint if the user isn't typing something and also delete tag by tag but selecting it first - couldn't get this to work yet)

| Main screen | Eyeem | Splitwise | | --- | --- | --- | | | | |

This PR migrates to gradle the build system of the following demo projects:

• CarouselFragment
• CompassExample
• ContactSelector
• CustomActivityTransition
• CustomTabsHack
• DynamicListItems
• encryption
• FixedSizeTextColumns
• Fragments
• GsonJsonWebservice

LiveData & ViewModel

This PR is part of a series of PRs to explore Architecture Components. The aim of this series is to showcase how to use Architecture Components and discuss tradeoffs, not to write a perfectly designed app. With that in mind, changes are been kept to the minimum necessary to better show what are the needed changes.

This PR is meant to showcase how to replace RxJava with LiveData and ViewModel.

In this project, RxJava was used to perform asynchronous work in a separate thread, execute some transformations on the downloaded data and callback the main thread with the result.

All that can be done with LiveData + ViewModel:

• Asynchrony is achieved through retrofit enqueue(retrofit2.Callback<T>).
• LiveData is just a data holder class that can be observed. When you post a value into a LiveData instance the observer will be notified in the main thread.
• A ViewModel stores the related UI data state and it's lifecycle aware: the stored data will survive configuration changes.

The sample app existing key components are:

• MainActivity : represents the app UI, a list of movies fetched from IMDB. The list is paged: when the user reaches the bottom a new page is fetched.
• MovieService : this class acts as repository and view state holder. It's composed with MoviesApi and contains a MoviesSate object to store the list of fetched movies and the current page. It provides asynchrony and api to domain data mapping with RxJava
• MoviesApi : A Retrofit API definition interface, describes the API calls but has no logic

The proposed changes in this PR change that scenario:

• A new key component, MoviesViewModel, is introduced. It's responsibilities are store the app's UI state and transform API data into domain data. Because MoviesViewModel is a ViewModel it's linked with MainActivity's lifecycle, so there's no need to manage subscription state.
• LiveData replaces RxJava as delivery mechanism to observe data changes.
• MovieService responsibilities are reduced to only make network calls using MovieApi

Considerations

This app is divided in two modules: app and core. Originally MovieService was inside core but I moved it into app in the destination branch before opening the PR. The reason was to keep the diff easier to follow (which is the main goal of this PR). LiveData depends on Android so a modified version of MovieService would need to go into app. If the original MovieService were inside core the diff would consider them separate files and instead of highlight only the changes it would mark the whole files red and green

Follow up

Upcoming PRs will showcase how to use other Architecture Components:

• ViewModel & LiveData (this PR)
• DataBinding #42
• Paging
• Room
• Navigation
• WorkManager

In order to showcase some of those components, it might be necessary to extend the app and add a few more use cases and screens.

Progress will be tracked here: https://github.com/novoda/android-demos/projects/1

Change google() repository & jcenter() repository access priority so that the gradle build would not fail to resolve dependencies as per latest Android Studio update.

Reference: https://stackoverflow.com/questions/50584437/android-studio-3-1-2-failed-to-resolve-runtime/50758769

Scope of the PR

Adds a recipe on how to create and integrate the newish Native Ads Express.

Reasons to exist

• Having a single guide to walk you through the process of creating and Advert and integrating it is more useful than checking separate documentation for each task.
• Google documentation is not very clear about advert sizes. At first sight it looks like the sizes you define when creating an Ad is the size you need to use later when integrating it. This cookbook tries to clarify that.

The current push demos are very outdated and there are better alternatives:

• Better demos for urban airship:https://github.com/urbanairship/android-samples/
• Better demos for gcm: https://github.com/google/gcm

This PR is open for discussion what push demos could be added in the future.

This PR adds short readme content for all projects.

For the first demos, I fixed some issues to make them work. At the end, I just added the readme files so we can decide which demos are important to us.

Description

This replaces a mvi'ish implementation of a movie search with a reusable implementation of MVI.

Considerations

First things first, this is the first iteration. There is lot's of room for improvements in our implementation of the pattern and for covering more use cases like screen orientation, one time events like (navigation, dialogs, etc.).

Furthermore, this PR introduces documentation around our implementation of MVI and the different components.

In the previous implementation, the SearchResultsViewable and SearchInputViewable did expose callbacks for user actions and methods to render a view state. The SearchResultsPresenter did register for these callbacks and forwarded the user actions to the SearchResultsModel. Furthermore, it observed the state from that model, mapped it to a view-state and forwarded this to the above-mentioned views. The SearchResultsModel was responsible to implement the business rules and to expose a stream of state changes according to them.

We replaced the views with a single MVIView<SearchAction, SearchState> which exposes an Observable<Action> and renders a SearchState. Furthermore, we moved all the business logic into the SearchMiddleware<SearchAction, SearchState, SearchChanges>, which exposes an Observable<SearchChanges>. These SearchChanges are then observed by the SearchReducer, which maps them to a SearchState. And finally, we introduced the BaseStore<Action, State, Change> as a use case agnostic class, which collaborates with the above components to connect the different data streams.

Data Flow

| High-level Diagram|Sequence Diagram| |----|----| || |

Paired with

@gbasile @zegnus @lgvalle @Michal-Novoda

This PR adds checkout screens, so that we can add a full end-to-end shopping flow test. Still work in progress as the app can't run. There is an issue in App.kt where DaggerAppComponent isn't being recognised. Possibly just a configuration issue.