Loading...
Home
  • Tech Blogs
  • Videos
  • Conferences
    • Droidcon News
    • Upcoming Conferences
    • Become a Partner
    • Past Events
    • Keep Me Informed
    • Diversity Scholarships
  • Community
    • droidcon Team
    • How to Hold a Droidcon
  • Android Careers
Sign In

Global CSS

 

Feature Components in Android

 

 
Anup Ammanavar
Mobile App Developer
Published: September 07, 2020
Tweet
Share
 

Creating loosely-coupled Reactive Feature Components

 

Photo by Charles Deluvio on Unsplash

 

Overview

Re-usability is a pattern that solves the problem of duplication. It can be as simple as creating Functions, Classes, Interfaces to more complex UI-Components and Feature-Components.

The article focuses initially on the re-usability of UI-Views(UIComponents) and then the FeatureComponents. Emphasis is on the Dependency-Inversion Principle, where both the Low-level(Feature Component) and High-level component (One incorporating the low-level components) both depend on abstraction, to create loosely-coupled systems.

 

A peek into UI Component [UI-level]

Before proceeding to Feature Components, we’ll start with a brief overview of UI-Components(re-usability of Views).

 Image for post

UI Component design. Low-level component and High-level Component

 

Data is sent downwards from HLC → LLC, while the Events are sent from the LLC → HLC.

Low-Level Component (UIComponent): It only renders itself based on the data provided by the High-level component. And propagates the events to the High-level component(👇). It’s devoid of business-logic.

 

Low-Level Component overview

 

High-level Component: Provides the data for the UI-Components(LLC), and handles the events from the UIComponent(👇). Example: Click events. It holds all the business logic. It is a single source of truth that holds the state/data for all the UI-Component.

 

High-Level Component Overview

 

Reactive Feature Component

UIComponents are useful when there is re-usability of UI-views, while Feature Component has larger functionality.

  • Apart from receiving the data, it also produces the data itself.
  • Contains its own business-logic.
  • Needs lesser hand-holding than UIComponent and is useful for designing SDKs and standalone features.

Why Reactive Feature Component?:- With multiple Components producing data, we need a way to synchronize them. Ex: Data produced by FC1 might affect FC2.

We will take a bottom-up approach, where we Design and Implement the Low-level Feature components first, and later look their incorporation into the High-level Component.

 

Design of Low-level Feature Components(LLC).

For demonstration purposes, we build a Flight Booking screen. It includes the following four Low-level Feature Components DateSelection, FlightsSelection, HotelSelection, and SummaryComponent.

 

Image for post

Booking screen Wireframe

 

The design of the FeatureComponent looks like this(👇)

 

Image for post

Design of Feature Components. Also showing the different terminologies.

 

Let’s look at the Flight Feature Component

 

1. EventDispatcher

Dispatches the events to High-level-Component. This is like a channel through which events are sent to the outside world(HLC).

 

Event Dispatcher — Propagates the events from Feature Component to HLC

 

  • onFlightSelection a flight selection event is sent to the outside world. This may then be used by another FeatureComponent.

 

2. EventReceiver

Feature Component receives the events from the High-level component.

 

Event Receiver — Receives the event from the High-Level Component

 

This is a gateway through which it receives events from the HLC.

  • dateChangeA change in date from another component is received. On reception, it fetches the flights for the said date.
  • onRemoveSelection clears the selected flight.

 

3. UI

The Feature Component has its own UI.

 

UI

 

  • Every FeatureComponent extends the UI interface, implying that they define their own UI.
  • HLC attaches it. render is a public API for the HLC to render the FeatureComponent by passing the view(More detail later in Implementation 👇).

 

Implementation of Low-level components.

Defining the FeatureComponent Contract

 

FeatureComponent protocol

 

  • All FeatureComponents implement this interface. It is generic on EventDispatcher.

1. EventDispatcher

 

Flight component delegating the click events to the FlightEventDispatcher.

 

  • EventDispatcher is a dependency of the Feature Component.
  • The component passes on the events to this interface. In this case, it sends the selectedFlight event.

 

2. EventReceiver

 

 

  • Flight FeatureComponent implements the FlightEventReceiverinterface. This provides it the capability to receive events from the HLC.
  • In this case, it receives dateChange and removeSelection events and passes them to its business layer(store).

 

3. Defining and managing the UI

 

Flight Feature Component implementing the View

 

  • Flight FeatureComponent implements the UI interface on FlightView defining its own UI.

Additionally, FeatureComponent additionally coordinates between its own business-layer and the view layer, by acting as a middle-man. (👇)

 

Image for post

Interaction between Business-layer and View-layer of the Feature Component

 


Design & Implementation of High-level Component(Booking screen)

Divide it into 2 parts — Business layer and View-Layer

 

1. Business-layer

 

Booking screen business-logic layer — Creation and receiving of Events from Component

 

  • It creates the Feature Components.
  • To receive events from the FeatureComponents(LLC), HLC implements the dispatcher (FlightEventDispatcher) in the form of inner class (FlightEventDispatchListener), which is then passed on as a dependency for component creation(👆).

 

Business-layer sending events to the Component.

 

  • To send events to Feature Component, HLC can directly call the methods of FlightComponent, as it has the capability to receive events. See clearSelections .

 

2. View-layer

 

View layer — Rendering the FeatureComponent by supplying the view to render itself.

 

  • It is only responsible for rendering the FeatureComponents created by the business-layer.

 

Conclusion with minor tweaks

What if HLC components have a large number of components? The HLC would be over-burdened with synchronizing and passing the events between different FeatureComponents.

  • A better approach would be to make the HLC a mediator for passing events to FeatureComponents.
  • Whenever it receives an event from one FeatureComponent, it passes the event blindly to other FeatureComponents.
  • All FeatureComponent receive all the events but chooses the events on which they want to react and ignore the rest.
  • This way both are loosely coupled and any component can be attached to the HLC.

You can find the demonstration example here.

 

 

Tags: Android, Kotlin, Modular Architecture, Android App Development, AndroidDev

 

View original article at: 


 

Originally published: September 07, 2020

Android News
Our Engineering Roadmap
Our Engineering Roadmap

By Mark Ng

We just completed our engineering road map for our Android apps at Australia Post. Each year we get together and try to decide on what we are going to do from an engineering perspective for the next 12 months. Each team gets to decide on what should be done now, what they want to complete by the end of the year and whats on the horizon for next year.

By ProAndroidDev -
Android News
Android Activity Lifecycle considered harmful
Android Activity Lifecycle considered harmful

By Eric Silverberg

The Android activity lifecycle is one of the first architectural concepts learned by a new Android developer. Ask any Android dev and they’ll likely all have seen this handy diagram from Google: 

By ProAndroidDev -
Android News
Our Safe Approach to Android Jetpack Navigation in a Multi-Modular App
Our Safe Approach to Android Jetpack Navigation in a Multi-Modular App

By Alejandro Weichandt

It has been a year since we started working on the Android version of the mobile app at Sync. During that year, we faced more than once that moment when we had to choose which path to follow on an Architectural decision. This story is about Navigation.

By ProAndroidDev -
Android News
Custom KotlinX Serializers
Custom KotlinX Serializers

By Jobin Lawrance

Let’s say we have a third-party class that we are using as a type in one of our data class that we want to be serialized, then we have to write a custom serializable for @Serializable to work.

 

By ProAndroidDev -
droidcon News

Tech Showcases,

Developer Resources &

Partners

/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/home-details/EmployerBrandingHeader
EmployerBrandingHeader
https://jobs.droidcon.com/
/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/jobs-droidcon/jobs.droidcon.com
jobs.droidcon.com

Latest Android Jobs

http://www.kotlinweekly.net/
/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/kotlin-weekly/Kotlin Weekly
Kotlin Weekly

Your weekly dose of Kotlin

https://proandroiddev.com/
/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/pad/ProAndroidDev
ProAndroidDev

Android Tech Blogs, Case Studies and Step-by-Step Coding

/detail?content-id=/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/Zalando/Zalando
/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/Zalando/Zalando
Zalando

Meet one of Berlin's top employers

/detail?content-id=/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/Academy for App Success/Academy for App Success
/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/Academy for App Success/Academy for App Success
Academy for App Success

Google Play resources tailored for the global droidcon community

Follow us

Team droidcon

Get in touch with us

Write us an Email

 

 

Quicklinks

> Code of Conduct

> Terms and Conditions

> How to hold a conference

> FAQs

> Imprint

Droidcon is a registered trademark of Mobile Seasons GmbH Copyright © 2020. All rights reserved.

powered by Breakpoint One