Let’s start with a clear warning: If you’re not a Mobile App Dev Geek like me, this article is not for you. Save some time and skip the article.

If you ask GPT this is the answer it spits out

CDUI (Client-Driven User Interface) is a software development approach where the client-side code is responsible for defining and rendering the user interface, allowing for dynamic UI generation based on data received from the backend.

Alot of jargons right ! Before we unravel whats Client Driven UI. We will cover some leading questions

What is a Mobile App?

A mobile app can be defined with two fundamental aspects:

1. User Interface (UI): This component of a mobile app comprises the visual elements and design principles that users interact with. It includes the arrangement of components, selection of colors, and choice of typography to create a visually appealing and user-friendly interface. The UI is responsible for presenting information, enabling user interactions, and defining the overall look and feel of the app.
2. Logic (UI Logic and Business Logic): The logic within a mobile app encompasses two distinct but interconnected components:

UI Logic: This refers to the set of rules and behaviors that govern how the user interface responds to user inputs and events. UI logic ensures that the app’s components function correctly, respond to user gestures, and provide a seamless and intuitive user experience.

Business Logic: Business logic represents the core functionality and operations of the app that are not directly related to the user interface. It defines how data is processed, stored, and manipulated, as well as the underlying algorithms and rules that drive the app’s intended purpose. Business logic ensures that the app delivers the intended services, processes data accurately, and performs any necessary computations.

Example: Bytes, a short 3 page app, of landing screen, category screen and article screen.

What is Mobile App Development?

Mobile app development involves creating software for mobile devices. In this process, a server and a client communicate using JSON data. While the server sends raw data, the client interprets and processes this data to independently create and manage the user interface (UI). UI elements and business logic are predominantly implemented on the client side, especially in the context of client-driven UI.

What is Client Driven UI ?

Client-Driven User Interface (UI) is an approach in app development where the client-side code is primarily responsible for defining and rendering the user interface, allowing dynamic UI generation and adaptation based on local data and logic.

And over simplified Steps are :

1.Component Creation: We meticulously designed and crafted user interface components tailored to the specific requirements of our application.

2.Data Parsing and Model Creation: Our next step involved parsing data and constructing models to efficiently manage and manipulate the information we received from various sources.

3.API Data Binding: We seamlessly integrated our components with data from APIs, ensuring a seamless flow of information. In this process, we also introduced essential business logic to enhance the functionality and user experience within our application.

4.Cross-Platform Implementation: To reach a broader audience and ensure a consistent user experience, we replicated this entire process on multiple platforms, including Android, iOS, and web.

5.Platform Releases: Finally, after rigorous testing and optimization, we delivered our application to users by submitting releases on all three major platforms — Android, iOS, and the web.

Does Client Driven UI Works?

Short Answer is YES, millions of apps ranging from games, social media, tools are build and they are updated billions of times every yea.r, and massive companies like Uber, AirBnb, SnapChat, Insta all run and are primarily built using client driven UI.

Problem with CDUI( Client Driven UI)

Lets take example of Bytes app to elaborate further

Problem No 1: UI is Point of No Return

In the realm of Client-Driven UI (CDUI), a series of steps can lead to what we refer to as the “Form of No Return” in UI development. This critical juncture signifies that making significant changes or updates to the user interface becomes an arduous process, often necessitating a new release cycle.

The sequence of events typically unfolds as follows:

1.Initial Development: In CDUI, you begin by designing and creating the user interface components. Initially, this allows for flexibility and adaptability.

2.UI Lock-In: However, as development progresses, if you make decisions that “lock in” or hardcode the UI layout, you inch closer to the “Form of No Return.” This means that the UI becomes less flexible and resistant to accommodating future changes.

3.Consequences: When you reach this critical stage, introducing new UI changes or adaptations requires going through an extensive release cycle. This entails additional development, testing, and app updates before users can experience the modifications.

Problem No 2: Not optimised for Runtime changes

In the realm of Client-Driven UI (CDUI), another notable challenge is its limited optimization for runtime changes. When the marketing team requests on-the-fly modifications, such as adding new buttons, conducting experiments, updating text, or changing values, CDUI may not be optimized for such dynamic alterations.

In CDUI, where UI components are often generated and managed based on data and logic present on the client side, accommodating runtime changes can be less straightforward. Here’s why this poses a challenge:

1.UI Generation: CDUI typically generates UI elements based on predefined templates and data sources. Adding entirely new components or altering existing ones at runtime may require substantial code adjustments and testing.

2.Data Binding: CDUI often relies on data-binding mechanisms, where UI elements are tied to specific data sources. When marketing teams request changes in real-time, ensuring that these modifications are seamlessly integrated without disrupting the existing UI can be complex.

3.Testing and Validation: Each runtime change introduces the potential for unforeseen issues or conflicts within the app. Rigorous testing and validation become crucial, adding to the development timeline.

4.Version Control: Managing multiple versions of the app can become challenging as runtime changes may create variations that need to be tracked and maintained.

Problem No 3: Repeated Layout and Business Logic

In the realm of Client-Driven UI (CDUI), a pervasive issue is the duplication of both layout and business logic across multiple platforms. This challenge revolves around the need to maintain consistency while developing for Android, iOS, and web platforms.

The key issues include:

Cross-Platform Duplication: CDUI applications aim for a unified user experience across different platforms. However, achieving this consistency often necessitates duplicating layout and business logic for each platform individually.

Redundant Effort: Developers are required to replicate the same UI layouts, designs, and interactive behaviors across Android, iOS, and web. This redundancy results in duplicated effort, consuming development resources and time.

Complex Maintenance: As the app evolves or updates are required, ensuring that layout and business logic remain consistent across platforms becomes increasingly challenging. Any changes must be meticulously applied to each platform, making maintenance complex.

Risk of Discrepancies: The more duplication there is, the greater the risk of introducing discrepancies or errors. These inconsistencies can negatively impact user satisfaction and the overall quality of the application.

What do we want to solve then??

What are the solutions?

To address the complexities arising from Client-Driven UI (CDUI), developers are exploring two primary alternatives:

1.Cross-Platform Development Frameworks: Many developers turn to cross-platform development frameworks, such as React Native, Flutter, or Xamarin. These frameworks empower developers to write code once and deploy it seamlessly across Android, iOS, and web platforms. By unifying the development process, these frameworks significantly reduce redundancy and streamline the task of maintaining consistency in the CDUI development landscape.

2.Server-Driven UI (SDUI): A novel paradigm gaining traction is Server-Driven UI (SDUI). In SDUI, the server plays a pivotal role in controlling the user interface, allowing dynamic UI generation and adaptation based on real-time data and logic. Unlike traditional CDUI approaches, where layout and logic are primarily managed on the client side, SDUI centralizes UI control on the server, reducing the need for cross-platform duplication and enabling swift, server-driven changes.

What is Server-Driven UI (SDUI)?

if you ask GPT this it what it spits out

Server-Driven UI is a revolutionary paradigm shift in mobile app development. Unlike traditional approaches where the client-side dictates the app’s appearance and behavior, SDUI empowers the server to control these aspects. In simpler terms, the server becomes the mastermind behind the app’s user interface.

Anyone Uses it?

Yes, Server-Driven User Interface (SDUI) is on the rise, and an increasing number of companies are adopting this approach to enhance the flexibility and efficiency of their applications. Here are a few examples of companies that have embraced SDUI:

Reddit:

Reddit Adopts Server-Driven UI for Its New Feed Architecture across Mobile Apps

Tinder:

How Tinder Solves Complex Lottie Localizations with Server Driven UI

Robinhood:

How Server Driven UI is Helping Frontend Engineers Scale Impact

Airbnb:

A deep dive into Airbnb’s server-driven UI system

How do you adopt Server Driven UI? Like Tinder, Reddit, Airbnb?

Lets continue the discuss here in part 2 of the series:

Mastering SDUI: A Deep Dive into Server-Driven UI

Understanding Client Driven UI: Limitations and the Rise of Server Driven UI was originally published in AndroIDIOTS on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you ask GPT this it what it spits out

Server-Driven UI is a revolutionary paradigm shift in mobile app development. Unlike traditional approaches where the client-side dictates the app’s appearance and behavior, SDUI empowers the server to control these aspects. In simpler terms, the server becomes the mastermind behind the app’s user interface.

In the part 1 of this series

Understanding Client Driven UI: Limitations and the Rise of Server Driven UI

we will use Bytes, a short 3 page app, of landing screen, category screen and article screen to explain the concept of SDUI.

What is a Mobile App in SDUI?

In the realm of Server-Driven User Interface (SDUI), a mobile app(or any frontend for that matter) can be viewed as a combination of two core components: User Interface (UI) and Logic, which can be further subdivided as follows:

User Interface (UI):
The visual layer of SDUI is composed of several building blocks:

UI Components: These building blocks include buttons, forms, and interactive elements, all expertly orchestrated by the server for dynamic rendering.

Tokens and Values: Tokens play a vital role, representing essential pieces of information needed for secure communication with the server. They encompass color tokens, typography tokens, spacing tokens, and other data crucial for personalized content retrieval.

Spatial Arrangement: Spatial considerations revolve around the positioning and layout of UI elements on the mobile app’s screen. The server assumes control of this spatial arrangement to ensure an organized and user-friendly interface.

Logic:
The Logic component of the mobile app can be further divided into two primary aspects:

1.UI Logic: client-side ui logic is responsible for managing user interactions such as button clicks or form submissions. For example, when a user taps the “Submit” button on a registration form, the UI logic validates the input data, generates an HTTP request to the server, and displays a success message upon a successful response.

2.Business Logic: Business logic, a fundamental component, can be segmented into two critical facets:

a. Actions: Actions encompass the execution of specific tasks or operations within the app, often instigated by user actions. These actions, in turn, trigger requests to the server, leading to updates or data retrieval. For instance, when a user clicks the “Purchase” button, it triggers an action that communicates with the server to complete the transaction and update the user’s account balance.

b. Rules: Rules consist of predefined conditions and logic set by the server, governing the behavior of the app’s UI. These rules are instrumental in ensuring consistency, safeguarding data integrity, and delivering a seamless user experience. For example, a rule could dictate that a user who is a member of the platform will see different pricing than a non-member.

What is SDUI system ?

A Server-Driven User Interface (SDUI) system is an architectural approach where the responsibility for presentation and user interface rendering is shifted from the client-side (mobile app or web browser) to the server-side. In this system, the server dynamically generates and controls various aspects of the user interface, including spatial layout, rendering, order of elements, logic, and values.

How does a typical SDUI system looks like?

A Server-Driven User Interface (SDUI) system typically comprises several key components that work together to deliver dynamic and server-controlled user interfaces. Here’s an overview of these components:

1.Design System: The design system defines the visual and interactive guidelines for the user interface, including elements like typography, colors, spacing, and UI components. It serves as the foundation for creating consistent and appealing UIs.

2.SDUI JSON (JavaScript Object Notation): SDUI JSON is a structured data format used to describe UI elements, layout, content, and behavior. It allows the server to transmit instructions and data to the client app for rendering the user interface dynamically.

3.Renderer: The renderer is responsible for interpreting and rendering the SDUI JSON received from the server. It translates the instructions in the JSON into actual UI elements and components displayed on the user’s device.

4.Page UI: Page UI represents the user interface as it appears on the user’s screen. It consists of various UI components, such as buttons, forms, text fields, and images, organized according to the layout defined by the SDUI JSON.

5.SDUI Backend Configuration: The SDUI backend configuration includes settings and rules that govern how the SDUI system operates. It specifies how the server should generate UIs, respond to user interactions, and handle data requests.

6.Data Source: The data source provides the necessary data and content for the SDUI system. This may include user-specific information, real-time updates, product listings, or any other data needed to populate the UI components.

7.BFF (Backend for Frontend) Layer: The BFF layer acts as an intermediary between the SDUI backend and the client app. It may perform tasks such as authentication, data aggregation, and request routing to ensure efficient communication between the client and server.

lets elaborate each part

What is Design System?

A design system typically consists of:

1.Typography: Typography is a foundational element that defines fonts, font sizes, line spacing, and text styles used throughout the UI. It ensures readability and maintains a cohesive visual identity.

2.Color Tokens: Color tokens represent a set of predefined colors used consistently in the UI. They include primary and secondary color schemes, background colors, text colors, and other variations. Color tokens allow for easy theming and brand consistency.

3.UI Components: UI components are the fundamental building blocks of the user interface. They encompass buttons, forms, input fields, checkboxes, and other interactive elements, each designed with specific styles and interactions defined by the design system.

4.Spacing and Layout: Guidelines for spacing, margins, padding, and grid layouts help maintain alignment and visual hierarchy in the UI. These rules contribute to a structured and balanced user experience.

What is SDUI JSON?

SDUI JSON (Server-Driven User Interface JSON) is a structured data format used for defining and controlling a user interface. It enables dynamic UI updates through server-client communication. Here are the main aspects:

UI Elements: Describes components like buttons, images, and their properties.
Layout: Specifies the arrangement and positioning of elements.
Data Binding: Connects UI components to real-time data sources.
Interaction: Defines how elements respond to user actions.
Styling: Includes themes, colors, and visual properties.
Navigation: Guides user movement between screens.
Logic and Rules: Implements business logic and behavior.
Responsiveness: Ensures adaptability to different devices.
Localization: Supports multiple languages and regions.

What is Renderer?

A Renderer is a key component responsible for interpreting and transforming SDUI JSON (JavaScript Object Notation) data received from the server into a fully rendered and interactive user interface on the client-side, such as a mobile app or web application.

Here’s how a renderer functions within an SDUI system:

Receiving SDUI JSON: The renderer receives SDUI JSON data from the server. This JSON contains instructions, data, and configurations for rendering the user interface.

Interpreting SDUI JSON: The renderer interprets the SDUI JSON, understanding the structure and content of the UI elements, their layout, behavior, and any associated data bindings.

Generating UI Components: Based on the SDUI JSON instructions, the renderer generates the actual user interface components, including buttons, text fields, images, and more. It applies the defined styling and layout rules to create a visually coherent UI.

Data Binding: The renderer establishes data bindings, connecting UI components to real-time data sources or dynamic content specified in the SDUI JSON. This ensures that the UI displays up-to-date information.

Handling User Interactions: Interactive components within the rendered UI, such as buttons and forms, are equipped with event listeners and logic to respond to user interactions, such as clicks or input submissions.

Displaying the UI: The renderer displays the fully rendered and interactive user interface on the user’s device screen, allowing users to interact with the application as intended.

Dynamic Updates: As the server can send updated SDUI JSON at any time, the renderer is designed to handle dynamic updates, ensuring that the UI reflects changes in real-time data or instructions.

What is Page UI?

Page UI refers to the user interface that is generated and displayed on the client-side based on the instructions and data received from the server. It represents the actual visual layout and components that users interact with when using a mobile app or web application.

Here are key characteristics of Page UI in SDUI:

Dynamic Generation: Page UI is dynamically generated based on the SDUI JSON (JavaScript Object Notation) instructions received from the server. These instructions define the structure, layout, content, and behavior of the user interface.

User-Facing Elements: Page UI includes all the user-facing elements and components of the application, such as buttons, forms, text fields, images, menus, and any other interactive or informational elements.

Layout and Styling: The layout and styling of Page UI are determined by the instructions provided in the SDUI JSON. This includes specifying how elements are positioned, their sizes, margins, padding, colors, fonts, and other visual attributes.

Data Binding: Page UI is often populated with real-time data through data binding. Data bindings connect UI components to data sources, ensuring that the displayed content is up-to-date and reflects changes on the server.

Interactivity: Interactive elements within the Page UI, such as buttons, links, and input fields, are designed to respond to user actions. Event handling and user interaction logic are defined to provide a responsive and intuitive user experience.

Navigation: Page UI may also include navigation elements, such as menus, tabs, or buttons that allow users to move between different screens or sections of the application.

Real-Time Updates: Page UI is capable of receiving real-time updates from the server. This enables dynamic changes to the UI without requiring users to manually refresh the application

What is SDUI Config?

In SDUI , the configuration or SDUI config encompasses various components:

Page Level Unresolved Config: This facet involves page-level settings that may incorporate dynamic or unresolved elements. It allows for conditional behavior, flexible styling, and data binding based on real-time conditions.

Skeleton of Components: SDUI config serves as a foundational blueprint, defining the initial arrangement of UI components on a page. This structural ‘skeleton’ sets the stage for the user interface layout.

Static Component Values: For UI elements with unchanging values, the config provides a straightforward specification. For instance, it can define default button labels, like ‘Submit,’ ensuring consistency.

Static Component Action: Similarly, static actions for UI components are defined. This includes specifying default actions triggered by user interactions, irrespective of dynamic variables.

Contains Reference to Values to be Resolved: The configuration may include references to values awaiting resolution at runtime. These references depend on conditions, user attributes, or dependencies. An example could be determining text color based on a user’s membership status.

Saved Config: SDUI config can be saved and versioned, allowing for change tracking and rollback capabilities. This ensures that historical records of config modifications are maintained.

Example: A config which works for membership

{
  "page": "User Profile Page",
  "layout": {
    "structure": "2-column layout",
    "components": [
      {
        "type": "Image",
        "source": "user-avatar.jpg",
        "position": "left-column"
      },
      {
        "type": "Text",
        "content": "Welcome, [UserName]!",
        "position": "right-column"
      }
    ]
  },
  "dynamicConfig": [
    {
      "element": "Text",
      "property": "content",
      "value": "Hello, [UserName]!",
      "condition": {
        "ifUserIsMember": {
          "value": "Welcome, [UserName]!",
          "elseValue": "Join now and enjoy exclusive benefits!"
        }
      }
    },
    {
      "element": "Image",
      "property": "source",
      "value": "premium-avatar.jpg",
      "condition": {
        "ifUserIsMember": true
      }
    }
  ],
  "generatedBy": "Admin Dashboard",
  "savedConfig": "v1.2",
  "description": "Config for the user profile page"
}

What is DataSource?

A datasource in the context of Server-Driven User Interface (SDUI) is essentially the source of data for your application. It could be a database like MySQL or MongoDB, an API, or any other data store that provides information to populate your app’s user interface.

What is BFF Layer?

BFF (Backend For Frontend): Abbreviated as BFF, which stands for “Backend for Frontend,” the BFF layer serves as an intermediary layer specifically designed to cater to the frontend’s needs in an SDUI architecture.

Hydration from SDUI Page Config: Within the BFF layer, all UI components are “hydrated” or populated with data from the SDUI page configuration. This means that the SDUI page config, which defines the structure and behavior of the user interface, is used to populate UI components with the necessary data.

Dynamic Reference Resolution: The BFF layer is responsible for resolving dynamic references at runtime. This involves retrieving data from database values and referencing SDUI component configurations and logic to ensure that the UI elements are updated with the most current and relevant information.

Extra Business Logic: In addition to data retrieval and reference resolution, the BFF layer can incorporate extra business logic specific to the frontend’s requirements. This logic can include validation checks, order adjustments, experiments, and personalization features that enhance the frontend’s functionality and user experience.

Do we understand SDUI System?

What are the Use Cases of SDUI system?

Internet-Driven Pages: SDUI is well-suited for web applications, websites, and mobile apps that rely on real-time data and content updates from the internet. Examples include news websites, social media platforms, and e-commerce sites where content needs to be frequently refreshed without requiring app updates.

Content-Rich Apps: Applications that serve a wide range of content, such as news articles, images, videos, or product listings, can benefit from SDUI. It enables seamless content updates, personalized recommendations, and dynamic user experiences.

SDUI : Any Other Benefits?

A/B Testing: SDUI enables seamless A/B testing and experimentation. Different UI configurations, content variations, or feature flags can be dynamically applied to specific user segments without the need for app updates. This allows for data-driven decision-making and optimization of user experiences.

Easy Configurations using Remote Configs at BFF Layer: Remote configuration management becomes simplified with SDUI. Changes to UI behavior, styling, or content can be managed centrally at the BFF (Backend For Frontend) layer, allowing for rapid adjustments without deploying new app versions.

Personalization: SDUI empowers applications to deliver personalized content and experiences to users. Data-driven insights can be used to customize UI elements, recommendations, and user journeys based on individual preferences and behavior.

Leveraging BFF Layer and Pre-Processing of Data: The BFF layer in SDUI can preprocess and optimize data before it reaches the client, reducing the workload on the client-side and enhancing overall performance. Data can be transformed, aggregated, or enriched to match the frontend’s specific needs.

New Pages Instantaneously: With SDUI, it’s possible to introduce entirely new pages or views instantly without the need to ship code updates to the app stores. If the same UI components are reused, the configuration can be adjusted to create new pages dynamically.

Consistency Across Platforms: SDUI promotes UI consistency across different platforms, including web, Android, and iOS. By defining UI components and behavior on the server side, the same user experience can be maintained across various devices and operating systems.

Release Management: SDUI simplifies the release management process. Updates, fixes, and enhancements can be implemented on the server side without requiring users to download and install new app versions. This streamlines the release cycle and reduces user friction.

Rollback Faulty Releases: In the event of issues or bugs in a release, SDUI allows for quick rollbacks. The server configuration can be reverted to a previous state, ensuring that users have a stable and reliable experience while issues are addressed.

Are there any challenges with SDUI?

while Server-Driven User Interface (SDUI) offers various advantages, it also presents certain challenges and considerations that developers and organizations should be aware of:

Complexity at Backend: Implementing SDUI can introduce complexity at the backend, particularly when managing dynamic UI configurations, data processing, and handling various client requests. It requires robust server infrastructure and logic.

Backward Compatibility: Maintaining backward compatibility with older versions of the client app can be challenging when making changes to SDUI configurations. Ensuring a smooth transition for existing users is essential.

Versioning to Prevent Errors: Effective version control and management are crucial to prevent errors and inconsistencies in SDUI configurations. Different levels of versioning may be needed, including component level, BFF level, SDUI config level, and app version level.

Accessibility: Ensuring accessibility for users with disabilities is essential, especially for large-scale consumer apps. SDUI implementations need to adhere to accessibility standards to provide an inclusive user experience.

Load Time: SDUI configurations, particularly when complex, can impact app load times. Optimizing the delivery and processing of SDUI data is necessary to maintain a responsive user experience.

Modularization: Breaking down the UI into modular components can be challenging but is essential for SDUI flexibility. Proper modularization allows for reusability and scalability.

Development and Maintenance: Developing and maintaining SDUI configurations, especially in large and evolving applications, can require ongoing effort and resources. It’s essential to have processes in place for efficient development and updates.

Anyone Uses it?

Yes, Server-Driven User Interface (SDUI) is on the rise, and an increasing number of companies are adopting this approach to enhance the flexibility and efficiency of their applications. Here are a few examples of companies that have embraced SDUI:

Reddit:

Reddit Adopts Server-Driven UI for Its New Feed Architecture across Mobile Apps

Tinder:

How Tinder Solves Complex Lottie Localizations with Server Driven UI

Robinhood:

How Server Driven UI is Helping Frontend Engineers Scale Impact

Airbnb:

A deep dive into Airbnb’s server-driven UI system

Can i ever use SDUI?

What do Tinder, Reddit, Robinhood, and Airbnb have in common?

They shared a combination of resources: Time, Money, and Expertise.

So question how can anyone use SDUI it they dont have all 3??

That is why we built Digia

We recognized that not everyone has the resources or expertise to implement a Server-Driven User Interface (SDUI) system. That’s why we developed Digia, a mobile app development platform. With Digia, anyone can harness the capabilities of an SDUI system, making dynamic and responsive mobile app development accessible to a wider audience

Check it out at here

Home | Digia

Mastering SDUI: A Deep Dive into Server-Driven UI was originally published in AndroIDIOTS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Problems with the current setup

Right now there is no dev-tools panel available in Android Apps. To debug android apps, most people either connect to Android Studio or Charles Proxy. But both of these comes with their own challenges.

• Android Studio — Non-Devs (QA/PM..) can initially find this a little daunting. Plus Android Studio needs over 3000GBs of RAM 💻🔥.
• Charles Proxy: No doubt a really helpful tool. But we are in 2022 now & No one has time to install a certificate or set up a WIFI proxy to debug apps. Also, the UI/UX of Charles is 👴🏽.

Introducing Requestly Android Debugger

Requestly Android Debugger adds the missing dev tools panel to your Android Debug Builds. It lets you have the power of Charles and Chucker in a single app and makes it super easy to debug APIs, Analytics Events & report issues directly from your device.

It requires only a one-time integration and then it can be used company-wide (Yes, without installing certificates or setting wifi proxy)

Also, it is completely free and open-source https://github.com/requestly/requestly-android-sdk

Features

Here are some of the features that Requestly Android Debugger support:

Network Traffic Debugger

View & debug your HTTP traffic directly from your device. You can see which requests are failing and send the faulty requests directly to the developer.

Analytics Events Debugger

Debug & validate your analytics events after every fix/release. PMs/QA can now verify what events are firing directly from your app.

Host Switcher 🔀

Switch your API’s hosts between PROD ↔ STAGE ↔ DEV in a single click. No need to hardcode the URLs in your codebase.

Logs Viewer 🪵

See your logcat logs directly from your app. No need to connect your device to your computer to know what’s happening inside your app. Check what crashed the app without opening Android Studio.

Shared Preferences Editor (Coming Soon)

See and modify the Shared Preference of the App directly from the device.

Demo

Check out some of the demo apps here.

↓ Click on Screenshot to try the App ↓

OR

• Dowload CryptoDemo Apk
• Download Infinity Reddit Apk
• Download Pokedex Apk

Check out more here: https://github.com/requestly/requestly-android-sdk

We are constantly working on improving this daily. If you liked what we are making, then please leave us a star ⭐️ on our GitHub repo.

Originally published at https://requestly.io.

The missing dev tools in Android Apps was originally published in AndroIDIOTS on Medium, where people are continuing the conversation by highlighting and responding to this story.

2020 was a tough year for everyone, google I/O 2020 was canceled, iOS supports widgets now (cough cough…)

In wake of covid -19 with the entire world working remotely albeit juggling between work and home we hoped android might also take a break, but no the juggernaut that is Android kept rolling in 2020 as usual.

We don’t want you to get overwhelmed by the amount of stuff Google, Jet-brains shipped together in thousand of articles online, here is a rewind of android as it happened in 2020 (well, the good part only).

Android 11:

New year, New android.

Android 11 in google’s words is

People-centric and expressive, with a new controls space and more privacy features. Extend your apps with conversation notifications and bubbles, try one-time permissions, surface devices and media in the controls. Work faster with tools like compatibility toggles, ADB incremental installs, and more!

With Android 11, Google has taken a step jump in enhancing the privacy of users. As a developer, you need to keep the following points in mind while building apps

• One Time Permissions: Starting in Android 11, whenever your app requests permission related to location, microphone, or camera, the user-facing permissions dialog contains an option called Only this time. If the user selects this option in the dialog, your app is granted a temporary one-time permission, and if the user denies the permission multiple times it will be considered a ‘Don’t Ask Again’ and the system will not show the permission dialog anymore, the user would have to grant permission from the settings.
• Permission Auto-Reset : If the user hasn’t interacted with apps for months system will remove sensitive permission access for these apps, to read best practices for request permission read here
• Scoped Storage: To give users more control over their files and to limit file clutter android introduced scoped storage in android 10 with android 11 its compulsory for all apps to use it.
• Background Location Access: Now developers have to request background and foreground requests incrementally in separate calls.

To enhance security Android 11 now uses SSL engine of Conscript, and it used Scudo Hardened Allocator internally to service heap allocations. which is capable of detecting and mitigating memory safety violations and now users' app usage stats are stored in credential encrypted storage.

It also comes with a host of new features like chat bubble, support for waterfall screen, Media control settings, and much more find the details here.

And in case confused about how to digest changes in Android 11 Here is a guide by @iamgoddamnbatma on steps to Migrate to Android 11 easily.

Android Jetpack And More :

• Jetpack Compose: An Android UI toolkit, taking inspiration declarative programming paradigm from the web, android now supports a new way of writing android UI say bye-bye to messy XML files and bloated adapters.
  Read Here to understand the power of composition Compose uses.

• Dagger Hilt: Finally google has an opinionated way of using dependency injection in android with dagger hilt, hilt simplifies the overall infra for using dagger with standard components and scopes it eases the pain of setup, readability, and testing. Read here to deep dive into Hilt.

• Data Store: Now you can store key-value pairs and typed objects locally in disk memory, data store is a replacement of Shared Preference Api it also leverages Kotlin Coroutines to store data asynchronously and consistently, so no more headache to synchronize apply and commit.
• View Pager 2: Built on top of recycler view, the new view pager API has a stable version now, here is a guide to help you migrate from the old view pager.
• Async Tasks Deprecated in Android 11: Finally some good news to all people who grew up loving to hate this API, some versions had Some versions have parallel execution and some have sequential execution with the special attention needed to not to leak memory limitation of execute() will be only be called from the main thread, the async task had it coming, so now what? well we have kotlin coroutines for the rescue
• Constraint Layout 2.0: With Flow, a new virtual layout for building chains, Layer, a helper to create virtual layers from several views, and first-class support of motion layout along with motion editor, constraint layout is now even more powerful.
• State Flow And Shared Flow: Data transfer is the bedrock of software development, and to enhance the existing infra of data communication android now has new APIs in Kotlin Flows. State flow updates the current and new state of data to its collector, and it stays in memory as long as the flow is collected by any collector, Shared flow is a configuration on top of state flow and it emits values to all the collectors that collect from it.
• Paging 3: With first-class support for Kotlin Coroutines and Flow, built-in error and load state for Responsive UI, and improved repository and presentation layer, paging 3 is now even more powerful than ever, are you already using paging 2 and above features are enticing enough to update have a read here, though paging 3 is currently in alpha so no rush as such.
• Jetpack App Startup: Every enterprise app has a lot of 3rd party dependencies eg Work Manager, FirebaseApp and these components need to be initialized before Application.onCreate() and content providers to initialize each dependency separately is the way to go about it till now, and obviously, it comes with the cost of time consumed to initialize every dependency independently, App Startup lets you define initializers that share a single content provider. This significantly improves app startup time, usually by ~2ms per content provider.
• Activity Result Api: Since the Inception of android we have been communicating between two activities bypassing Intent and requestCode through startActivityForResult , we check the request and result code before paring response on onActivityResult , but when the app grows there is a lot of tight coupling in a lot of if cases and becomes very difficult to test, the new Activity Result API which is part of the AndroidX library suite comes with a good abstraction that allows us yo handle onActivityResult() the method in a clean and reusable structure, you can register a callback for an Activity Result, The Activity Result APIs provide components for registering for a result, launching the result, and handling the result once it is dispatched by the system.

Kotlin:

Jetbrains has been very active even during these tough times and shipped new features for Kotlin all year round.

In March, Kotlin 1.3.70 came out with these new changes:

• @OptIn and @RequiresOptIn have replaced @UseExperimental and @Experimental
• Double-ended queue implementation: ArrayDeque
• Collection builders: buildList, buildSet, and buildMap which work similar to buildString
• Scanning Lists and Sequences: scan() is closely related to fold(). Both scan() and fold() apply the given binary operation to the sequence of values, but differ in that scan() returns the whole sequence of intermediate results, while fold() returns only the final result.

Kotlin 1.4.0 was released in August with a focus on Quality and Performance, with these new updates:

• New functions for arrays and collections
• StringBuilder has useful new extension functions: set(), setRange(), deleteAt(), deleteRange(), appendRange(), and others.
• New functions for bit manipulations: countOneBits() ,countLeadingZeroBits() ,countTrailingZeroBits() , takeHighestOneBit() , takeLowestOneBit() , rotateLeft() and rotateRight()
• Using break and continue inside when in loops
• Mix named and positional arguments when calling a function
• Support for Trailing commas
• More support for callable references.

In the most recent release, Kotlin 1.4.21, the major update was the deprecation of kotlin-android-extensions. We’ve all used this library for synthetic views from, and @Parcelize annotation has become our go-to, to avoid writing lots of boilerplate when implementing parcelable’s. Synthetic views are no longer needed since the Android team introduced view-binding (migration guide), so Jetbrains decided to deprecate it, and move @Parcelize to its own kotlin-parcelize package.

Android Studio

Studio 3.6

• Split view in design editors to see Code + Design
• Color Picker Resource Tab to easily pick colors in scope.
• Updates to the Android Gradle plugin: View Binding
• Apply changes: You can now add a class and then deploy that code change to your running app by clicking either Apply Code Changes or Apply Changes and Restart Activity.
• Deobfuscate class and method bytecode in APK Analyzer
• Leak Detection in Memory Profiler: When you capture/import a heap dump, the profiler can now flag instances in the heap which might be memory leaks.
• Emulators: Improved location support, Multi-display support
• Resumable SDK downloads
• Gradle offline toggle on Gradle tool window
• Win32 is deprecated

Studio 4.0

• Build Analyser: Understand and diagnose issues with your build processes, such as disabled optimizations and improperly configured tasks. The window organizes the possible build issues in a tree on the left and a more detailed description on the right.

• Java 8 library desugaring in D8 and R8: Android Studio now includes support for using a number of Java 8 language APIs without requiring a minimum API level for your app.
• Feature-on-feature dependencies: Feature modules can now depend on other feature modules. This means that when your app requests to download a feature module, the app also downloads other feature modules it depends on. You can enable this in-studio from Help > Edit Custom VM Options.
• Dependencies metadata: When compiling your app with Android Gradle Plugin 4+, a summary of dependencies is stored in build/outputs/sdk-dependencies/release/sdkDependency.txt which PlayStore uses to give alerts and actionable feedbacks on known issues of the SDKs you use.
• Support for Kotlin DSL script files: The Android Gradle plugin now supports Kotlin DSL build script files (*.kts).
• CPU Profiler Updates: Error rates are decreased and UI is much more intuitive. CPU recordings are separated from the main timeline for easier analysis and has many more options such as viewing thread activities, flame chart, top-down and bottom-up, etc.
• New Motion Editor: You can now preview your MotionLayout animations in the design editor. You can move your objects, define states, play the animation in the editor and it’ll automatically generate the corresponding XML code for you!

• Live Layout Inspector: Debug your layout with an updated Live Layout Inspector that provides complete, real-time insights into your app’s UI while it’s deployed to a device. You can see the dynamic layout hierarchy, resolved properties, a 3D view which is especially helpful with view pagers.
• Smart editor features for code shrinker rules: With R8 getting stable, the studio got smarter with features like syntax highlighting, code completion, and error checking for rules.

Studio 4.1

• New Database Inspector: It’s finally here! The long-awaited database inspector lets you inspect, query, and modify your databases in your running app using the new Database Inspector.
• Run the Android Emulator directly in Android Studio: A lot of devs disliked how they had to switch between emulator and studio all the time, breaking their workflow.
• Use TensorFlow Lite models: ML Model binding for .tflite models help in generating easy-to-use classes for you to interact with.
• Native Memory Profiler: If the studio is connected with a device running Android 10 and above, the studio allows you to record memory allocations and deallocations from native code and inspect cumulative statistics about native objects
• Dagger navigation support: Now you can navigate between your Dagger-related code by providing new gutter actions and extending support in the Find Usages window
• Material Design Components: Updated themes and styles in new project templates depending on material design and conforming to its guidelines.

Honorable Mention: Firebase

Firebase has shipped some major releases this year, with the most notables ones being :

• Bye Bye Fabric: Fabric SDK has been officially deprecated since 18th November and crashes will now be reported with firebase’s crashlytics sdk.
• Firebase Android BoM: The Firebase Android BoM (Bill of Materials) enables you to manage all your Firebase library versions by specifying only one version — the BoM’s version. Super useful as it ensures that all your firebase sdk dependencies are inter-compatible.

We believe this rewind was useful we are also inviting Android Developers across the globe to contribute back to the community via AndroIDIOTS. If you are interested in recording a podcast or writing tech articles, we would love to have you on board. Here is a small form you can fill so we can get back to you.

Happy New Year 2021, Cheers !!

Android Rewind : 2020 was originally published in AndroIDIOTS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Code Quality has always been a central theme in the life of a software developer.
Lints are one of the easiest ways to maintain some sanity over the codebase. Out of the box linters that Android Studio provides gives us the power to analyse the source code to flag programming errors, bugs, stylistic errors.

And in this episode, we have Hitanshu Dhawan from Urbanclap who helps us, deep-dive, into the same.

Lints :

Lint, or a linter, is a tool that analyses source code to flag programming errors, bugs, stylistic errors, and suspicious constructs.

Eg :

Custom Lints :

In any organisation, there are internal code standards and Base classes like CustomViews which ought to be used instead of View classes provided by Android. Creating Custom Lints can ensure that all the other devs also follow the same standard and are warned if they miss something.

Use case: In our app as per the design guidelines all the radio button will have a default margin of 8 dp at the start which needs to be consistent throughout the app, and when a new guy tries to use the android version we want to show an error warning him/her about the custom option which is available

Custom Radio Button Class:

class IdiotRadioButton : AppCompatRadioButton {
    private var buttonPadding = 0

    constructor(context: Context?) : super(context) {
        init()
    }

    constructor(context: Context?, attrs: AttributeSet?) : super(
        context,
        attrs
    ) {
        init()
    }

    constructor(
        context: Context?,
        attrs: AttributeSet?,
        defStyleAttr: Int
    ) : super(context, attrs, defStyleAttr) {
        init()
    }

    private fun init() {
        buttonPadding = resources
            .getDimensionPixelOffset(R.dimen.list_item_button_right_margin)
 // default margin 
    }

    override fun getCompoundPaddingLeft(): Int {
        return buttonPadding + super.getCompoundPaddingLeft()
    }
}

Step 1: Create a Java/Kotlin Library

In an existing android studio project create a new java/kotlin module lets name it “AndroidiotLint”

Step 2: Add dependencies

Module build.gradle

//AndroidiotLint/build.gradle

apply plugin: 'java-library'

ext {
    lintVersion = "26.5.3"
}
dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])

    // Lint
    compileOnly "com.android.tools.lint:lint-api:$lintVersion"
    compileOnly "com.android.tools.lint:lint-checks:$lintVersion"
    // Lint Testing
    testImplementation "com.android.tools.lint:lint:$lintVersion"
    testImplementation "com.android.tools.lint:lint-tests:$lintVersion"
    testImplementation "junit:junit:4.12"

}

app/ build.gradle

apply plugin: 'com.android.application'

dependencies {
   //existing dependencies
     lintChecks project(path: ':AndroidiotLint')
}

Important: The lint version should correspond to the Android Gradle Plugin version + 23.If the AGP is 3.5.3, then the lint version should be 26.5.3

Step 3: Create Issue Registry

IssueRegistry class contains the central list of issues that the Linter references while checking the codebase

class IssueRegistry : IssueRegistry() {

    override val issues: List<Issue>
        get() = listOf(
            IdiotCodeIssueDetector.ISSUE,  
            IdiotXmlIssueDetector.ISSUE
        )
}

Step 4: Declare Issue Registry

Above step would be enough if we wanted the linter to only work with gradle. But the real power of custom Lints is how they work out of the box with Android Studio. This can be done by declaring Issue registry file path in

ModuleNam/src/main/resources/META-INF/services/com.android.tools.lint.client.api.IssueRegistry

I.e Inside the Lint module only.

Step 5: Create a Custom Detector Class

A detector is able to find a particular problem. Each problem type is uniquely identified as an Issue.

class IdiotCodeIssueDetector : Detector() {
}

Step 6: Create an Issue

An issue is a potential bug in an Android application. An issue is discovered by a Detector, and has an associated Severity.

class IdiotCodeIssueDetector : Detector() {


  companion object {

      val ISSUE = Issue.create(
          id = "IdiotRadioButtonUsageWarning",
          briefDescription = "Android's RadioButton should not be used",
          explanation = "Don't use Android Radio button, be an idiot and use IdiotRadioButton instead",
          category = Category.CORRECTNESS,
          priority = 3,
          severity = Severity.WARNING,
          implementation = Implementation(
              IdiotCodeIssueDetector::class.java,
              Scope.RESOURCE_FILE_SCOPE
          )
      )
  }

}

Issue Attributes :

id = It’s a unique identifier for the issue and the one we mention in @SupressWarning(“”).

briefDescription = lines to explain the issue and will be shown for the lint, typically describing the problem rather than the fix.

category = A category is a container for related issues. It can be any one of the following type.

/** Issues related to running lint itself  */
@JvmField
val LINT = create("Lint", 110)

/** Issues related to correctness  */
@JvmField
val CORRECTNESS = create("Correctness", 100)

/** Issues related to security  */
@JvmField
val SECURITY = create("Security", 90)

/** Issues related to legal/compliance  */
@JvmField
val COMPLIANCE = create("Compliance", 85)

/** Issues related to performance  */
@JvmField
val PERFORMANCE = create("Performance", 80)

/** Issues related to usability  */
@JvmField
val USABILITY = create("Usability", 70)

priority: It is defined on a scale of 1–10 which we can use to determine which issues to fix first.

severity: Determines if a lint would be treated as a warning or an error while building the app. An error will cause the build to break while a warning would be just printed to console or a file.

/**
 * Fatal: Use sparingly because a warning marked as fatal will be
 * considered critical and will abort Export APK etc in ADT
 */
FATAL("Fatal"),

/**
 * Errors: The issue is known to be a real error that must be addressed.
 */
ERROR("Error"),

/**
 * Warning: Probably a problem.
 */
WARNING("Warning"),

/**
 * Information only: Might not be a problem, but the check has found
 * something interesting to say about the code.
 */
INFORMATIONAL("Information"),

/**
 * Ignore: The user doesn't want to see this issue
 */
IGNORE("Ignore");

implementation: Scope of the issue that it is interested in like manifest, resource files, java/Kotlin source files

Note : Issues and detectors are separate classes because a detector can discover
multiple different issues as it’s analysing code, and we want to be able to
different severities for different issues, the ability to suppress one but
not other issues from the same detector, and so on.

Step 7: Add the Scanner to the Detector

FileScanner : Allows to perform analysis on a file, based on subtype of scanner implemented in the detector.

As we want to scan the XML files to find the usage of RadioButton we will use XmlScanner, define the text reference we are looking for in an XML and the error message, and re-sync the Gradle afterward.

class IdiotCodeIssueDetector : Detector(), XmlScanner {


    override fun getApplicableElements(): Collection<String> {
        return listOf("RadioButton") // will look for Radio Button //Text in all xml
    }

override fun visitElement(context: XmlContext, element: Element) {
    context.report(
        issue = ISSUE,
        location = context.getNameLocation(element),
        message = "Usage of RadioButton is prohibited" // Error message
    )
}

Now if we open up the XML file we can see the error message

Step 8: Add Lint (Quick) Fix

As only showing error is not enough, we would ideally like to replace the Radio button with our IdiotRadioButton.

In comes LintFixes using which we provide structured data to be used by the IDE to create an actual fix.

class IdiotCodeIssueDetector : Detector(), XmlScanner {


    override fun getApplicableElements(): Collection<String> {
        return listOf("RadioButton")
    }

    override fun visitElement(context: XmlContext, element: Element) {

        val idiotRadioButtonFix = LintFix.create()
            .name("Use IdiotRadioButton")
            .replace()
            .text("RadioButton")
            .with("com.androidiots.playground.IdiotRadioButton")
            .robot(true)
            .independent(true)
            .build()

        context.report(
            issue = ISSUE,
            location = context.getNameLocation(element),
            message = "Usage of Radio Button is prohibited",
            quickfixData = idiotRadioButtonFix
        )
    }

Testing Lints :

Unfortunately, we cannot debug our lints just like we debug apps. That’s because lints don’t run on mobile device. What we can do is writing test cases for the lint and run those tests in debug mode

class IdiotCodeIssueDetectorTest {
    

    @Test
    fun testRadioButton() {

            lint()?.files(
                xml(
                    "res/layout/layout.xml",
                    """
                <merge>
                <RadioButton
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            app:layout_constraintBottom_toBottomOf="parent"
            app:layout_constraintEnd_toEndOf="parent"
            app:layout_constraintStart_toStartOf="parent"
            app:layout_constraintTop_toTopOf="parent"
            />
</merge>
            """
                ).indented()
            )
                ?.issues(IdiotCodeIssueDetector.ISSUE)
                ?.run()
                ?.expectWarningCount(1)
                ?.verifyFixes()
                ?.checkFix(
                    null,
                    xml(
                        "res/layout/layout.xml",
                        """
                <merge>
                     <com.androidiots.playground.IdiotRadioButton
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            app:layout_constraintBottom_toBottomOf="parent"
            app:layout_constraintEnd_toEndOf="parent"
            app:layout_constraintStart_toStartOf="parent"
            app:layout_constraintTop_toTopOf="parent" />
                </merge>
            """
               ).indented()
                )
    }
}

This test checks that the actual number of errors in this lint check matches exactly the given count.

Lint Internals :

Java and kotlin files are converted to UAST and we write our lint rules for this UAST.

UAST stands for Universal abstract syntax tree, where it’s a tree representation of the source code. Read more about UAST here.

And along with gradlew and XML file, this UAST is consumed by the Lint Analysis process to point out lint errors.

References:

• Androidiots/playground
• Improve your code with lint checks | Android Studio | Android Developers

• Link: Implementing your first Android lint rule
• Link: Writing a Custom Android UI Inheritance Lint Rule
• Link: Get started with Android Lint — Custom Lint Rules
• Link: Android Lint Deep dive — Advanced custom Lint rules
• Link: Building Custom Lint Checks in Android

We are inviting Android Developers to contribute back to the community via AndroIDIOTS. If you are interested in recording a podcast or writing tech articles, we would love to have you on board. Here is a small form you can fill so we can get back to you.

Follow us on Twitter for regular updates and feel free to DM the hosts (Anupam & Vivek) for any queries.

If you have any questions/suggestions/queries about the topic feel free to contact the speaker Hitanshu Dhawan for more info.

Cheers!!

AndroIdiots Podcast E18: Custom Lints was originally published in AndroIDIOTS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Android Studio was announced on May 16, 2013, at the Google I/O conference as an IDE for android development and we finally said Bye Bye to our beloved Eclipse Android Development Tools (ADT).

It quickly became the de facto tool for all future android development. It’s built on Jetbrains’ IntelliJ platform which comes with a host of features like File templates, Code navigation, and the one that we are going to discuss in this episode with Tusharaeron from Urbanclap, Plugins.

Show Notes
Plugin :

A software component that adds a specific feature to an existing computer program.

In Android Studio some of the commonly used plugins are ADB wifi, RoboPojoGenerator and KeyPromotorX

Why write your own?

We observe that in day to day development, there are a few tasks that are executed repeatedly and slowly eat up dev-productivity. To avoid these we can create custom plugins specific to our project or our organization. For example, we use Jenkins as our CI tool. To trigger a build on Jenkins you have to open a browser, log in, find your job, and then run it. What we did was create an Android Studio custom plugin which lets us do the same in 2 clicks without having to leave the IDE.

How to write your own?
Let's walk you through a step by step guide which takes you from knowing nothing about Android Studio plugins to publishing one of your own.

Prerequisites :

1. Android Studio latest edition
2. Intellij Community Edition

We need a platform to work on Android Studio was built on IntelliJ hence we create plugins for IntelliJ only

Note: IntelliJ CE should be compatible with the Android Studio build number.

Step 1: Create A Gradle project in Intellij

Understanding Project Architecture :

1. Plugin.xml
   This file is similar to AndroidManifest.xml used in Android development. It contains metadata about the plugin and here we can register different elements of our plugin like actions, components etc.

<idea-plugin>
    <id>myPlugin.myPlugin</id>
    <name>Hello Idiots action Project</name>
    <version>0.0.2</version>
    <vendor email="andro021idiots@gmail.com" url="androidiots.in">Androidiots</vendor>

    <extensions defaultExtensionNs="com.intellij">
        <!-- Add your extensions here -->
    </extensions>

    <actions>
        <!-- Add your actions here -->
    </actions>

<applicationcomponents>
        <!-- Add your components here -->
    </applicationcomponents>
</idea-plugin>

2. build.gradle
We can mention our repositories, dependencies inside this file. It is essential to mention the local android studio path as alternativeIdePath to run our plugin in Android Studio.

buildscript {
    ext.kotlin_version = '1.2.31'

    repositories {
        mavenCentral()
    }
    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

plugins {
    id 'java'
    id 'org.jetbrains.intellij' version '0.4.10'
}

version '1.0-SNAPSHOT'

apply plugin: 'kotlin'

sourceCompatibility = 1.8

repositories {
    mavenCentral()
}

dependencies {
    compile "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version"
    testCompile group: 'junit', name: 'junit', version: '4.12'
}

compileKotlin {
    kotlinOptions.jvmTarget = "1.8"
}
compileTestKotlin {
    kotlinOptions.jvmTarget = "1.8"
}
intellij {
    version '2019.1.4'
    alternativeIdePath '/Applications/Android Studio.app' // add your local android studio path here 
}
patchPluginXml {
    sinceBuild = '191.8026'
    untilBuild = '191.*'
}

Step 2: Define Actions and Components

Actions: Remember the toolbar at the top of your project, where you see the options like File, Edit, Tool, Build and Run, etc. When you click on one of these options every line item inside the drop-down is called an Action.
Actions are organized into groups, these groups can contain other groups and so on and so forth. We can create our own action by extending AnAction() class.

class IdiotAction: AnAction() {

    override fun actionPerformed(e: AnActionEvent) {
        val noti = NotificationGroup("myFirstPlugin", NotificationDisplayType.BALLOON, true)
        noti.createNotification("My Title",
                "My Message",
                NotificationType.INFORMATION,
                null
        ).notify(e.project)
    }

Components: Components control the life-cycle and manage the state of a plugin.

There are 3 variants of Component :

1. Application-level component: it is initialized when the IDE (Android Studio) starts up. Remember the Send Statistics to google dialog on the bottom right corner that pops up every single time, that’s an application-level component.

class ApplicationComponentExample : ApplicationComponent {     
    val LOG: Logger = Logger.getInstance(ApplicationComponentExample::class.java)
    override fun initComponent() {        
        LOG.info("Initializing plugin. Project is not opened yet");        
    }     
    override fun disposeComponent() {
        LOG.info("Disposing plugin. Intellij is closing");    
    }     
    override fun getComponentName(): String {        
        return "components.ApplicationComponentExample"    
    }
}

2. Project-Level Components: it is created for each project instance in the IDE.

class ProjectComponentExample : ProjectComponent {     
    val LOG: Logger = Logger.getInstance(ProjectComponentExample::class.java)
    private var project: Project? = null
    private var applicationComponent: ApplicationComponentExample? = null

    constructor (project: Project, applicationComponentExample: ApplicationComponentExample){
        this.project = project
        this.applicationComponent = applicationComponentExample
    }
    override fun initComponent() {
        //called before projectOpened()
    }
    override fun disposeComponent() {
        //called after projectClosed()
    }
    override fun projectOpened() {
        LOG.info(String.format("Project '%s' has been opened, base dir '%s'", project?.getName(),     project?.getBaseDir()?.getCanonicalPath()))
    }
    override fun projectClosed() {
        LOG.info(String.format("Project '%s' has been closed.",   project?.getName()))
    }    
    override fun getComponentName(): String {        
        return "components.ApplicationComponentExample"    
    }
}

3. Module-level components: it is created for each module inside every project loaded in the IDE.

class ModuleLevelComponent : ModuleComponent {     
    val LOG: Logger = Logger.getInstance(ModuleLevelComponent::class.java)
    private var module: Module? = null

    constructor (module: Module){
        this.module = module
    }
    override fun projectOpened() {
        LOG.info(String.format("Module '%s' has been opened'", module?.getName()))
    }
    override fun projectClosed() {
        LOG.info(String.format("Module '%s' has been closed'", module?.getName()))
    }    
    override fun moduleAdded(){        
        LOG.info(String.format("Module '%s' has been added'", module?.getName()))    
    }
}

JetBrains has introduced 3 new components namely Service, Extensions, and Listeners which make writing plugins even simpler and even save development time using Dynamic plugins.

Services: It is a plugin component loaded on demand when your plugin calls the getService() method of the ServiceManager class and the IntelliJ Platform ensures that only one instance of a service is loaded even though the service is called several times.
Service is also available at the application level, project level, and module level.

For example, say we are migrating our code from java to kotlin and need to find all the java files when the project loads. We can then use the project level service. When a project loads, we can call the getService() method of ServiceManager, get the instance of the service and calculate the file count.

Extensions: Extensions are the most common way for a plugin to extend the functionality of the IntelliJ Platform. It is not as straightforward as adding an action to a menu or toolbar.
Extensions(read Extension Points) allow us to add tool windows, the panels displayed at the sides of the IDE user interface, or to add pages to the Settings/Preferences dialog.

Listeners: Listeners allow plugins to declaratively subscribe to events delivered through the message bus. You can define both application- and project-level listeners.

Let’s take an example of a project level listener. The class implementing the listener interface can define a one-argument constructor accepting a Project, and it will receive the instance of the project for which the listener is created.

Refer below git projects, for the understanding of Actions, Components, Service, Extensions, and Listeners.
1. IntelliJ-Plugin Examples
2. Android Studio Jenkins Project

tusharaeron/jenkins-android-studio-plugin

Step 3: Open the plugin.xml

<idea-plugin>
    <id>myPlugin.myPlugin</id>
    <name>Hello Idiots action Project</name>
    <version>0.0.2</version>
    <vendor email="andro021idiots@gmail.com" url="androidiots.in">Androidiots</vendor>

    <depends>com.intellij.modules.lang</depends>
    <application-components> // Add application component here
        <component>
            <implementation-  class>components.ApplicationComponentExample</implementation-class>
        </component>
    </application-components>
    <actions> // Add your actions and group of actions here
        <group          // For grouping similar actions
               id="IdiotPluginGroup"  
               text="Androidiots"
               description="Idiot Menu">
             <add-to-group  // Add reference for where to place the group
               group-id="MainMenu" anchor="last"/>
             <action id="IdiotAction" // Add indivisual action
                    class="action.IdiotAction"
                    text="Idiot Action"
                    description="Hello Idiots">
                <keyboard-shortcut first-keystroke="control alt k" keymap="$default"/> // Set shortcut for action
            </action>
            </group>
    </actions>
</idea-plugin>

Declare your elements (i.e. actions, components, services, etc.) in plugin.xml to be picked when the studio is launched. Refer comments in the code above for understanding the usage of individual elements.

Step 4: Run the project

Either by Run button in IntelliJ or in the Gradle Tool Window, you can find the runIde task. Double click and run this.

Step 5: Wait for Android Studio to open

When we hit run in our IntelliJ, it will build the plugin, launch Android Studio, (since we have mentioned alternativeIdePath in plugin.xml), and install the plugin. We can now see our Action placed at the last position on our Main Menu along with the keyboard shortcut which we have set.

Debugging

Debugging plugins works exactly the same way as in android app development. Either you launch Android Studio while debugging or you attach the debugger once it’s already launched.

Testing

IntelliJ provides capabilities to do functional or integration testing of high-level functionality.
For example: We can use AssertJ and JUnit4 to create unit tests for our plugins. Please read the official docs on testing.

We need to add the respective dependency in build.gradle file.

dependencies {
  testImplementation("org.assertj:assertj-core:3.11.1")
}

Publish

To locally share it with friends or colleagues, you can build a “zip file” of your Gradle plugin. They can install it via Android Studio’s plugin manager and start using it after restarting the IDE.
To publish your plugin visit the JetBrains website, signup, and upload your plugin. Jetbrains takes some time to review the plugin after which it will be available on the Plugins Marketplace.

References

• Creating Your First Plugin
• tusharaeron/jenkins-android-studio-plugin
• How I automated creating files for a new screen with my own Android Studio Plugin

You can check the codes of plugins you use in your day to day life in the Readme section.

We are inviting Android Developers to contribute back to the community via AndroIDIOTS. If you are interested in recording a podcast or writing tech articles, we would love to have you on board. Here is a small form you can fill so we can get back to you.

Follow us on Twitter for regular updates and feel free to DM the hosts (Anupam & Vivek) for any queries.

If you have any questions/suggestions/queries about the topic feel free to contact the speaker Tusharaeron for more info.

Cheers!!

Androidiots Podcast 17: Android Studio Plugins with Tushar Aeron was originally published in AndroIDIOTS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Android Platform has come a long way since its launch, from Cupcake to Pie. We had lots of deserts, product features like Notification Centre, Material Design, Dark-theme, capabilities like Google Assistant, Video Casting, Wireless charging etc.

But like any good software system the core always remains intact, so today we try to answer how the System designers went about designing android system, what are the design considerations that they kept in mind?

How system treats & interacts with the apps that we developers make? We deep dive into entire android process lifecycle with Deepak Garg and try to understand the same.

Show Notes :

Design Considerations while designing Android :

1. In Background app in Mobile Vs Closed App on Desktop systems.
2. No Swap Space in Android
3. Frequent Application Switching
4. “All Applications are created equal” philosophy.

The Android operating system is a multi-user Linux system in which each application is a different user. Android assigns a unique user ID (UID) to each Android application and runs it in its own process.

A process is created for an application specifically when some part of its code is run and the process keeps running until it’s no longer needed and system claims its memory to be used by for other applications.

Each Process has its own VM hence every app runs in isolation with other apps, this design also helps in securing apps to be infected by malicious apps.

ART starts the first VM which in turns calls the main method of original zygote process which then preloads all shared classes and resources to the memory.

Zygote: Every process in android is forked from Original Zygote Process. Original Zygote provides a template for all new mini zygote process and a VM is also assigned to every mini zygote process and the application is bound to the thread of this process.

Software Component Containers: Once loaded, they hold the activity, services, content providers component of the application, and the map of these preloaded classes is shared when an application is launched, dramatically reducing load time of application.

Activity Thread : The entry point for an activity, it manages the execution of main thread in an application process, handles broadcasts. and whatever is triggered from main method is called MAIN UI thread

When any application is launched the Zygote is bootstrapped, classes are loaded into the JVM, and the JVM to locates the java public static void "main" method and invoke it in Activity Thread.

And once main method is invoked it does 3 main things

1. Prepares the main Looper : Looper.prepareMainLooper method is called and this marks the current random thread as the applications main thread

2. Sets up a Handler : There is a private inner class called H that extends the Handler class.Which is initialised to sever as the main handler, H Handler contains all the definitions that an application can be in like LAUNCH_ACTIVITY, PAUSE_ACTIVITY, BIND_SERVICE etc.

3. Calls the Looper.loop() method on the main thread: In order for work to take place on the main thread, the main method calls the Looper’s loop method on the main thread. This begins the execution of messages on the Loopers message queue. Now the main thread is up and running and can begin processing tasks from the queue.

The handler in ActivityThread class is responsible for handling every message that’s received in its onHandleMessage method. Resuming an activity, pausing it, starting it, binding services, handling receivers, flagging low memory, or trimMemory warnings all are handled here.

Even RELAUNCH_ACTIVITY is one of these cases. handleRelaunchActivity() is invoked which internally calls handleRelaunchActivityInner() which calls performLaunchActivity() which returns an Activity object. This Activity object already has crucial information like: Instrumentation, Context, Component and Intent information to the Activity.

The final step is when Instrumentation class method `callActivityOnCreate()` is invoked, which calls `performCreate()` method of the Activity class that calls Activity’s OnCreate method.

At this point, your Activity has been loaded with tonnes of useful variables and methods that can be used to create your awesome Android App! This is all thanks to the ActivityThread, some smart thinking behind the Handler and Looper framework.

We are inviting Android Developers to contribute back to the community via AndroIDIOTS. If you are interested in recording a podcast or writing tech articles, we would love to have you on board. Here is a small form you can fill so we can get back to you.

Follow us on twitter for regular updates and feel free to DM the hosts (Anupam & Tushar) for any queries.

Cheers!!

AndroIdiots Podcast 16: Android Process LifeCycle was originally published in AndroIDIOTS on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are all software developers and we love to code, don’t we? And ofcourse, Kotlin is our favourite language.

Don’t you wish you could write every system in Kotlin. Well its no news, that the Kotlin makers are actually making it true. We have discussed it before in our previous episode about Kotlin/Multiplatform and in this episode we discuss how to get started with Kotlin as a BackEnd language with Matt Thornfield.

Matt is the author of the book Building Spring Boot Applications with the Kotlin Programming Language distributed by Manning Publications and also has a course on with same name on LinkedIn Learning.

Show Summary:

Spring Boot:

Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can “just run”. It’s an open source project which creates a huge range of frameworks, plugins & tools around Java Virtual Machine and is used by many enterprises already.

How to get started:

You can put in your requirements on https://start.spring.io/ and chose Kotlin as the language of your choice. Other options are Java & Groovy. The website will generate a zip file, a starter kit, which can be used to start coding right away in your favourite IDE.

Advantages of Using Kotlin:

Immutable variables, data classes, sealed classes, compile time null check, a much less verbosity, a somewhat functional programming support, and Kotlin is still evolving. We will surely get a lot more features.

Complexities of switching to Kotlin from Java:

A couple of complexities around making the data side work and design choices. Listen to the podcast for more details. You may also check Matt’s course to learn all the nitty-gritties.

We thoroughly enjoyed having Matt on our podcast. Thank you Matt.

Manning Publications have been kind enough to share some discount codes for our listeners.
You can use the code: podandroid19 to get a flat 40% discount on any live free video course.

And here are few codes to get free Spring Boot Application With Kotlin course:
andkot-38DA
andkot-480B
andkot-B1FC

Link to the course :
www.manning.com/livevideo/buildin…gramming-language

We are inviting Android Developers to contribute back to the community via AndroIDIOTS. If you are interested in recording a podcast or writing tech articles, we would love to have you on board. Here is a small form you can fill so we can get back to you.

Follow us on twitter for regular updates and feel free to DM the hosts (Anupam & Tushar) for any queries.

Cheers!!

AndroIdiots Podcast 15: Using Kotlin as a BackEnd language with Matt was originally published in AndroIDIOTS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here are the top tweets from the last week you should not miss if you’re an #AndroidDev.

Amit Shekhar on Twitter

LiveData vs Observable Field in Android https://t.co/gRXKSRojhE #AndroidDev #Android

Google Developers on Twitter

Fact: Great things happen when people come together. Attend, organize, and speak at #KotlinEverywhere events. Find out more at https://t.co/DnpHBJ1Fnq and from this video with @FMuntenescu and @HHariri. Watch now → https://t.co/zSLG4KYg2C

androidiots on Twitter

@androidiots is in top 5 Android podcast to listen to in 2019. @_feedspot has been really kind to feature us. Thank you everyone for your support. https://t.co/zxbkLZmk7g #AndroidDev #AndroidDevelopment #kotlin #podcast #India Everything Compounds :)

androidiots on Twitter

In this episode, @urbanclap Android Team meets the passionate #Android folks @Zomato. We discuss Recyclerview, its Adapter, scalability and optimising performance with @SajalGupta94, @_prtks & @_yashikakatyal. Do listen in. There is tons of information. https://t.co/WQiYJJJkHY

MindOrks on Twitter

What is Lint? What is it used for? https://t.co/p0brKWyO5F #AndroidDev #Android

MindOrks on Twitter

Exploring Android ViewPager2 in Android https://t.co/yRfXTE1RiX #AndroidDev #Android

Amit Shekhar on Twitter

Mockito cannot mock because : final class in Kotlin https://t.co/R7GgyVYOtU #AndroidDev #Android #Kotlin

Firebase on Twitter

Firebase is coming back to India in June, with day-long events in Bangalore and Pune, and many meetups along the way. 🔥❤️🇮🇳 Register today → https://t.co/rOqAX0QLhV

Android Developers on Twitter

Build a dark theme for your Android app with the @MaterialDesign documentation and code! ☑️ Save battery power for devices with OLED screens ☑️ Reduce eye strain ☑️ Facilitate use in low-light environments Get started here → https://t.co/Jqvf4V4eGU https://t.co/I5ehVUrbtY

Android Developers on Twitter

Direct sharing from your app is now lightning fast with #AndroidQ's ShareSheet ⚡️ ✅ Loads instantly when launched ✅ Backwards compatible ✅ Publish sharing shortcuts in advance Learn more in this short video → https://t.co/EPVWEEt9tA

MindOrks on Twitter

Using Custom and Downloadable Fonts in Android https://t.co/LWAZsVgh3C #AndroidDev #Android #MindOrks

Amit Shekhar on Twitter

Create your own Custom View https://t.co/5JPSQYWIr0 #AndroidDev #Android #MindOrks #KotlinEverywhere #Kotlin

Amit Shekhar on Twitter

Gradle Tips and Tricks for Android https://t.co/zlfOKGAQd0 #AndroidDev #Android #MindOrks #Gradle #Tips #tricks

Amit Shekhar on Twitter

Primary and Secondary Constructors in Kotlin https://t.co/4e6OI9AQ5P #AndroidDev #Android #MindOrks #Kotlin

Flutter on Twitter

At #io19, @DomesticMouse and @redbrogdon's dedicated their talk to building for iOS with Flutter 📲 Check it out to learn how to build interfaces iOS users will love with Flutter's Cupertino package! Watch here → https://t.co/4RsYtTVvvX

Amit Shekhar on Twitter

Understanding inline, noinline, and crossinline in Kotlin https://t.co/6fi2nrfU0o #AndroidDev #Kotlin

Kotlin on Twitter

KotlinEverywhere is being planned all over the world. We already have more than 50 events - find or host one near you at https://t.co/s11wpDeaNP! https://t.co/CIbzWn1vHQ

Android Developers on Twitter

We teamed up with @Udacity to bring you a free online course 🙌 Learn to build Android apps using #Kotlin and #AndroidJetpack! Get started here ↓ https://t.co/uTLZs4WItd

Firebase on Twitter

On a new episode of #AskFirebase, @ThatJenPerson teams up with A/B testing champion @jonnypotatoes to answer your questions about Firebase Auth! 🔥🏆 Watch here → https://t.co/pFyOTp8MO6

Amit Shekhar on Twitter

Using Exoplayer to play Video and Audio in Android like a Pro https://t.co/kVzPz9TJjo #AndroidDev #Android #Exoplayer #pro #MindOrks

Android Developers on Twitter

AndroidQ Beta 3 is here! Join @adressyengineer to learn more about new updates including: ✅ Dark theme ✅ Gestural navigation ✅ Smart actions Watch here → https://t.co/7YQKZKlgAL

Follow AndroIDIOTS for more such amazing android related content.

Beat the Tweet #24 : 3–9th June 2019 was originally published in AndroIDIOTS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Zomato is an Indian search and discovery platform for restaurants, founded in 2008 by Deepinder Goyal and Pankaj Chaddah. It currently operates in 24 countries with more than 50 million downloads of its Android app.
Such scale requires an app to be dynamic enough to support various types of restaurants, cuisines of multiple locations. Hence the App needs to be developed at scale and be able to serve in all the possible forms.
We all know in Android this can be achieved with templatized nested Recyclerview and in this episode we have Sajal Gupta, Prateek and Yashika from Zomato's Android team, walk us through their journey with Recyclerview & its adapter and things that they do to make it highly performant and scalable.

Show Notes :

Generations of Recyclerview adapter at Zomato Android App.

Better RecyclerView Adapter (V1):

Heavy lifting is done by the base adapter itself, the developer extending this version needs to take care of onCreateViewHolder() and rest everything is sorted.

Better RecyclerView Adapter(V2):

View model is abstracted which was previously coupled with the view but now view holder holds the view model. Hence the onbind() method is no more needed.

Better RecyclerView Adapter (V3):

With onset of DiffUtils the adapter evolved to support the same.

Question : How to send the user interaction information in this new Adapter?
Hint : Take a closer look to onViewAttachedToWindow() method.

For more adapter secrets do listen to the episode.

We are inviting Android Developers to contribute back to the community via AndroIDIOTS. If you are interested in recording a podcast or writing tech articles, we would love to have you on board. Here is a small form you can fill so we can get back to you.

Follow us on twitter for regular updates and feel free to DM the hosts (Anupam & Tushar) for any queries.

Cheers!!

Androidiots Podcast 14 : Better RecylerViews feat Zomato. was originally published in AndroIDIOTS on Medium, where people are continuing the conversation by highlighting and responding to this story.