rafaelsramos/hermeslogger

A Runtime information gathering system aimed at empowering testers/QAs

Hermes

Hermes is an open source Android library that aims at increasing the overall team's productivity. It does so by empowering not-so-technical team members, such as QAs and Testers to more easily and independently perform software analysis. By empowering not-so-technical team members, the time developers have to dedicate clarifying behaviours or looking into issues that, turn out, can only be solved by another team, would decrease.

Usual issue analysis flowchart

Section A and C are inevitable, making it more likely to navigate from Section A to C, not having to pass by Section B, will result in an overall team productivity improvement.

Gradle Setup

On your build.gradle (Project level) add mavenCentral() to your repositories.

repositories {
  google()
  mavenCentral()
}

On your build.gradle (App level) add the library dependency.

dependencies {
  implementation 'io.github.rafaelsramos:hermeslogger:0.1.0'
}

Setup in project

With 3 simple lines, the HermesLogger is attached to the project.

Hermes.initialize(isDebugEnvironment)
// SystemInfoBuildable implementation
Hermes.updateSystemInfo(systemInfoBuildable)
OverviewLayout.create(activityReference)

Hermes.initialize(isDebugEnvironment) informs Hermes if current environment is or not a debug environment. If it's not, all interactions with the library will be aborted.

Hermes.updateSystemInfo(systemInfoBuildable) provides Hermes with an implementation that will be used to build device/app information, such as device model, dimentions, or even App environment or variant.

OverviewLayout.create(activityReference) generates an OverviewLayout, that will inflate itself on top the activity's views. This layout is where:

• All the submitted logs can be seen;
• Logs can be removed;
• Individual logs can be shared;
• Entire log stack can be shared;

Use cases

Debugging and testing an Android application can be hard. However, with some well placed hints, one's life can be substantially easier.

Here are some Common use-cases:

• Transitions between fragments:

  Hermes.i().message("Transitioning to: ${fragment.javaClass.simpleName}").submit()

• API call information:

  Hermes.i()
      .message("AllProducts API call")
      .extraInfo(result.data, format = DataType.JSON) // Formats the content as Json
      .submit()

• Exceptions

  try {
      throw IllegalArgumentException("Invalid arguments")
  } catch (ex: IllegalArgumentException) {
      Hermes.e().throwable(ex).submit()
  }

Share events

Specially for QAs and Testers, it is part of the job to share with devs bugs and strange behaviours. With that specific task in mind, it is possible to share a single or the whole stack of logs though Messenger, Whatsapp, mail, ect.

Simple event share

On each event's detailed view, on the top right corner, there is a share icon, that can be used to share the information of that particular event;

To use such a feature for Android 10- devices,it is necessary to request WRITE_EXTERNAL_STORAGE permission from the user:

To use the Share feature:

• On Android 10- devices it is necessary to request WRITE_EXTERNAL_STORAGE permission from the user.
  1. Declare the permission on AndroidManifest.xml

     <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"
        android:maxSdkVersion="28" />

  2. Ask permission to the user at runtime (using TedPermission in the example below)

     TedPermission
         .with(this)
         .setDeniedMessage("Necessary to use share feature\n\n")
         .setPermissions(Manifest.permission.WRITE_EXTERNAL_STORAGE)
         .check()

• On Android 10+ devices, there is no necessity for requesting permissions.

hermeslogger's Issues

Create Overview layout, to ease usage

Allow filtering by content or date

Allow user to filter all the logs by date, or content, to find what he's looking 4.

Ensure the toolbox is not shown in production

Start only displaying logs overview after a flag is given

Improve Info add / show architecture and usability

As a dev, using this library, I want to use it in a structured and meaningful way.

Create view all logs tab, in the overview section

Allow the user to view all logs, to ease comprehension of what happened

Create filter section

Replace the tabs for a filter system, to give us more flexibility

Publish beta version

• Clean all code;
• Assure Kotlin coding conventions for libraries:
  • Always explicitly specify member visibility (to avoid accidentally exposing declarations as public API)
  • Always explicitly specify function return types and property types (to avoid accidentally changing the return type when the implementation changes)
  • Provide KDoc comments for all public members, with the exception of overrides that do not require any new documentation (to support generating documentation for the library)
• Allow devs to see implementation;
• Finish readme

Improve filtering/Search

As a user, I want to be able to:

• Use lower or upper cases to search;
• Use regex to search for it?

Create Info section

In this section/screen the devs should be able to:

1. Communicate general information, to be seen by other devs, QAs and Testers;
2. Provide information that can ease the experience of QA's and testers, such as credentials specific users, or even Service responses, can be copy-pasted into Charles, or other debugging proxy software;

This section/screen must allow for a "folder-like" system, to make it easier to find information.

Publish on maven

Have the library accessible from maven repository

• Publish on maven;
• Publish first official release;

Support some Overview customizability

Allow the library users to edit:

• Overall layout alpha (default value -> 0.9F)
• ...

Remove external sample App from the project

Create Timber tree, to easily anchor to Timber

Create a timber tree, that can be attached to Timber, and log all Timber logs onto Hermes.

This makes it really fast to extract real value from Hermes.

Add number of notifications

As a user, I want to be able to see how many logs e have, of each type

Allow devs to place tags on events

In order to group up logs, allow devs to place tags into logs.

This will allow users to more easily find important logs.

Allow users to interact with the overview, to invoke commands

On the Overview, allow the users to press commands, that will be mapped on the App

Allow adding commands with a ViewTreeObserver, so that it they are recycled automatically

Commands should:

• Have a title;
• Have a brief description (optional);
• Have a confirmation alert;

Example of commands:

• Clear cache or shared preferences;
• Enable / Disable features;
• Enable / Disable other debugging tools;
• Switch between languages;
• Copy something to clipboard;
• Close this tool;

Add click listeners on ViewHolders init

Instead of adding the click listeners on the #bind, add it on the init. Minor performance improvement.

Add log number on the logs' Overview

As a user, I want to be able to see the number of a Log, to come back to it later on.

Create settings tab

The settings tab should allow the user to:

• Completly close the toolbox;
• Change the alpha (to allow seeing what's behind it);