README_EN.md

FloatingX

FloatingX is a flexible and powerful floating window solution.

English Introduction

See detailed documentation here

👏 Features

• Supports JetPack Compose
• Supports semi-hidden floating window mode
• Supports custom hide/show animations;
• Supports multi-touch, precise touch gesture recognition;
• Supports custom history position saving and restoration;
• Supports system floating window, in-app floating window, local floating window;
• Supports boundary rebound, edge hovering, boundary settings;
• Supports setting floating window content in layout or View ways;
• Supports custom floating window display position, supports auxiliary positioning;
• Supports blacklist and whitelist functions to prevent floating window display on specific pages;
• Supports kotlin build extensions and is friendly compatible with Java;
• Supports display position [forced fix] to cope with special models (requires separate activation);
• Supports local floating window, which can be displayed in ViewGroup, Fragment, Activity;
• Comprehensive logging system, you can see different levels of Fx running processes when turned on, making it easier to find and solve problems.

👨‍💻‍ Dependency Method

Gradle

dependencies {
    implementation 'io.github.petterpx:floatingx:2.2.6'
    
    // System floating window && need to be imported when compose
    // AppHelper invoke enableComposeSupport()
    implementation 'io.github.petterpx:floatingx-compose:2.2.6'
}

🏄‍♀️ Demo

Full screen, activity, fragment, single view	Small screen display	Abnormal aspect ratio screen

Screen rotation	Feature demo

Comprehensive Log Viewer

Enable the log viewer to see the entire Fx running track, making it easier to find and track problems. Also supports custom log tags.

App	Activity	ViewGroup

👨‍🔧‍ Usage

Global Floating Window Management

AndroidManifest (optional)

// If not using system floating window, you can ignore this step (skip if FxScopeType.App)
<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />
<uses-permission android:name="android.permission.SYSTEM_OVERLAY_WINDOW" />

kt

FloatingX.install {
	setContext(context)
    setLayout(R.layout.item_floating)
  	setScopeType(FxScopeType.SYSTEM_AUTO)
}.show()

Java

AppHelper helper = AppHelper.builder()
	.setContext(context)
    .setLayout(R.layout.item_floating)
  	.setScopeType(FxScopeType.SYSTEM_AUTO)
    .build();
FloatingX.install(helper).show();

Local Floating Window Management

General Creation Method

kt

ScopeHelper.builder {
  setLayout(R.layout.item_floating)
}.toControl(activity)

kt & java

ScopeHelper.builder()
    .setLayout(R.layout.item_floating)
    .build()
    .toControl(activity)
    .toControl(fragment)
    .toControl(viewgroup)

Kotlin Extension Support

Create floating window in activity

private val scopeFx by createFx {
    setLayout(R.layout.item_floating)
    build().toControl(this/Activity)
}

Create floating window in fragment

private val activityFx by createFx {
    setLayout(R.layout.item_floating)
    build().toControl(this/Fragment)
}

Create floating window in viewGroup

private val activityFx by createFx {
    setLayout(R.layout.item_floating)
    build().toControl(this/Viewgroup)
}

🤔 Technical Implementation

System level floating window is implemented based on WindowsManager. It globally holds a separate floating window View and inserts it into WindowManager at appropriate times by listening to Activity lifecycle through AppLifecycle.

App level floating window is implemented based on DecorView. It globally holds a separate floating window View and inserts it into DecorView at appropriate times by listening to Activity lifecycle through AppLifecycle.

View level floating window is based on the given ViewGroup.

Fragment level floating window is based on its corresponding rootView.

Activity level floating window is based on DecorView's internal R.id.content.

Specific details are as follows:

See my blog for more details: Source Code Analysis | Activity-setContentView

Ps: Why should the app-level floating window be inserted into DecorView instead of R.id.content -> FrameLayout?

Inserting into DecorView maximizes the floating window's freedom of movement, allowing it to be truly [fullscreen] draggable.

Inserting into content limits its draggable range to application view range, affected by status bar, bottom navigation bar, and default AppBar. For example, if the user hides the status bar or navigation bar, the corresponding view size will change, affecting the floating window's position.

👍 Thanks

The initial implementation idea of the basic floating window View comes from EnFloatingView's FloatingMagnetView, which was thoroughly refactored and evolved.

The measurement code for the navigation bar comes from Wenlu and has been further adapted to cover 95% of the market models. It can be said to be the only tool that can accurately measure the navigation bar.

About Me

Welcome to follow my public account and look forward to progressing together. If you have any usage problems, you can also add me on WeChat.

WeChat: Petterpx