App開發架構指南（谷歌官方文件譯文）
這篇文章面向的是已經掌握app開發基本知識，想知道如何開發健壯app的讀者。
注：本指南假設讀者對 Android Framework 已經很熟悉。如果你還是app開發的新手，請檢視 Getting Started 系列教程，該教程涵蓋了本指南的預備知識。
app開發者面臨的常見問題
跟傳統的桌面應用開發不同，Android app的架構要複雜得多。一個典型的Android app是由多個app 組建構成的，包括activity,Fragment,service,content provider以及broadcast receiver。而傳統的桌面應用往往在一個龐大的單一的程序中就完成了。
大多數的app組建都宣告在app manifest中，Android OS用它來決定如何將你的app與裝置整合形成統一的使用者體驗。雖然就如剛說的，桌面app只執行一個程序，但是一個優秀的Android app卻需要更加靈活，因為使用者操作在不同app之間，不斷的切換流程和任務。
比如，當你要在自己最喜歡的社交網路app中分享一張照片的時候，你可以想象一下會發生什麼。app觸發一個camera intent，然後Android OS啟動一個camera app來處理這一動作。此時使用者已經離開了社交網路的app，但是使用者的操作體驗卻是無縫對接的。而 camera app反過來也可能觸發另一個intent，比如啟動一個檔案選擇器，這可能會再次開啟另一個app。最後使用者回到社交網路app並分享照片。在這期間的任意時刻使用者都可被電話打斷，打完電話之後繼續回來分享照片。
在Android中，這種app並行操作的行為是很常見的，因此你的app必須正確處理這些流程。還要記住移動裝置的資源是有限的，因此任何時候作業系統都有可能殺死某些app，為新執行的app騰出空間。
總的來說就是，你的app組建可能是單獨啟動並且是無序的，而且在任何時候都有可能被系統或者使用者銷燬。因為app組建生命的短暫性以及生命週期的不可控制性，任何資料都不應該把存放在app組建中，同時app組建之間也不應該相互依賴。
通用的架構準則
如果app組建不能存放資料和狀態，那麼app還是可架構的嗎？
最重要的一個原則就是儘量在app中做到separation of concerns（關注點分離）
第二個很重要的準則是用model驅動UI，最好是持久化的model。之所以要持久化是基於兩個原因：如果OS銷燬app釋放資源，使用者資料不會丟失；當網路很差或者斷網的時候app可以繼續工作。Model是負責app資料處理的組建。它們不依賴於View或者app 組建（Activity，Fragment等），因此它們不會受那些組建的生命週期的影響。保持UI程式碼的簡單，於業務邏輯分離可以讓它更易管理。
app架構推薦
注：沒有一種適合所有場景的app編寫方式。也就是說，這裡推薦的架構適合作為大多數使用者案例的開端。但是如果你已經有了一種好的架構，沒有必要再去修改。
假設我們在建立一個顯示使用者簡介的UI。使用者資訊取自我們自己的私有的後端REST API。
建立使用者介面
UI由UserProfileFragment.java以及相應的佈局檔案user_profile_layout.xml組成。
要驅動UI，我們的data model需要持有兩個資料元素。
User ID: 使用者的身份識別。最好使用fragment argument來傳遞這個資料。如果OS殺死了你的程序，這個資料可以被儲存下來，所以app再次啟動的時候id仍是可用的。
User object: 一個持有使用者資訊資料的POJO物件。
我們將建立一個繼承ViewModel類的UserProfileViewModel來儲存這一資訊。
一個ViewModel為特定的UI組建提供資料，比如fragment 或者 activity，並負責和資料處理的業務邏輯部分通訊，比如呼叫其它組建載入資料或者轉發使用者的修改。ViewModel並不知道View的存在，也不會被configuration change影響。
現在我們有了三個檔案。
user_profile.xml: 定義頁面的UI
UserProfileViewModel.java: 為UI準備資料的類
UserProfileFragment.java: 顯示ViewModel中的資料與響應使用者互動的控制器
下面我們開始實現（為簡單起見，省略了佈局檔案）：
public class UserProfileViewModel extends ViewModel {
private String userId;
private User user;
public void init(String userId) {
this.userId = userId;
}
public User getUser() {
return user;
}
}
public class UserProfileFragment extends LifecycleFragment {
private static final String UID_KEY = "uid";
private UserProfileViewModel viewModel;
@Override
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
String userId = getArguments().getString(UID_KEY);
viewModel = ViewModelProviders.of(this).get(UserProfileViewModel.class);
viewModel.init(userId);
}
@Override
public View onCreateView(LayoutInflater inflater,
@Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
return inflater.inflate(R.layout.user_profile, container, false);
}
}
注：上面的例子中繼承的是LifecycleFragment而不是Fragment類。等Architecture Component中的lifecycles API穩定之後，Android Support Library中的Fragment類也將實現LifecycleOwner。
現在我們有了這些程式碼模組，如何連線它們呢？畢竟當ViewModel的user成員設定之後，我們還需要把它顯示到介面上。這就要用到LiveData了。
LiveData是一個可觀察的資料持有者。 無需明確在它與app組建之間建立依賴就可以觀察LiveData物件的變化。LiveData還考慮了app組建(activities, fragments, services)的生命週期狀態，做了防止物件洩漏的事情。
注：如果你已經在使用RxJava或者Agera這樣的庫，你可以繼續使用它們，而不使用LiveData。但是使用它們的時候要確保正確的處理生命週期的問題，與之相關的LifecycleOwner stopped的時候資料流要停止，LifecycleOwner destroyed的時候資料流也要銷燬。你也可以使用android.arch.lifecycle:reactivestreams讓LiveData和其它的響應式資料流庫一起使用(比如, RxJava2)。
現在我們把UserProfileViewModel中的User成員替換成LiveData，這樣當資料發生變化的時候fragment就會接到通知。LiveData的妙處在於它是有生命週期意識的，當它不再被需要的時候會自動清理引用。
public class UserProfileViewModel extends ViewModel {
...
private User user;
private LiveData<User> user;
public LiveData<User> getUser() {
return user;
}
}現在我們修改UserProfileFragment，讓它觀察資料並更新UI。
@Override
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
viewModel.getUser().observe(this, user -> {
// update UI
});
}
每當User資料更新的時候 onChanged 回撥將被觸發，然後重新整理UI。
如果你熟悉其它library的observable callback的用法，你會意識到我們不需要重寫fragment的onStop()方法停止對資料的觀察。因為LiveData是有生命週期意識的，也就是說除非fragment處於活動狀態，否則callback不會觸發。LiveData還可以在fragmentonDestroy()的時候自動移除observer。
對我們也沒有做任何特殊的操作來處理 configuration changes（比如旋轉螢幕）。ViewModel可以在configuration change的時候自動儲存下來，一旦新的fragment進入生命週期，它將收到相同的ViewModel例項，並且攜帶當前資料的callback將立即被呼叫。這就是為什麼ViewModel不應該直接引用任何View，它們遊離在View的生命週期之外。參見ViewModel的生命週期。
獲取資料
現在我們把ViewModel和fragment聯絡了起來，但是ViewModel該如何獲取資料呢？在我們的例子中，假設後端提供一個REST API，我們使用Retrofit從後端提取資料。你也可以使用任何其它的library來達到相同的目的。
下面是和後端互動的retrofit Webservice：
public interface Webservice {
/**
* @GET declares an HTTP GET request
* @Path("user") annotation on the userId parameter marks it as a
* replacement for the {user} placeholder in the @GET path
*/
@GET("/users/{user}")
Call<User> getUser(@Path("user") String userId);
}
ViewModel的一個簡單的實現方式是直接呼叫Webservice獲取資料，然後把它賦值給User物件。雖然這樣可行，但是隨著app的增大會變得難以維護。ViewModel的職責過多也違背了前面提到的關注點分離（separation of concerns）原則。另外，ViewModel的有效時間是和Activity和Fragment的生命週期繫結的，因此當它的生命週期結束便丟失所有資料是一種不好的使用者體驗。相反，我們的ViewModel將把這個工作代理給Repository模組。
Repository模組負責處理資料方面的操作。它們為app提供一個簡潔的API。它們知道從哪裡得到資料以及資料更新的時候呼叫什麼API。你可以把它們看成是不同資料來源（persistent model, web service, cache, 等等）之間的媒介。
下面的UserRepository類使用了WebService來獲取使用者資料。
public class UserRepository {
private Webservice webservice;
// ...
public LiveData<User> getUser(int userId) {
// This is not an optimal implementation, we'll fix it below
final MutableLiveData<User> data = new MutableLiveData<>();
webservice.getUser(userId).enqueue(new Callback<User>() {
@Override
public void onResponse(Call<User> call, Response<User> response) {
// error case is left out for brevity
data.setValue(response.body());
}
});
return data;
}
}雖然repository模組看起來沒什麼必要，但它其實演扮演著重要的角色；它把資料來源從app中抽象出來。現在我們的ViewModel並不知道資料是由Webservice提供的，意味著有必要的話可以替換成其它的實現方式。
管理不同組建間的依賴：
前面的UserRepository類需要Webservice的例項才能完成它的工作。可以直接建立它就是了，但是為此我們還需要知道Webservice所依賴的東西才能構建它。這顯著的增減了程式碼的複雜度和偶合度（比如，每個需要Webservice例項的類都需要知道如何用它的依賴去構建它）。另外，UserRepository很可能不是唯一需要Webservice的類。如果每個類都建立一個新的WebService，就變得很重了。
有兩種模式可以解決這個問題：
依賴注入: 依賴注入允許類在無需構造依賴的情況下定義自己的依賴物件。在執行時由另一個類來負責提供這些依賴。在Android app中我們推薦使用谷歌的Dagger 2來實現依賴注入。Dagger 2 通過遍歷依賴樹自動構建物件，並提供編譯時的依賴。
Service Locator：Service Locator 提供一個registry，類可以從這裡得到它們的依賴而不是構建它們。相對依賴注入來說要簡單些，所以如果你對依賴注入不熟悉，可以使用 Service Locator 。
這些模式允許你擴充套件自己的程式碼，因為它們提供了清晰的模式來管理依賴，而不是不斷的重複程式碼。兩者均支援替換成mock依賴來測試，這也是使用它們主要優勢之一。
在這個例子中，我們將使用 Dagger 2 來管理依賴。
連線ViewModel和repository
現在我們修改UserProfileViewModel以使用repository。
public class UserProfileViewModel extends ViewModel {
private LiveData<User> user;
private UserRepository userRepo;
@Inject // UserRepository parameter is provided by Dagger 2
public UserProfileViewModel(UserRepository userRepo) {
this.userRepo = userRepo;
}
public void init(String userId) {
if (this.user != null) {
// ViewModel is created per Fragment so
// we know the userId won't change
return;
}
user = userRepo.getUser(userId);
}
public LiveData<User> getUser() {
return this.user;
}
}快取資料
上面的repository對抽象web service呼叫是很好的，但是因為它只依賴於一個數據源，並不是非常實用。
UserRepository的問題在於當獲取完資料之後，它並沒有把資料儲存下來。如果使用者離開UserProfileFragment然後在回來，app會重新獲取資料。這是很不好的，原因有二：1.浪費了頻寬資源，2.使用者被迫等待新的查詢完成。為了解決這個問題，我們向UserRepository中添加了一個新的資料來源，它將把User物件快取到記憶體中。
@Singleton // informs Dagger that this class should be constructed once
public class UserRepository {
private Webservice webservice;
// simple in memory cache, details omitted for brevity
private UserCache userCache;
public LiveData<User> getUser(String userId) {
LiveData<User> cached = userCache.get(userId);
if (cached != null) {
return cached;
}
final MutableLiveData<User> data = new MutableLiveData<>();
userCache.put(userId, data);
// this is still suboptimal but better than before.
// a complete implementation must also handle the error cases.
webservice.getUser(userId).enqueue(new Callback<User>() {
@Override
public void onResponse(Call<User> call, Response<User> response) {
data.setValue(response.body());
}
});
return data;
}
}持久化資料
目前的實現中，如果使用者旋轉螢幕或者是離開之後再次回到app，UI將立即可見，因為repository是從常駐記憶體的快取中獲取的資料。但是如果使用者離開了app，幾個小時之後再回來時程序已經被殺死了怎麼辦呢？
以目前的實現來看，我們需要再次從網路獲取資料。這不僅僅是糟糕的使用者體驗，還是一種浪費，因為它需要花費移動流量獲取相同的資料。你可以直接快取web請求，但是這又產生了新的問題。如果同樣的user資料來自於另一個型別的請求呢（比如獲取一個朋友的列表）？那樣的話你的app很可能會顯示不一致的資料，這是一種困惑的使用者體驗。例如，因為朋友列表請求與使用者請求可能在不同的時間執行，同一使用者的資料可能會不一致。你的app需要融合它們以避免資料出現不一致。
處理這個問題的正確方式是使用持久化的model。持久化庫Room就是為此而生。
Room是一個物件關係對映庫，以最少的程式碼提供本地資料持久化功能。它在編譯時驗證每個查詢，所以損壞的SQL查詢只會導致編譯時錯誤而不是執行時崩潰。Room抽象了部分SQL查詢與表的相關操作的底層細節。它還可以讓你通過一個LiveData物件監聽到資料庫資料的變化。另外，它還明確定義了執行緒約束，解決了諸如從主執行緒獲取儲存這樣的常見的問題。
注：如果熟悉其它的持久化方案比如SQLite ORM或者是一個不同的資料庫，如Realm，你不需要把它替換成Room，除非Room的特性對你的用例而言更加重要。
要使用Room，我們需要定義本地的schema。首先使用@Entity註解User類，將它標記為資料庫中的一張表。
@Entity
class User {
@PrimaryKey
private int id;
private String name;
private String lastName;
// getters and setters for fields
}
然後通過繼承RoomDatabase建立一個database類：
@Database(entities = {User.class}, version = 1)
public abstract class MyDatabase extends RoomDatabase {
}
注意MyDatabase是抽象類。Room根據它自動提供一個實現。詳細情況參見Room文件。
@Dao
public interface UserDao {
@Insert(onConflict = REPLACE)
void save(User user);
@Query("SELECT * FROM user WHERE id = :userId")
LiveData<User> load(String userId);
}然後，在database類中引用DAO。
@Database(entities = {User.class}, version = 1)
public abstract class MyDatabase extends RoomDatabase {
public abstract UserDao userDao();
}
注意load方法返回的是LiveData。Room知道database什麼時候被修改過，當資料變化的時候，它將自動通知所有處於活動狀態的observer。
注：對於alpha 1 版本，Room是根據表的修改檢查驗證，因此可能會發送錯誤的訊號。
現在我們可以修改UserRepository以和Room協同工作。
@Singleton
public class UserRepository {
private final Webservice webservice;
private final UserDao userDao;
private final Executor executor;
@Inject
public UserRepository(Webservice webservice, UserDao userDao, Executor executor) {
this.webservice = webservice;
this.userDao = userDao;
this.executor = executor;
}
public LiveData<User> getUser(String userId) {
refreshUser(userId);
// return a LiveData directly from the database.
return userDao.load(userId);
}
private void refreshUser(final String userId) {
executor.execute(() -> {
相關推薦
App開發架構指南（谷歌官方文件譯文）
這篇文章面向的是已經掌握app開發基本知識，想知道如何開發健壯app的讀者。
注：本指南假設讀者對 Android Framework 已經很熟悉。如果你還是app開發的新手，請檢視 Getting
Started 系列教程，該教程涵蓋了本指南的預備知識。
ap
HDFS架構指南（Hadoop官方文件翻譯）
HDFS架構指南
本文翻譯自《HDFS Architecture Guide》
來源於Apache開源社群的Hadoop Apache Project
文獻引用為：
Borthakur D. HDFS architecture guide[J]. Hadoop
Spring Framework 4.0 遷移指南 （官方文件翻譯）
看到Spring Framework4.0釋出的訊息，看了下new future，OneCoder很喜歡spring這種追“時髦”的風格，groovy指令碼配置和Java8都支援了。順便就翻譯了一下官方的遷移指南。對一般使用來說，遷移沒什麼難度。
使用Google Chrome Frame（谷歌瀏覽器內嵌框架）解決低版本IE不相容問題
對於web開發最頭疼的當然是相容性問題，尤其是相容IE8以下版本，很多的便捷的新功能就都用不了，為了解決這類的問題我總結了兩種比較好的方法。
使用條件註釋
使用條件註釋加script標籤選擇IE版本小於9的瀏覽器自動立即跳轉
<!--
MongoDB內建角色詳解（翻譯自官方文件）
1 資料庫使用者角色
每個資料庫都包含下列的角色：
read : 提供讀取所有的非系統集合的能力，也能讀取以下系統集合：system.indexes,system.js,system.namespacesreadWrite:提供所有讀許可權另外還能修改非系統集合和system.js集合
（官方文件中文版）Windows環境下安裝RabbitMQ
安裝RabbitMQ
本文按照官方文件按步驟詳細解讀，廢話不多說，下面介紹Windows下安裝RabbitMQ全過程，之後介紹RabbitMQ快速入門。
RabbitMQ是Erlang語言編寫的，所以安裝RabbitMQ需要分為兩步，安裝Erlang
MyBatis 註解（摘自MyBatis官方文件）
註解
目標
相對應的 XML
描述
@CacheNamespace
類
<cache>
為給定的名稱空間 (比如類) 配置快取。
屬性:implemetation,evictio
ubuntu 系統安裝配置搭建jenkins（官方文件小結）
On Debian-based distributions, such as Ubuntu, you can install Jenkins through apt-get.
使用apt方式在給予debian的linux發行版上搭建jenkins；
Recen
十分鐘掌握pandas（pandas官方文件翻譯）
十分鐘掌握pandas
文件版本：0.20.3
這是一個對pandas簡短的介紹，適合新使用者。你可以在Cookbook中檢視更詳細的內容。 通常，我們要像下面一樣匯入一些包。
In [1]: import pandas as pd
In [2]: import numpy as np
I
使用Android Studio進行NDK開發和除錯(gradle-experimental之官方文件的翻譯說明)
版本更新
環境要求
Gradle（參照三裡邊的版本要求）
Android NDK r10e
Build Tool在19.0.0以上的SDK
Gradle版本要求
不同版本的Experimental Plugin需要不同版本的gradle
HBase資料庫與關係型資料庫的區別（取材於官方文件）
HBase 資料被建模為多維對映，其中值（表單元）通過 4 個鍵索引：
value = Map(TableName, RowKey, ColumnKey, Timestamp)
其中：
TableName 是一個字串。 是表名。
RowKey 和 ColumnKey 是
ES聚合原理：（來源自官方文件）
聚合原理：（來源自官方文件）
大多數字段預設為索引，這使得它們可以搜尋。 但是，排序，聚合和訪問指令碼中的欄位值需要與搜尋不同的訪問模式。
搜尋需要回答“哪些文件包含此術語？”的問題，而排序和聚合需要回答一個不同的問題：“本文對這個文件有什麼價值？”。
大多
vSFTP（配置多用戶文件共享）
linuxvsftp企業需求要求：1、每個部門對應一個共享的FTP目錄。共有部門：財務部、行政部、技術部。2、每個部門對應一個FTP用戶。3、不允許通過匿名訪問。搭建步驟一、安裝VSFTP# yum -y install vsftpd （安裝VSFTP二、修改配置
RecyclerView API官方文件譯文
RecyclerView
added in version 22.1.0
belongs to Maven artifact
com.android.support:recyclerview-v7:27.0.0
繼承關係
已
SpringBoot 三種方式配置 Druid（包括純配置文件配置）
tor clu 分享 mys dep imp 沒有 context 密碼 記錄一下在項目中用純 YML（application.yml 或者 application.properties）文件、Java 代碼配置 Bean 和註解三種方式配置 Alibaba Druid 用
PEP 484 型別提示 -- Python官方文件譯文 [原創]
英文原文：https://www.python.org/dev/peps/pep-0484/
採集日期：2019-12-27
PEP 484 -- 型別提示（Type Hints）
PEP: 484
Title: Type Hints
Author: Guido van Rossum <guido
PEP 443 單分派泛型函式 -- Python官方文件譯文 [原創]
# PEP 443 -- 單分派泛型函式（Single-dispatch generic functions）
> 英文原文：[https://www.python.org/dev/peps/pep-0443](https://www.python.org/dev/peps/pep-0443/)
> 採
JApiDocs（自動生成介面文件神器）
# JApiDocs教程
## 前言
- 作為一名優秀的程式設計師來說，由於涉及到要與前端進行對接，所以避免不了的就是寫介面文件。寫完介面文件，一旦程式碼返回結果，引數等出現變動，介面文件還得隨之改動，十分麻煩，違背了我們簡單，快速，低bug的開發初衷。
- 所以，自動生成介面文件的工具就出現了
Daphile 安裝手冊 -- 官方文件譯文 [原創]
# Daphile 安裝手冊（Daphile Installation）
> 英文原文：[https://www.daphile.com/download/DaphileInstallation.pdf](https://www.daphile.com/download/DaphileInstallatio
GCM(谷歌雲推送)客戶端伺服器端開發全指南（伺服器篇）
由於谷歌雲推送GCM升級成為FCM，所以此部落格能容僅供參考 ————2016.12.2更新
今天我們按照之前所說的步驟介紹GCM雲推送服務端的開發，因為服務端的開發比客戶端的開發較簡單，遵從由易到難，一步一步攻破的原則，所以我先於客戶端講服務端的開發，話不多