Abstract

We need to add a context menu to each dev tool which will help to perform some actions to update the tools state, like reset its configuration value to default or revert the updates the user made to it. Also, an useful action might be an action that will display a help dialog.

Help Dialog: Sometimes the DevTool title is not enough to explain its scope to the user. It would be nice to have a help component(an info button attached to all dev tool items) which will display a dev tool detailed info in for of a dialog.

Requirements

Add a dev tool context menu.
All tools except Group Tool should have the following items:

• Help
• Select default
• Reset selection

Group tools should have the following items:

• Enable all
• Disable all
• Set all to default
• Reset all changes

Implement a DevTool help component which will display:

1. Tool title;
2. Tool description;
3. Tool key;
4. Tool current configuration value;
5. Tool default configuration value.

Consumer flow

1. Open the sample app;
2. Select any source;
3. Notice dev tool items have a context menu, make sure all context menu actions are working properly;
4. Make sure the Help Dialog shows proper data.

Abstract

It would be way easier to access devtools if there will be a search feature so that I can search a dev tool in the configuration screen by id/name.

Requirements

Implement search feature.

Consumer flow

1. Open the configuration screen for any dev tool source type
2. Notice the search field on the top of the screen
3. Try to search for a dev tool and make sure everything works perfectly

Abstract

Both iOS projects, devtools/ios and samples/ios use CocoaPods, which is a Ruby gem. Everyone might have a different global version of CocoaPods installed on their machine which might cause problems. A solution is to use Bundler.

Requirements

1. Add Gemfile with cocoapods gem inside.
2. Now, the installation of dependencies will be done with bundle exec pod install.

Abstract

I've configured CI to automatically uploaded the artifact to maven central in #56 but I didn't invoke the configureSiging method and this is why the artifacts are not signed.

Requirements

Sign all artifacts before uploading them to Maven Central

Abstract

The current EnumTool component UI is ok enough as soon as we have a small number of options, however, it might be not handy for a large number of options.

It would be nice if the library will provide a dialog with a vertically scrollable list for tools with large options size.

Requirements

1. Split the DevTool view component option selector to a compact(with chips) and an extended one(a scrollable list inside a dialog);
2. Show the compact view when the tool options size is smaller than 7 and extended one vice-versa.

Consumer flow

1. Open the sample app;
2. Find the Enum tool [Custom Provider];
3. Make sure you can update its configuration value and the configuration value is persisted.

Abstract

The enum extended view becomes visible and overlaps the compact one after recycle.

Platform related info:

• OS: Android
• Library version: 1.0.0

Steps to reproduce

1. Open the sample app
2. Select any source, i.e. YAML
3. Scroll the list down, and up several times
4. Find any enum tool

Expected
All enum tools show the compact or extend options selector.

Actual
Both options selectors are visible and overlapped.

Screenshots

Requirements

1. Update library version to 1.0.1;
2. Update the changelog file.

Abstract

JCenter is shutting down, and we should get rid of it.

Requirements

Get rid of jcenter()

Consumer flow

Make sure CI is ✅

Abstract

Having always the latest versions of the libraries is good. Still, it is not always convenient, and keeping OldTargetApi as a critical warning failing the build might block other non-related PRs, which is not good. Instead, we can make this lint check informative and monitor it well. This way, we'll be able to do updates in an async mode.

Requirements

Update Android dependencies and make OldTargetApi lint check informative

Consumer flow

Nothing to test for this issue. Just make sure the CI is ✅

Abstract

SwiftLint, without indication of paths, lints all the paths in the project directory, including the Pods folder, which inevitably will show warnings.

Steps to reproduce

1. Open devtools/ios. Run Pods/SwiftLint/swiftlint. It shows warnings and errors.

Expected
SwiftLint should not show any warnings in the master branch.

Actual
SwiftLint shows warnings from the Pods directory (dependencies).

Requirements

Update Android library's "common" module dependency version for release configuration to 1.0.0

releaseApi("com.maximbircu:devtools-common:1.0.0") { transitive = true }

Abstract

The TextTool component was already implemented, It enables the ability to store and manipulate text/integer and floating-point numbers configurations. An android view implementation was already added in #17 now we need to implement the same view for iOS.

Requirements

Add TextTool view implementation for iOS

Implementation details

The toggle tool logic is already implemented inside the common module, you just need to provide a view implementation for it.
So basically you need to:

• Provide an implementation for TextToolView
• Consume the TextToolPresenter

Consumer flow

1. Open the sample app and go to the YML dev tools screen.
2. Find the TextTool UI control
3. Try to update the configuration value and make sure it's persisted after app restart.

Repeat the same use-case for Memory dev tools screen.

Abstract

A search feature would increase the UX of the configuration screen allowing users to find the configuration dev tool they are looking for quickly.

Requirements

Add search ability to the Dev Tools configuration screen

Consumer flow

1. Open any configuration screen
2. Try searching for a dev tool
3. Make sure the search feature works properly

Abstract

According to the project architecture, we already have a :devtools:common module which is a Kotlin multiplatform module and holds dev tools domain code which aims to be shared between difrernt platforms iOS/Android etc...

Running ./gradlew assemble will generate aar artifacts for Android platform usage and a fat iOS framework.

It was decided that there will be 2 more modules on for iOS and one for Android which will depend on aar and the fat framework respectively.

The android module is already up and running, we need now to set up the iOS one.

Requirements

1. Set up iOS library module
2. Set up iOS sample app module

Implementation details

You'll have to change the path here in order to make the tasks build and place the iOS fat framework inside the iOS library so that it will be able to consume it.
https://github.com/maximbircu/devtools-library/blob/master/devtools/common/build.gradle#L95
https://github.com/maximbircu/devtools-library/blob/master/devtools/common/build.gradle#L105

How to test

Make sure everything is set up and you can run the iOS sample app.

Abstract

As I see that documentation of this library is quite big. Maybe is a good idea to move it to a static website?!

I suggest https://v2.docusaurus.io/ as I used it for 2 projects and was pretty happy!

Other options:

• https://www.gitbook.com/
• https://docsify.js.org/
• https://grazedocs.io/
• https://www.mkdocs.org/
• https://couscous.io/

Implementation details

Doc generator may be located in documentation folder.
Using actions-gh-pages docs will be published at https://maximbircu.github.io/devtools-library

Abstract

We need to define a rough basic DevTool skeleton so that we have a clear vision around what the project has to be built.

Requirements

1. Define and set up a DevTool architecture;
2. Build a DevTool for boolean values, let it be a toggle dev tool.

Consumer flow

1. Open the sample app;
2. Make sure you use a toggle dev tool and the control is working.

Abstract

Currently to update a disabled dev tool you first have to enable it by tapping on the enable checkbox. It is possible to improve the UX of the library by enabling the tool automatically whenever the developer touches the tool control area.

Requirements

1. Enable the dev tool whenever the user touches its control area.
2. The behavior should remain the same for an enabled tool.

Consumer flow

u1

1. Open the dev tools screen for any source, i.e. YAML;
2. Touch the input area of any disabled dev tool;
3. Note that the tool became automatically enabled.

u2

1. Open the dev tools screen for any source, i.e. YAML;
2. Touch the input area of any enabled dev tool;
3. Make sure that you're able to edit the dev tool value.

Abstract

A group tool doesn't have a state, which means that it can not be enabled/disabled. Thus we should hide the enable/disable checkbox forever.

Platform related info:

• OS: Android, iOS
• Library version: 1.0.0

Steps to reproduce

1. Go to any configuration file, i.e. YAML config file
2. Find the group tool
3. Try to add canBeDisabled: true property

Expected
The enable checkbox should not be present

Actual
The enable checkbox ist present

Screenshots

Platform related info:

• OS: Android
• OS version: Any
• Library version: 1.0.0

Steps to reproduce

1. Open the sample app and open any dev tools configuration screen
2. Adjust any dev tool value
3. Don't hit the apply button and leave the screen by press the back button
4. Enter back to the same dev tools screen

Expected
The previous adjusted value should be reset.

Actual
The previous adjusted value is not reset

Preferable fix
It would be nice to implement a discard/keep changes dialog which will pop up whenever you'd like to leave the screen and have some unsaved changed dev tools.

Video

Abstract

Sometimes, we might have time as a configuration value. Sure thing that a timestamp most probably will be of a Long time. Thus, a TextTool could be used to represent it. Though, using the text tool, in this case, might not be handy, especially for high values.

A TimeTool was implemented in #20. It helps the library consumer manipulate easily time tool values by adding a good UX in the form of a time picker, on Android. We should ad a TimeTool view implementation for iOS too.

Requirements

Add a view implementation for TimeTool.

Implementation details

The time tool logic is already implemented inside the common module, you just need to provide a view implementation for it.
So, basically you need to:

• Provide an implementation for TimeToolView
• Consume the TImeTooPresenter

Consumer flow

1. Open the sample app and go to the YML dev tools screen.
2. Find the TimeTool UI control
3. Try to update the configuration value and make sure it's persisted after app restart.

Repeat the same use-case for Memory dev tools screen.

Abstract

Currently, all GitHub actions are running on unbuntu-latest. We need to update make them run on a macOS machine so that there'll be a possibility to assemble iOS frameworks.

Requirements

Make all actions run on macos-latest

Consumer flow

Make sure CI is ✅

Abstract

In Kotlin 1.4.20-M2 JetBrains deprecated Kotlin Android Extensions compiler plugin.

kotlinx.android.synthetic is no longer a recommended practice. Removing in favour of explicit findViewById

Requirements

Migrate the library to view-binding

Implementation details

https://proandroiddev.com/migrating-the-deprecated-kotlin-android-extensions-compiler-plugin-to-viewbinding-d234c691dec7

Consumer flow

Run the Android sample and make sure there is no regression.

Abstract

It would be nice to have the UI implemented in Jetpack Compose since this might improve a bit the performance.

Requirements

Rewrite Dev Tools to Jetpack Compose

Consumer flow

Run a small regression and check all dev tool types.

Abstract

Setup a new project and working environment for the new Devtools library.

Requirements

1. Create a new multiplatform (Android/iOS) project;
2. Setup minimal Github Actions CI;
3. Setup Github issue and PR description templates;
4. Add contribution rules to the README file.

Requirements

TBA by @maximbircu @ASV44

Implementation details

TBA by @maximbircu @ASV44

Abstract

We need a CI step that will check the correctness of each branch name and commit message to be able to keep everything consistent.

Requirements

Add a CI step that will check the branch and commit message style.

The branch should:

• Start with the number of the issue it relates to
• All words should be with lower case and split by -

The commit message

• Should not be longer than 72 chars
• Should start with a capital letter

How to test

The CI should fail in case any of the rules listed above are violated.

Abstract

We need to prepare the library before its first release, configure all kinds of publishing, and signing plugins to be able to upload the artifacts to maven central.

Requirements

1. Configure maven-publish
2. Configure dokka
3. Configure signing-plugin

Make sure the generated artifacts meets https://central.sonatype.org/pages/requirements.html

Abstract

ChipGroupLayout will crash if click on already selected chip

Platform related info:

• OS: Android
• OS version: Android 10(29)

Steps to reproduce

1. Go to 'whatever screen where enum tools are available "MEMORY" for example'
2. Click on 'second-option'
3. Then click one more time on 'second-option'
4. App will force-stop

Expected
The second option will remain selected

Actual
App force-stop

Additional context

Crash occurs because of 'getCheckedChipId' returns 'NO_ID (-1)'. ChipGruops returns NO_ID in order to unselect already selected chip. I dont know if this behavior applicable for devtools-library. If yes, can be added a check for NO_ID before retrieving chipName from chips map.

Abstract

There could be cases when several configuration values belong to a common context and it would be nice to have them grouped together somehow. This could be done by implementing a group dev tool, which will allow the library user to place a group of configuration values inside an object and visualize them a separate group inside the configuration screen.

Requirements

Implement a GroupTool, which will help the library consumer group its configuration values which belong to the same context.

Consumer flow

1. Open the sample app and go to the YML dev tools screen.
2. Find a GroupTool UI control
3. Try to update the configuration value of the dev tools inside the group and make sure all of them are persisted after the app restarts.

Repeat the same use-case for Memory dev tools screen.

Abstract

Sometimes, we want to limit the configuration value options the library user is able to select. This could be easily achieved by introducing an Enum tool, which will present a finite list of configuration values that could be selected for a parameter.

Requirements

Implement an Enum Tool which will help the library consumer limit the configuration values a parameter might take. It might be done in for of a radio group. The library consumer should have the ability to make the tool accept custom values though.

Consumer flow

1. Open the sample app and go to the YML dev tools screen.
2. Find the EnumTool UI control
3. Try to update the configuration value and make sure it's persisted after app restart.

Repeat the same use-case for Memory dev tools screen.

Abstract

We have already implemented a single tool and the required readers, now before continuing building all other tools we have to build the actual configuration screen and the list where the tools will be displayed.

Requirements

1. Implement the DevTools configuration screen and the actual DevTools list.
2. Adjust the iOS sample app to have the same structure as the Android one:
   • 1 screen should display 4 buttons
     • MEMORY: should open a config screen for memory source
     • YAML: should open a config screen for Yaml source
     • JSON SCHEMA: should open a config screen for Json source
     • COMBINED: should open a config screen with combined sources

Implementation details

• The config screen should implement ConfigScreenView and use ConfigScreenPresenter
• There should be a separate component for the list itself that should implement DevToolsListView and that should be passed to the ConfigScreenPresenter as a parameter

Consumer flow

1. Open the sample app
2. Walkthrough all screens of all tools sources and make sure the dev tools are displayed inside a list

Abstract

Sometimes, we might have time as a configuration value. Sure thing that a timestamp most probably will be of a Long time. Thus, a TextTool could be used to represent it. Though, using the text tool, in this case, might not be handy, especially for high values. It would be nice if we'll have a separate tool for time values, which will simplify the time configuration value manipulations providing a good UX in the form of a time picker.

Requirements

Implement a TimeTool, which will help the library consumer easily manipulate time configuration values.

Consumer flow

1. Open the sample app and go to the YML dev tools screen.
2. Find the TimeTool UI control
3. Try to update the configuration value and make sure it's persisted after app restart.

Repeat the same use-case for Memory dev tools screen.

Abstract

The EnumTool was already implemented, it enables the ability to limit the configuration value options the library user is able to select. An android view implementation was already added in #21 now we need to implement the same view for iOS.

Requirements

Add EnumTool view implementation for iOS

Implementation details

The toggle tool logic is already implemented inside the common module, you just need to provide a view implementation for it.
So basically you need to:

• Provide an implementation for EnumToolView
• Consume the EnumToolPresenter

Consumer flow

1. Open the sample app and go to the YML dev tools screen.
2. Find the EnumTool UI control
3. Try to update the configuration value and make sure it's persisted after app restart.

Repeat the same use-case for Memory dev tools screen.

Abstract

Library consumers might need to monitor specific tools update to react specifically to the new configuration values.

Requirements

Add a critical flag to the DevTool.
Whenever a tool with critical = true gets updates the library consumer should be notified through DevTools.kt#L15

Consumer flow

Usecase 1

1. Open the sample app
2. Update any critical tool (You can find the critical tool using the help dialog)
3. Make sure you see a toast telling that a critical update just happened

Usecase 2

1. Open the sample app
2. Update any non-critical tool (You can find a non-critical tool using the help dialog)
3. Make sure you see a toast telling that a non-critical update just happened

Abstract

We need to implement a multiplatform Preferences mechanism to be able to persist configuration values on both iOS and Android.

Requirements

Implement multiplatform Preferences and use it as a dev tool configuration store.

Consumer flow

1. Open the sample app;
2. Notice a toggle tool on the screen; (Remember it's current state)
3. Update the toggle tool
4. Restart the app and make sure the configuration value was persisted and you don't see the old one.

Abstract

Currently, the library is able to read dev tools directly from memory. This option was added more for test purposes and might not be comfortable enough for a real library consumer. That's why we need to support a way simpler way of doing this. One of the options would be to add YML support.

Requirements

Add YML source support. Library consumers should be able to define their tools in the form of a YML file while the library should be able to parse them and extract the dev tools together with all dev tools metadata.

Check out the Android YML sample file

How to test

Make sure the toggle tool is still present on the screen, and it's taken from a YML file.

Abstract

The dev tool configuration updates are not persisted after scrolling the list on Android devices. Most probably this happens because we don't have an in-memory persistence mechanism and all updates that the user is doing are kept and taken from the view which gets recycled.

Platform related info:

• Platform: Android

Steps to reproduce

1. Open the app
2. Select any source
3. Update configuration value of the first tool
4. Scroll the list till the end
5. Scroll the list back to the tool you've updated

Expected
The tool changes should be present

Actual
The tool changes are reset to default

Abstract

We're currently using a custom secret to pass the GH access token to the [email protected] and seems that this doesn't work for PR's from forks, because the secrets are not shared with them for security reasons. However, we could fix this by using the default GITHUB_TOKEN env variable.

Requirements

Pass GITHUB_TOKEN to [email protected] instead of a custom secret.

How to test

Make sure the CI is ✅

Abstract

The first and easiest tool which is already implemented in the Android library in #3 should be implemented on iOS too.

Requirements

1. Implement dev tools configuration screen which should display a tools list
2. Implement ToggleTool;
3. Integrate all required tools for linting and testing.

Implementation details

The toggle tool logic is already implemented inside the common module, you just need to provide a view implementation for it.
So basically you need to:

• Provide an implementation for ToggleToolView
• Consume the ToggleToolPresenter

Consumer flow

1. Open the iOS sample app and make sure you see a toggle tool on the screen;
2. Update the tool value;
3. Kill the app process;
4. Restart the app and make sure the tool value you selected previously is preserved.

Abstract

It would be too hard for library consumers to integrate the library and benefit of all its features without a good documentation.

Requirements

1. Find the option to store the library API docs
2. Cover the whole library API with docs

Consumer flow

Make sure the library API docs are accessible, straight forward, and concise.

Abstract

A library user might need to update the dev tools programmatically, a valid use-case would be updating them from startup arguments to run the app preconfigured.

Requirements

1. Add a fun updateFromParams(params: Map<String, Any>) to the public API which will iterate through all tools and will update their values with values taken from the passed params property.
2. Add also a updateFromBundle(bundle: Bundle?) method which will take an Android bundle as a parameter, will extract the arguments from it and will call the updateFromParams

Consumer flow

1. Open the sample app passing --ez toggle-tool true --ez tools-group.toggle-tool true as startup arguments;
2. Make sure the changes are applied.

Clicking on contributing guidelines on this page leads to 404

Abstract

We have already implemented the ToggleTool component which enables the ability to store and manipulate boolean configurations. Now we need to implement a tool component for text values.

Requirements

Implement the TextTool component which will be able to store and manipulate text configuration values.

Consumer flow

1. Open the sample app and go to the YML dev tools screen.
2. Find the TextTool UI control
3. Try to update the configuration value and make sure it's persisted after app restart.

Repeat the same use-case for Memory dev tools screen.

Abstract

It would be nice to release a new version for every commit merged to the master branch, and we can do automate this using Github Actions.

Requirements

Upload dev-tools to maven central when building master branch.

Consumer flow

Nothing to test 🤷‍♂️

Abstract

We need a tool that will help us monitor better the code coverage changes during project development lifetime. https://codecov.io/ is a tool which fits nice for this.

Requirements

Integrate https://codecov.io/

Consumer flow

Make sure code coverage info is posted to https://codecov.io/

Abstract

The library was released to maven central and now we can update Update the "Add the library dependency" section from the QuickStart docs page.

Requirements

Describe the steps to add the library dependency to a library consumer under the "Add the library dependency" section from the QuickStart docs page.

Abstract

Currently, the library is able to read dev tools directly from memory. This option was added more for test purposes and might not be comfortable enough for a real library consumer. That's why we need to support a way simpler way of doing this. One of the options would be to add YML support.

Requirements

Add YML source support. Library consumers should be able to define its tools in the form of a YML file while the library should be able to pars and extract the dev tools together with all dev tools metadata.

How to test

Make sure the toggle tool is still present on the screen, and it's taken from a YML file.

Abstract

For some library, consumers might be useful the ability to get all config info form of a JSON string.

Requirements

• Add a getConfigAsJson method to DevToolsStorage.kt
• Add a filterEnabled parameter so that the library user will be able to filter out the disabled configuration values.

Consumer flow

Usecase 1

1. Go to any source Dev Tools Configuration screen
2. Add val jsonConfiguration = devtools.getAllConfigAsJson() inside the onCreate method
3. Place a breakpoint and check the jsonConfiguration result
4. Make sure the JSON configuration string contains all configuration values

Usecase 2 (Make sure the filter predicate works properly)

1. Go to any source Dev Tools Configuration screen
2. Add val jsonConfiguration = devtools.getAllConfigAsJson { tool -> tool.isEnabled } inside the onCreate method
3. Place a breakpoint and check the jsonConfiguration result
4. Make sure the JSON configuration string contains all enabled configuration values
   You can try and experiment with different filters.

Abstract

A GroupTool was implemented in #22. It helps the library consumer group a set of dev tools that belongs to the same context. The Android view implementation was already added in #22, we need to and iOS view implementation.

Requirements

Add a view implementation for GroupTool.

Implementation details

The time tool logic is already implemented inside the common module, you just need to provide a view implementation for it.
So, basically you need to:

• Provide an implementation for GroupToolView
• Consume the GroupTooPresenter

Consumer flow

1. Open the sample app and go to the YML dev tools screen.
2. Find the TimeTool UI control
3. Try to update the configuration value and make sure it's persisted after app restart.

Repeat the same use-case for Memory dev tools screen.

Abstract

Currently, the library is able to read dev tools directly from memory and from a YAML configuration file. Though JSON Schema support might be useful especially for library consumers that would want to take the configuration from an API.

Requirements

Add JSON source support. Library consumers should be able to define their tools in the form of a JSON Schema file while the library should be able to parse them and extract the dev tools together with all dev tools metadata.

Consumer flow

1. Open the sample app and select JSON source
2. Make sure al dev tools are presented and work properly