Rxjava Mvp Giphy

Showcase of RxJava used with MVP and some other popular android libraries
Alternatives To Rxjava Mvp Giphy
Project NameStarsDownloadsRepos Using ThisPackages Using ThisMost Recent CommitTotal ReleasesLatest ReleaseOpen IssuesLicenseLanguage
Android Tech Frontier10,389
2 years ago11apache-2.0
a year ago41apache-2.0Java
⚔️ A common architecture for Android applications developing based on MVP, integrates many open source projects, to make your developing quicker and easier (一个整合了大量主流开源项目高度可配置化的 Android MVP 快速集成框架).
6 months ago36apache-2.0Java
:closed_book: "任阅" 网络小说阅读器,3D翻页效果、txt/pdf/epub书籍阅读、Wifi传书~
7 months ago1apache-2.0Java
Android 技术中台,但愿人长久,搬砖不再有
Awesome Rxjava4,834
2 years ago5
RxJava resources
Android Mvp Architecture4,421
4 months ago40apache-2.0Java
This repository contains a detailed sample app that implements MVP architecture using Dagger2, GreenDao, RxJava2, FastAndroidNetworking and PlaceholderView
5 years ago50Java
:books:A pure reading App based on Material Design + MVP + RxJava2 + Retrofit + Dagger2 + Realm + Glide
3 years ago14apache-2.0Kotlin
:fire: 「停止维护」基于Kotlin+MVP+Retrofit+RxJava+Glide 等架构实现短视频类小项目,简约风格及详细注释,欢迎 star or fork!
4 years ago25mitJava
本项目仿最新版微信6.5.7(除图片选择器外),基于融云SDK,使用目前较火的 Rxjava+Retrofit+MVP+Glide 技术开发。相比上个版本,加入发送位置消息,红包消息等功能。
Android Mvp Mvvm Flytour2,885
2 years ago8apache-2.0Java
🔥🔥🔥 FlyTour是Android MVVM+MVP+Dagger2+Retrofit+RxJava+组件化+插件组成的双编码架构+双工程架构+双语言Android应用开发框架,通过不断的升级迭代该框架已经有了十个不同的版本,5.0之前工程架构采用gradle配置实现组件化,5.0之后的工程架构采用VirtualAPK实现了插件化,5.0之前采用Java编码实现,5.0之后采用Kotlin编码实现,编码架构由MVVM和MVP组成,工程架构和编码架构及编码语言开发者可根据自己具体的项目实际需求去决定选择使用,该框架是Android组件化、Android插件化、Android MVP架构、Android MVVM架构的集大成者,帮助你快速的搭建自己的App项目开发框架,以便把主要的精力放在自己的项目的业务功能实现上,另外在长期的工作实践中总结整理大量的实用工具类在项目lib_common组件的util包当中方便大家调用。
Alternatives To Rxjava Mvp Giphy
Select To Compare

Alternative Project Comparisons

Giphy RxJava MVP

A showcase of RxJava and Model View Presenter, plus a number of other popular libraries for Android development, including AutoValue, Retrofit, Moshi, and ButterKnife. Unit tested with Mockito covering any business logic.

The app is a simple master/detail implementation: we retrieve a list of gifs from the Giphy api and present them on the TrendingActivity in a RecyclerView. When a gif is clicked on, we load it in by itself in the GifDetailActivity.


This setup has a number of advantages over a non-MVP app architecture

  • it separates our concerns
    • the Presenter is view agnostic and does not care how an action was triggered, making a clear division which is easy to change
    • the view which implements the View interface is very simple - the methods are usually one liners, doing something on the android Activity e.g. just setting a view's state to View.GONE - which also makes them easy to test
  • it allows us to place all our business logic within the Presenter object and abstracts the View for easy mocking, so we can unit test all the things, e.g:
    • when we're doing a network request, does the loading indicator show when it starts, and hide when it ends?
    • are we ignoring clicks on the 'refresh' button when a network call doing a refresh is already in progress?
    • what happens when a network call fails?
    • ... etc
  • support for orientation changes (e.g. device rotation) with very little effort
  • the power of rxjava
    • Observables exposing future actions via the View interface, allowing our Presenters to be entirely stateless
    • easy to do long running operations off the main thread
      • in app code but also in the unit tests



The app is packaged by component/feature, under the com.emmaguy.giphymvp.feature package, to keep everything as private as possible. This means that any classes which contain logic for the trending feature is contained within feature.trending package and cannot be mistakenly used or extended elsewhere.

Each component consists of a Presenter class, a View interface which the corresponding Activity implements and a Module/Component for dependencies. The components currently map 1-1 to Activities, but could easily use custom views instead.

View interface

The View interface enables the Presenter to be pure Java and not have to know about anything android:

    interface View extends PresenterView {
            Observable<Object> onRefreshAction();

            void showLoading();
            void hideLoading();

The interface exposes:

  • actions that the user can perform e.g. clicking a button, swiping, etc. (these are the methods that return Observable<Object>)
    • we subscribe to each of these in the Presenter's one lifecycle method, onViewAttached
    • each subscription is added to a CompositeSubscription via the method unsubscribeOnViewDetach, which will unsubscribe from all subscriptions when the view is detached
    • we limit what the Presenter is exposed to by using a return type of Observable<Void>, often it's enough just to know the action has happened
  • actions which immediately update the view with a simple operation e.g. show or hide a progress bar (method name will usually starts with show/hide), or methods which set data/state
  • actions that start another Activity (prefixed with open e.g. openGifDetail)


Are responsible for presentation of whatever the view has (using a view interface), constrained by some business logic.

For example, TrendingPresenter can react to refreshes. The consequence of a refresh varies depending on whether we successfully retrieve gifs or not, we can either show the grid of gifs or an error.

While the view introduces two kinds of refresh, loading (a ProgressBar centered on screen as there's nothing else to see) and incremental loading (a swipe to refresh view), we have cheated slightly and just set both the loading and incremental loading to hidden after we refresh. The Giphy API does not support pagination, so this is not the place to try and demo incremental loading. We don't need to show incremental errors because we either have no data or some cached. In a real application, it's likely the cache is too stale to show anything useful, but this sample is not that complex!


A class containing state, for the moment this is just whether we have some gifs, or whether there's been an error


We only have one in this project, TrendingManager, which is responsible for managing the network and the cache. We hit the cache - if there's something in it, we go with that. If not, let's refresh and cache it.

An advantage of this separation is that we are able to have unit tests covering the useful logic here - do we actually save gifs in storage when we successfully get some? Do we avoid the network when we use the cache?


As you might expect, these classes just persist things. Here we only have TrendingStorage which is just an in memory cache of the last list of trending gifs we successfully received. No timestamp or concept of invalidation, just some gifs to show to the user.

Dependency Injection

This project does not use Dagger, instead it provides the required classes manually.

We instead create simple classes suffixed with Module that contain static factory methods that construct the required dependencies, and create interfaces suffixed Component which list the injectable items for each feature.

Example Module:

class TrendingModule {
    private static TrendingPresenter presenter;

    static TrendingPresenter trendingGifsPresenter() {
        return  new TrendingPresenter(trendingGifManager(), AndroidSchedulers.mainThread());

Example Component:

interface TrendingComponent extends BaseComponent {
    TrendingPresenter getPresenter();

Then, when the dependencies are needed, we can create the required components using the factory methods. We abstract this into the BaseActivity, which also performs the ButterKnife binding/unbinding and Presenter lifecycle methods attaching/detaching the view.

@CallSuper @Override protected void onCreate(final Bundle savedInstanceState) {

    unbinder = ButterKnife.bind(this);

We separate the createComponent and inject steps as an easy way to support orientation change - the first time we call both create and inject, any subsequent times we need to inject we can just call inject and we can reuse the classes - which means we use our memory cache of data from our network requests (held in TrendingStorage) rather than hit the network again.


Copyright 2016-2017 Emma Guy

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


Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
See the License for the specific language governing permissions and
limitations under the License.
Popular Mvp Projects
Popular Rxjava Projects
Popular Software Architecture Categories
Related Searches

Get A Weekly Email With Trending Projects For These Categories
No Spam. Unsubscribe easily at any time.