preface

In Android circles about the popup window open source framework or a lot, but most of the extensions are in style, such as a type of pop-up developers into different parameters can be displayed on the UI effects of different effects, such extension is indeed very convenient but in the specific work our business development, UI pursuit of pop-up window style Basically, the effect of each type of popover interface is quite different in business scenarios, and it cannot achieve the unification of interface in the real sense

The focus of this scenario is not on UI effects but on the business logic of popovers

ideas

Thanks to Markzhai’s concept of task flow, the idea of abstracting the process of App initialization into three phase categories: Flow, Wave, and Task

I’ve sorted out some popovers related categories (ps: popovers are no longer the usual concept of a Dialog)

public enum PopType {
    DIALOG,
    WEBVIEW,
    WIDGET,
    POUPOWINDOW,
    TOAST,
    SNACKBAR,
    OTHERS
}
Copy the code

I’ve also tried to unify and abstract these various pop-ups into one of the core members of this framework, the PopLayerView

It is a popover view but does not inherit from view and has basic functions like show,hide and other native popovers

It can be any of the popovers listed above just by passing in your specific popover strategy

The framework is made from the requirement and then the requirement document might require you to delay the popovers for a fixed amount of time and disappear some of the active popovers require you to expire at a specific time or how do you manage those popovers when the business is delivering multiple active Windows to meet their needs

In the face of these problems

The popover is not limited to the popover itself, it must have the ability to assemble various services to match

Time range management 2. Pop-up window number management 3. Priority setting 4. Display time configuration

PopLayerController is internally maintained with members of the popover business function to accommodate these scenarios

Member PopManager maintains the corresponding popover priority queue to ensure the normal popover process

To sum up, it temporarily meets the current needs. I hope this idea can get your approval

The specific use

You can go to Github: github.com/MrCodeSnipe… I hope I can help you

//add this to your repositories
 maven { url 'https://www.jitpack.io' }

//add this to your dependencies
implementation 'com. Making. MrCodeSniper: PopLayer: 2.0.0'
Copy the code

About popover management

I’m going to treat each popover object as a popover entity in the frame called Popi

It’s the smallest indivisible entity of a description window that has all the properties of a description popover and can be extended as needed

In use, you only need to assemble corresponding business requirements according to your requirements

Popi mUpgradePopi1 = new Popi.Builder()
                .setmPopId(4)// The unique identifier of the popover is treated as a new popover when the ID changes
                .setmPriority(2)// Priority There is no specific division of the corresponding range. A smaller value indicates a higher priority
                .setmCancelType(TRIGGER_CANCEL)// The popover vanish types are TRIGGER_CANCEL COUNTDOWN_CANCEL
                .setMaxShowTimeLength(5)// Maximum display time (S)
                .setMaxShowCount(5)// Maximum display times
                .setmBeginDate(1548858028)// Start time 2019-01-30 22:20:28
                .setmEndDate(1548944428)// End time 2019-01-31 22:20:28
                .setmPopLayerView(mLayerView1)/ / the View window
                .build();
Copy the code

I mentioned before that you can pass in a specific popover policy and create a corresponding popover, which is the policy that you pass in to the Dialog popover in the following section and you can take the unified View object and hand it over to Popi

/ / form Dialog
PopLayerView  mLayerView = new PopLayerView(this,R.layout.common_dialog_upgrade_app);
// Transparent Webview form
PopLayerView mLayerView = new PopLayerView(this,LayerConfig.redPocketScheme);
Copy the code

How to implement popover priority business logic

As mentioned before, member PopManager maintains the corresponding popover priority queue to ensure the normal popover process, and the final show and hide is also after its operation

First, Popi entities implement the Comparable interface to give them the ability to compare sizes by priority

The second is that the internal priority queue does heap sort every time an element is added or removed to adjust the priority of the queue

private  PriorityQueue<Popi> queue;
Copy the code

When Popi joins the team, it will judge whether to join the team by checking whether its Id is repeated

According to the corresponding attributes of the Popi passed in during the display, it is determined whether the Popi is satisfied

1. Be active for a limited time

2. Save the display times of the corresponding popover through SP. Key is Popi and its unique ID to determine whether the display times are beyond the range

3. Add DelayDimiss if the cancellation type is Delayed cancellation

Popover entities that the process cannot exit are removed from the queue

It is also very simple to use

// Add popover management
PopManager.getInstance().pushToQueue(mUpgradePopi);
// Start displaying pop-ups
PopManager.getInstance().showNextPopi();
Copy the code

Results the preview

Current flaws in the framework

There is currently no good way to listen for callbacks to native control disappearance

A dialog like this does not follow our vanish logic when clicked outside the circle

You need to add a listener but that makes the internal logic a little confusing

The current solution is to unify the touch mechanism of popovers into physical and peripheral areas and bring them under our control

With the release of V2, the touch mechanism has been implemented by default with different extensions that are essentially uniform

About the project

V1 scheme

The version number LOG Progress update
V1.0.0 Open source project, complete popover management and Dialog form expansion Dialog policy expansion completed
V1.0.1 Fixed bug where Dialog policy could not get Dialog entities Dialog strategy optimization
V1.0.2 Fixed pop-up bug caused by activity destruction Dialog strategy optimization
V1.0.3 Optimized the use of popover more convenient and fast Optimization of frame usage

V2 scheme

The version number LOG Progress update
V2.0.0 Transparent Webview popover policy extension officially added Transparent Webview policy extension completed

Future plans

The transparent Webview extension has been completed and you can go to it

Android general business popup management scheme V2 to see the relevant effect

Other types of popovers will also be updated in succession, hoping to provide you with a more comprehensive popover management framework to meet business needs

The authors introduce

Hello, my name is Lalala. If you like my article, you can go to my Github and give me a Star. I will be very happy!

Github:github.com/MrCodeSnipe…

–End