自從發佈Poplayer以來期間完善了一版以後,已經有一個月沒有更新了,期間在寫着業務代碼的同時涌出許多想法,每一個想法若是衍生出框架,均可以極大的下降平常的工做成本而且幫助理清業務的流程,想法越多要作的事情也愈來愈多,java
在不一樣的框架實現中不斷遊走, 做爲程序員,天天除了工做還得保證兩個小時的學習時間 其間我的工做也到達了項目衝刺區基本上週六週日也是開乾的節奏 ,剩下沒有多少時間來爲框架添磚加瓦,實在是有點疏忽了,也深深以爲維護一個框架或者從頭編寫一個框架的不易,實在感謝那麼多的大佬爲開源作的貢獻,一塊兒共勉git
進入正題 Poplayer第三版的靈感來自於項目中早就發現的一個現象 也感謝以前文章評論留言的同窗提出的這個問題 程序員
如今回想這個需求 對於以前的回覆實際上是有些牽強的github
由於咱們沒有辦法預測多個網絡請求結束的公共時間節點(除非定義一個固定的時間點),這個問題在以後也想了一些時間,考慮到須要統籌各個項目的網絡框架就不了了之網絡
但如今想來 咱們只須要將這個過程理清,統籌邏輯並不必定要適配某某網絡框架,給用戶提供調度的接口便可再在其上添加主流網絡框架的支持 也不失一種解決辦法框架
在發佈V3以前,Poplayer在我眼裏的定義是彈窗的統一管理 包括優先級 顯示時間範圍 顯示倒計時 顯示次數等等 但在V3以後它不只是能夠統籌彈窗內部屬性的框架 它也是能夠統籌外部網絡通訊的業務邏輯 也能夠自定義適合自身業務的彈窗顯示邏輯的流程控制框架post
Android業務中的網絡請求方式各類各樣 但結果是不變的學習
能夠總結爲:成功或失敗(須要顯示彈窗或者不須要)測試
因此咱們須要定義一個任務類型粒度的對象 它具有基礎的優先級屬性 根據優先級來控制流程優化
咱們的每一次網絡請求能夠當作一個Task,它對應着其結果須要顯示的彈窗Popi
有了Task固然須要一個管理者去管理業務中繁瑣的步驟, TaskManager所以而生其內置了Poplayer的支持保證了在業務流程中 也能使用咱們的Poplayer實現的效果 (它包括Dialog,透明Webview等)
因爲Task規定了流程的前後順序 因此在低優先級任務執行成功後顯示的彈窗 須要進行預留因此咱們須要一個預留彈窗隊列保證彈窗顯示不會亂序ReServePriorityQueue
最後爲了支持主流的回調框架Rxjava在時間和空間上的統籌 增長了其上包含通用邏輯的PopRxSubscriber 用戶能夠繼承進行自定義擴展
上圖是以APP開發中最多見的版本更新和公告彈窗的數據交互與顯示流程爲例的邏輯圖
它分爲兩個部分 分別是引入流程控制先後的邏輯順序咱們能夠清晰的發現二者的區別
一般流程下咱們必須在每一個流程的中介點進行數據產出和UI生成的操做 在框架的幫助下 咱們只須要考慮產生UI 具體的邏輯由事先訂好的規則由任務管理器幫咱們處理
基礎使用
//建立網絡請求任務
Task taskUpdate=new Task();
//新建Poplayer彈窗
PopLayerView mLayerView1 = new PopLayerView(this,LayerConfig.dialog5);
Popi downloadPop = new Popi.Builder()
.setmPopId(30)
.setmPriority(6)
.setmCancelType(TRIGGER_CANCEL)
.setLayerView(mLayerView1)
.build();
//加入任務管理
TaskManager.getInstance(this).pushToQueue(taskUpdate,mUpgradePopi)
複製代碼
自定義回調
TaskManager.getInstance(this).onTaskGoOn(taskNotice);//回調成功
TaskManager.getInstance(this).onTaskInterupt(taskUpdate);//回調失敗
複製代碼
若是您使用的是Rxjava實現回調能夠繼承框架中自帶回調邏輯的PopRxSubscriber
public class MySubscriber extends PopRxSubscriber {
public MySubscriber(Context mContext, Task task) {
super(mContext, task);
}
}
複製代碼
優勢:就代碼而言 能解決一個接口有多處調用點的問題 彈窗邏輯上的顯示由優先級判斷,而且解決了網絡邏輯業務沒法使用Poplayer彈窗效果的問題
缺點: 摒棄了某些接口的懶加載特性
發佈v3以前我也很懷疑 這個問題是否有解決辦法 是否須要花費太多的時間 因此一直猶豫要不要在有限的時間來作這個東西,但其實只要將複雜問題分解下 逐個擊破其實並無想象的那麼難纏
第一步 將其中涉及的關鍵成員都整理起來 闡明對應的職責 用代碼實現出一個大概
第二步 將複雜的問題 最小化具象化 將邏輯寫下來 根據邏輯和成員類寫測試代碼
第三步 考慮N+1種可能 將簡單問題進行N種可能的適用化 並逐步用在小範圍的業務代碼上
POPLAYER
Android通用彈窗管理框架,支持網絡回調業務邏輯彈窗,內部維護彈窗優先級隊列 具有彈窗管理擴展功能 整合Dialog,PoupoWindow,懸浮Widget,透明Webview,Toast,SnackBar,無需再爲繁瑣的業務彈窗邏輯所困擾
具體如何使用 能夠去github.com/MrCodeSnipe…閱讀下面的使用說明文檔
您也能夠下載Demo體驗一番 若有問題 能夠在Github上打開Issue 我會第一時間回覆
若是你對往期版本感興趣 歡迎前往 觀看 別忘了點個贊喲!
版本號 | LOG | 進度更新 |
---|---|---|
V1.0.0 | 項目開源,完成彈窗管理與Dialog形式擴展 | Dialog策略擴展完成 |
V1.0.1 | 修復Dialog策略沒法獲取dialog實體bug | Dialog策略優化 |
V1.0.2 | 修復activity摧毀形成的彈窗異常 bug | Dialog策略優化 |
V1.0.3 | 優化了彈窗的使用更加方便快捷 | 框架使用優化 |
版本號 | LOG | 進度更新 |
---|---|---|
V2.0.0 | 正式加入透明Webview彈窗策略擴展 | 透明Webview策略擴展完成 |
版本號 | LOG | 進度更新 |
---|---|---|
V3.0.0 | 引入流程任務管理模塊 | 解決涉及網絡的業務邏輯彈窗 |
Hello 我叫lalala,若是您喜歡個人文章,能夠去個人Github給個Star我就很開心啦!!!
Github:github.com/MrCodeSnipe…
--End