PanelSwitchHelper: a Java framework for keyboard-to-panel transitions on Android

The layout-height problem PanelSwitchHelper was written to remove

Chat, live and comment screens all need the same behaviour: tapping the input box raises the keyboard, tapping a smiley or plus button replaces the keyboard with a function panel, and the two never overlap. The common workaround is a Weight+LinearLayout whose height is recalculated at runtime. The README describes this as the "traditional technical solution" the framework improves on. That approach breaks down when the keyboard height changes mid-session, when the navigation bar hides or shows, or when the screen is a full-screen, notch or hole-punch device. PanelSwitchHelper targets Android app developers building those screens in Java or Kotlin. It is a UI-layer library, not a chat SDK, and it does not send messages or manage a socket. Its job ends at moving the panel.

How PanelSwitchLayout, content containers and panels fit together

The architecture is a three-part layout. PanelSwitchLayout is the outer container. Inside it sits a content container, and inside that sits the EditText and the rest of the scrolling content. The content container is told which EditText drives the keyboard through the app:edit_view attribute, and the README marks that attribute as required. From that reference the container can observe when the keyboard appears or disappears and resize the visible area accordingly. The README also lists app:linear_auto_reset_enable, which controls whether the LinearContentContainer accepts touch events and hides the panel on its own, and app:linear_auto_reset_area, which narrows that auto-hide behaviour to one View region. Two switching modes are documented: a sliding mode, described as smoother, and a fixed mode. app:animationSpeed sets the transition speed, with standard shown in the layout example. The framework also exposes APIs for a custom content container, a custom business panel, hiding the panel programmatically, and controlling switching speed.

Installing PanelSwitchHelper from JitPack and wiring a first layout

The README gives JitPack as the distribution channel. Add the repository to the allprojects block, then add the dependency. The version string in the README's dependency example is v1.5.15. Note the comment in that same block: from 1.4.0 onward the library only supports AndroidX.

allprojects {
    repositories {
        maven { url 'https://jitpack.io' }
    }
}

Then declare the dependency in the module build script. If your project is not on AndroidX, the README says to open the app in Settings.gradle and turn off the AndroidX configuration in gradle.properties before this will work.

dependencies {
    implementation 'com.github.DSAppTeam:PanelSwitchHelper:v1.5.15'
}

In the layout, wrap the screen in com.effective.android.panel.view.PanelSwitchLayout and put a content container inside it. The EditText id is what ties the two together, so the app:edit_view value must match the actual id.

<com.effective.android.panel.view.PanelSwitchLayout
    android:id="@+id/panel_switch_layout"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    app:animationSpeed="standard">

    <com.effective.android.panel.view.content.LinearContentContainer
        android:id="@+id/content_view"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:orientation="vertical"
        app:edit_view="@id/edit_text">

After the first build, the visible result is that tapping the EditText raises the keyboard and the content area shrinks above it rather than being covered. The README points to README_SENCE.md for scenario walkthroughs, README_API.md for the API surface, and README_UPDATE.md for version history; those files are the place to look for panel registration and toggle calls, because the main README stops at the container setup.

Where PanelSwitchHelper stops being the right tool

The dependency line carries its own constraint. The README states that 1.4.0 and later only support AndroidX, so a project still on the support library cannot take the current release without migrating first. The README does describe a non-AndroidX path, but it is a project-level switch in gradle.properties, not a per-library option, which means it affects the whole app. Second, this is Android-only and Java/Kotlin-only. Nothing in the README suggests a Flutter, React Native or Compose equivalent, so a cross-platform codebase gains nothing here. Third, the framework operates on native ViewGroup containers. The README lists Activity, Fragment, Dialog, DialogFragment and PopupWindow as supported containers, and the layout sample uses a RecyclerView subclass named HookActionUpRecyclerView, which hints that the content view may need touch handling that cooperates with the container. If your list already overrides touch events, that interaction is worth checking before you migrate a screen.

How it differs from hand-rolled window inset handling

The direct alternative is doing the work yourself with window insets and a height-animated layout, the Weight+LinearLayout pattern the README names. The difference is where the state lives. A hand-rolled solution typically reacts to a single keyboard event and animates one dimension, so a mid-session keyboard height change or a navigation bar toggle can leave the panel misaligned until the next event. PanelSwitchHelper keeps the keyboard and the panel inside one container that owns the transition, which is why the README can claim real-time adaptation when the input method changes height or the navigation bar hides. The trade-off is coupling: your layout must use the framework's containers and declare app:edit_view, so the screen is no longer a plain View hierarchy. A team that only needs a static panel below a fixed input bar will find the container overhead hard to justify.

Maintenance, licence and the upgrade cost you are accepting

The repository is not archived, and the last push was on 2026-08-12, which is recent enough that the project is still receiving changes. There are no retrieved releases, so versioning is expressed through the JitPack tag in the dependency line; the README badge shows version 1.4.0 while the dependency example uses v1.5.15, and the update log lives in README_UPDATE.md. That means upgrades are a matter of bumping the tag and reading that file, and the AndroidX-only rule from 1.4.0 is the kind of change that can strand an older project. The licence is Apache-2.0, which permits commercial use and modification and requires that the licence and notice be preserved; the LICENSE file is at the repository root. This is a description of the licence text, not legal advice, and a team with specific obligations should read LICENSE directly. The library is reported at 14K in the README badge, so the binary footprint is small relative to the layout logic it replaces.

Editorial conclusion

Adopt PanelSwitchHelper if your screen already has an EditText and a bottom panel, and you want the switch handled by a container instead of manual height math. Skip it if you need a cross-platform UI layer, or if you cannot move to AndroidX, since the README states that 1.4.0 and later only support AndroidX. Before committing, verify the version you pull from JitPack and check that your layout's app:edit_view attribute points at the real EditText id.

Frequently asked questions

Official sources

1. DSAppTeam/PanelSwitchHelper on GitHub
2. Issues
3. License: Apache-2.0
4. README