：
上上周五的下午，也就是2012.09.07,終於向主管提出了辭職，也下定決心準備返回武漢工作，原因當然 有
很多，在此也不講這「數不清理還亂的」事兒了，讓各位笑話了。
最近，工作倒挺清閒，俗話說「人太閒了，就容易奇思亂想」 ，
這不我也
覺得天馬行空了。於是心裡一直在
嘀咕著，
我腦海裡。
可我腦子不好使，沒有很好地
創意。每次和朋友同事聊天，「有想法，其他都是浮雲」總是會從我的
嘴裡蹦出來，可我只能空口說白話，插科
打諢。呵呵，
我也希望自己能多點創新的點子，說不定那天我也去創業
了呢？ 額，話說大了。還是拉回現實吧。
我只能想啊想，思啊思，偶然間聯想到部落格中之前對應用程式中相關資訊的一系列總結，索性橫下一條心，先
做個簡易的任務管理器吧，所謂「麻雀雖小，五臟俱全」。希望也能在逐步完善這個任務管理器的時候，能夠從中
汲取更多關於編碼、設計以及效率的問題，自己也會隨著這個小東西的完善而逐漸變得強大的。
差不多占用了週末時間以及晚上(我可沒加班)時間，做出來了這個雛形，馬馬虎虎而已。廢話不多說了，見
下文。
1、<
>>
2、<
>
>
3、<
>>
4、關於製作底部導航的相關博文如下：
<<
>>
<
(仿網易客戶端)>>
簡單點來說，就是把我上面列出的4條單獨地個體整理成乙個有機的整體，整體才是有生命、充滿活力的。
功能簡單，程式當然也很簡單。 先上圖：
工程邏輯圖如下：
由於我們用於呈現分類的已安裝程式的activity在介面以及功能上大體一致，因此我們將這部分共性(介面等)
抽取出來形成乙個抽象父類(baseactivity)，基本上所有功能都由這個抽象父類完成了，子類僅僅提供資料物件。
uml圖：
然而，隨著後期新功能的加入以及優化，這種在tabactivity中新增activity的功能已經不能滿足需要，甚至
現有設計本身就是欠缺地，只能在後續中重構改善設計。
缺點主要有二：
1、效率比較低下 ---- 需要同時管理多個activity的生命週期
2、造成了資料之間的過度耦合以及**冗餘 ---- 新增新功能時，發現資料互動之間比較繁雜，例如：新增
乙個對action_package_***的broadcastreceiver時，需要註冊多次，資料互動之間也不很麻煩。
計畫參考android2.3 settings中應用程式功能的實現，採用
tabhost.tabcontentfactory類
為tabactivity提供
檢視，在效能上繼續優化我們的這個小東西 。
baseactivity的部分原始碼如下：
}/**設定ui*/
protected void initui(int resid)
//構建乙個baseadapter介面卡物件，為listview提供資料
//返回該應用程式適合的容器
//查詢系統應用程式資訊並填充到我們的集合中
catch(exception ex)
} }
//根據flag標記分別新增至我們的集合中
//本來是系統程式，被使用者手動更新後，該系統程式也成為第三方應用程式了
} //第三方應用程式
} //安裝在sd卡中的程式
} }
private class pakcagestatechangereceiver extends broadcastreceiver
else
}else // action_package_added
else //更新了應用程式}}
}} }
}其他**就不在貼了，大家有興趣的自行研究咯。
希望大家能提供寶貴意見。 over ~~~~
Flowable 管理應用程式（2）
flowable 6.6.0應用指南 除了部署和定義之外，您還可以在流程引擎中查詢流程例項 任務 作業和事件訂閱。所有檢視的工作方式都與前面描述的類似。這是管理ui應用程式的特定屬性 管理ui應用程式屬性 property name old property default value descri...
docker資料卷管理 管理應用程式資料
volume bind mount 將docker主機資料掛載到容器中 docker提供三種不同的方式將資料從宿主機掛載到容器中 volumes bind mounts和tmpfs volumes docker管理宿主機檔案系統的一部分 var lib docker volumus bind mou...
版本控制 使用Gradle自動管理應用程式版本
versioncode versionname 假設當前版本是這樣的 defaultconfig上面我們說了採用人工的方式去管理應用的版本是比較容易出錯的，所以既然手動管理不行，那麼就採取自動管理的方式去管理吧，而versioncode的作用就是提供乙個int型別的版本標識 用公升級，而每一次rel...