What is floating window in android

#4 Floating Windows on Android: Floating Window

Learn how to use floating windows in your Android apps. The fourth lesson teaches you how to create actual floating windows and show them.

Have you ever wondered how to make those floating windows used by Facebook Heads and other apps? Have you ever wanted to use the same technology in your app? It’s easy, and I will guide you through the whole process.

I’m the author of Floating Apps; the first app of its kind on Google Play and the most popular one with over 8 million downloads. After 6 years of the development of the app, I know a bit about it. It’s sometimes tricky, and I spent months reading documentation and Android source code and experimenting. I received feedback from tens of thousands of users and see various issues on different phones with different Android versions.

Here’s what I learned along the way.

Before reading this article, it’s recommended to go through Floating Windows on Android 3: Permissions.

In this article, I will teach you how to show the actual floating window over other apps.

WindowManager 🔗

WindowManager is an interface that the app can use for communication with the window manager.

And the window manager on Android handles everything you can see on the screen. Fortunately, it allows us to add and remove views directly, and if we add them with correct parameters, we have our floating windows!

LayoutParams 🔗

In the short source code sample above, we called addView with the second parameter being windowParams of type WindowManager.LayoutParams . What are the correct params?

The first four parameters specify the position and size of the window. Usually, I tend to have layout params defined on class level, so I keep these four being zero and calculate them later. Technically, we can set them right in place, but I rather move this code outside of the variable assignment. For calculation, it’s possible to use something like this to consider also screen size:

The next parameter is the type of window. This one is critical, and using the right type, we tell Android how it should treat our view. Before Android O, the recommended type was WindowManager.LayoutParams.TYPE_PHONE . There are other types, and it’s possible to mix them to achieve different priorities of windows. However, as it’s unavailable from Android O, I don’t recommend using it. From Android O, the recommended type is WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY , and other types fallback to it.

The next comes flags , and they are also critical as they tell Android how we want our window to be interacting with touches, buttons and key input.

• FLAG_LAYOUT_NO_LIMITS — Allow window to extend outside of the screen. This one is optional, but I tend to use it and calculate limits on my own.
• FLAG_NOT_FOCUSABLE — The window won’t ever get key input focus, so the user can not send key or other button events to it. Those will instead go to whatever focusable window is behind it. This one is extremely important, because it allows us to control the apps behind the floating window.
• FLAG_NOT_TOUCH_MODAL — Allow any pointer events outside of the window to be sent to the windows behind it.
• FLAG_WATCH_OUTSIDE_TOUCH — Receive events for touches that occur outside of your window. This one will be important in the future.

The last parameters is the pixel format. I recommend PixelFormat.TRANSLUCENT as it tells Android to select a format that supports translucency. And having windows partly transparent is fun .

Layout 🔗

Unfortunately, we can’t use Jetpack Compose for floating windows as we need just a view, and there is no activity and thus no lifecycle.

However, we can use old good layout XML. To use it, we need to get instance of the LayoutInflater and inflate the view:

For demonstrational purposes, let’s rely on LinearLayout . It nicely demonstrates how our window layout is structured. In Floating Apps, I use the base layout for the window and insert the content dynamically, but we can have just a single layout file as there is only one window type.

I’m not good designer, so I just pick a few semi-random colors for the window design .

And, voála, the result of my designing skill:

Floating Window 🔗

We have prepared view, layout parameters, and window manager. Now, let’s put the code together, and our very first floating window is ready!

Let’s create Window class to encapsulate the whole logic. The full source code:

Floating Apps 🔗

If you are interested in how complex the logic behind simple floating windows can get, there is a bit of the background from Floating Apps.

There are many mini-apps. Each of them has a header file that contains the necessary information about it — localized name, internal identifier, icon, list of required permissions, launch preferences, window presets, etc. Headers files are kept in memory and used for listing available apps.

When the app is launched, the information from its header file is used to create the app’s instance and an instance of Window .

Each of the apps extends Application that provides a basic set of features for managing its lifecycle, defining menus, handling window size, position, minimizing, etc. Also, the Application class can automatically solve a lot of shortcomings in floating technology. I will teach you more about all these issues in one of the next articles.

Also, all running apps are registered with the global list of active windows, and that allows for many exciting features — listing all active apps, running some of them only once, reactivating running apps instead of rerunning them, cross-app state refreshing, etc.

As you can see, there can be a vast logic. As normal Android apps rely on the system to provide many of these features, I had to rewrite all of these features for Floating Apps from scratch.

Results & Missing Pieces 🔗

As you can see in the animation below, we open our new floating window and even switch apps. The window is still there visible above them.

However, there are two main issues:

• The window stays in the center of the screen, and we can’t move it anywhere.
• It’s not possible to type texts. The keyboard is not activated and doesn’t appear.

We will address both of these problems in the next articles.

Source Code 🔗

The whole source code for this article is available on Github.

Stay Tuned 🔗

Eager to learn more about Android development? Follow me (@vaclavhodek) and Localazy (@localazy) on Twitter, or like Localazy on Facebook.

The Series 🔗

This article is part of the Floating Windows on Android series.

Источник

#4 Floating Windows on Android: Floating Window

Learn how to use floating windows in your Android apps. The fourth lesson teaches you how to create; actual floating windows and show them.

Have you ever wondered how to make those floating windows used by Facebook Heads and other apps? Have you ever wanted to use the same technology in your app? It’s easy, and I will guide you through the whole process.

I’m the author of Floating Apps; the first app of its kind on Google Play and the most popular one with over 8 million downloads. After 6 years of the development of the app, I know a bit about it. It’s sometimes tricky, and I spent months reading documentation and Android source code and experimenting. I received feedback from tens of thousands of users and see various issues on different phones with different Android versions.

Here’s what I learned along the way.

Before reading this article, it’s recommended to go through Floating Windows on Android 3: Permissions.

In this article, I will teach you how to show the actual floating window over other apps.

WindowManager

WindowManager is an interface that the app can use for communication with the window manager.

And the window manager on Android handles everything you can see on the screen. Fortunately, it allows us to add and remove views directly, and if we add them with correct parameters, we have our floating windows!

LayoutParams

In the short source code sample above, we called addView with the second parameter being windowParams of type WindowManager.LayoutParams . What are the correct params?

The first four parameters specify the position and size of the window. Usually, I tend to have layout params defined on class level, so I keep these four being zero and calculate them later. Technically, we can set them right in place, but I rather move this code outside of the variable assignment. For calculation, it’s possible to use something like this to consider also screen size:

The next parameter is the type of window. This one is critical, and using the right type, we tell Android how it should treat our view. Before Android O, the recommended type was WindowManager.LayoutParams.TYPE_PHONE . There are other types, and it’s possible to mix them to achieve different priorities of windows. However, as it’s unavailable from Android O, I don’t recommend using it. From Android O, the recommended type is WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY , and other types fallback to it.

The next comes flags , and they are also critical as they tell Android how we want our window to be interacting with touches, buttons and key input.

• FLAG_LAYOUT_NO_LIMITS — Allow window to extend outside of the screen. This one is optional, but I tend to use it and calculate limits on my own.
• FLAG_NOT_FOCUSABLE — The window won’t ever get key input focus, so the user can not send key or other button events to it. Those will instead go to whatever focusable window is behind it. This one is extremely important, because it allows us to control the apps behind the floating window.
• FLAG_NOT_TOUCH_MODAL — Allow any pointer events outside of the window to be sent to the windows behind it.
• FLAG_WATCH_OUTSIDE_TOUCH — Receive events for touches that occur outside of your window. This one will be important in the future.

The last parameters is the pixel format. I recommend PixelFormat.TRANSLUCENT as it tells Android to select a format that supports translucency. And having windows partly transparent is fun ;-).

Layout

Unfortunately, we can’t use Jetpack Compose for floating windows as we need just a view, and there is no activity and thus no lifecycle.

However, we can use old good layout XML. To use it, we need to get instance of the LayoutInflater and inflate the view:

For demonstrational purposes, let’s rely on LinearLayout . It nicely demonstrates how our window layout is structured. In Floating Apps, I use the base layout for the window and insert the content dynamically, but we can have just a single layout file as there is only one window type.

I’m not good designer, so I just pick a few semi-random colors for the window design ;-).

And, voála, the result of my designing skill:

Floating Window

We have prepared view, layout parameters, and window manager. Now, let’s put the code together, and our very first floating window is ready!

Let’s create Window class to encapsulate the whole logic. The full source code:

Floating Apps

If you are interested in how complex the logic behind simple floating windows can get, there is a bit of the background from Floating Apps.

There are many mini-apps. Each of them has a header file that contains the necessary information about it — localized name, internal identifier, icon, list of required permissions, launch preferences, window presets, etc. Headers files are kept in memory and used for listing available apps.

When the app is launched, the information from its header file is used to create the app’s instance and an instance of Window .

Each of the apps extends Application that provides a basic set of features for managing its lifecycle, defining menus, handling window size, position, minimizing, etc. Also, the Application class can automatically solve a lot of shortcomings in floating technology. I will teach you more about all these issues in one of the next articles.

Also, all running apps are registered with the global list of active windows, and that allows for many exciting features — listing all active apps, running some of them only once, reactivating running apps instead of rerunning them, cross-app state refreshing, etc.

As you can see, there can be a vast logic. As normal Android apps rely on the system to provide many of these features, I had to rewrite all of these features for Floating Apps from scratch.

Results & Missing Pieces

As you can see in the animation below, we open our new floating window and even switch apps. The window is still there visible above them.

However, there are two main issues:

• The window stays in the center of the screen, and we can’t move it anywhere.
• It’s not possible to type texts. The keyboard is not activated and doesn’t appear.

We will address both of these problems in the next articles.

Source Code

The whole source code for this article is available on Github.

Stay Tuned

Eager to learn more about Android development? Follow me (@vaclavhodek) and Localazy (@localazy) on Twitter, or like Localazy on Facebook.

The Series

This article is part of the Floating Windows on Android series.

Localazy

There are over 4 billion people online behind language barriers. Speak everyone’s language.

Источник

How to Make a Floating Window Application in Android?

Well, on our desktop computers we can easily restore down windows, do something in the background, and maximize the window whenever we want. But we don’t see this feature in android apps that much. Nowadays we can see android is offering Split Screen, but that’s a feature provided by OS, not the app’s individual feature. Let’s make an app that can minimize and maximize itself on just a button click. This feature can help users, in a lot of ways. Suppose you are reading some pdf document with some mathematical calculations and then a minimized calculator over the pdf viewer app will be very helpful. There are a lot of apps that use this feature like Clipboard, MI Calculator, and many more. Here’s a demo of the final app of this article. Note that we are going to implement this project using the Java language.

Step by Step Implementation

Step 1: Create a New Project

To create a new project in Android Studio please refer to How to Create/Start a New Project in Android Studio. Note that select Java as the programming language.

Step 2: Let’s make the working platform

• Add new Colors for the App: Go to values -> colors.xml. Any custom color can be added here. We have added these two colors.

• Remove the ActionBar: In Android Studio 4.1, go to values -> themes. There are two themes XML file, one for light mode and one for dark mode. In both of the XML, in the style block change the parent attribute to Theme.MaterialComponents.DayNight.NoActionBar.
• Change primary Theme color for the App: In the same file, the first item block must be about the primary color of the app. Here the newly added colors are added. In the item block add @color/gfgTheme or @color/gfgThemeTwo.

Step 3: Let’s make all the Layouts first

3.a: Start working on the activity_main.xml file

This XML file makes the layout of the Main Activity of the app. The layout is not so complicated. There’s only a Button, TextView, EditText, and another Button one after another inside a ConstraintLayout. Here is the XML code.

3.b: Start working on the floating_layout.xml file

Go to res -> layout. Right-click on layout -> New -> Layout Resource File. Add the name of the layout (floating_layout for here). This XML file makes the layout of the floating window. It has the same components just as the Main Layout but with slightly different size constraints. Here is the XML code.

Step 4: Start working on the Java programs

We made 3 classes here. Obviously, the first one is the MainActivity. The second one is FloatingWindowGFG for the floating window service and the last one is a Common class for two common variables.

Источник