App開發：模擬服務器數據接口 - MockApi

時間  2019-11-29
標籤 app 開發 模擬 服務器 數據接口 mockapi 简体版
原文   原文鏈接

轉載：http://blog.csdn.net/hj7jay/article/details/54860866java

爲了方便app開發過程當中，不受服務器接口的限制，便於客戶端功能的快速測試，能夠在客戶端實現一個模擬服務器數據接口的MockApi模塊。本篇文章就嘗試爲使用gradle的android項目設計實現MockApi。android

需求概述

在app開發過程當中，在和服務器人員協做時，通常會第一時間肯定數據接口的請求參數和返回數據格式，而後服務器人員會盡快提供給客戶端可調試的假數據接口。不過有時候就算是假數據接口也來不及提供，或者是接口數據格式來回變更——極可能是客戶端展現的緣由，這個是產品設計決定的，總之帶來的問題就算服務器端的開發進度會影響客戶端。算法

因此，若是能夠在客戶端的正常項目代碼中，天然地（不影響最終apk）添加一種模擬服務器數據返回的功能，這樣就能夠很方便的在不依賴服務器的狀況下展開客戶端的開發。並且考慮一種狀況，爲了測試不一樣網絡速度，網絡異常以及服務器錯誤等各類「可能的真實數據請求的場景」對客戶端UI交互的影響，咱們每每須要作不少手動測試——千篇一概！若是本地有一種控制這種服務器響應行爲的能力那真是太好了。json

本文將介紹一種爲客戶端項目增長模擬數據接口功能的方式，但願能減小一些開發中的煩惱。api

設計過程

下面從分層設計、可開關模擬模塊、不一樣網絡請求結果的製造這幾個方面來闡述下模擬接口模塊的設計。
爲了表達方便，這裏要實現的功能表示爲「數據接口模擬模塊」，對應英文爲MockDataApi，或簡寫爲MockApi，正常的數據接口模塊定義爲DataApi。服務器

分層思想

說到分層設計，MVC、MVP等模式必定程度上就起到了對代碼所屬功能的一個劃分。分層設計簡單的目標就是讓項目代碼更加清晰，各層相互獨立，好處很少說。網絡

移動app的邏輯主要就是交互邏輯，而後須要和服務器溝通數據。因此最簡單的情形下能夠將一個功能（好比一個列表界面）的實現分UI層和數據訪問層。app

下面將數據訪問層表述爲DataApi模塊，DataApi層會定義一系列的接口來描述不一樣類別的數據訪問請求。UI層使用這些接口來獲取數據，而具體的數據訪問實現類就能夠在不修改UI層代碼的狀況下進行替換。框架

例如，有一個ITaskApi定義了方法List<Task> getTasks()，UI層一個界面展現任務列表，那麼它使用ITaskApi來獲取數據，而具體ITaskApi的實現類能夠由DataApi層的一個工廠類DataApiManager來統一提供。異步

有了上面的分層設計，就能夠爲UI層動態提供真實數據接口或模擬數據接口。

模擬接口的開關

可能你們都經歷過在UI層代碼裏臨時寫一些假數據得狀況。好比任務列表界面，開發初，能夠寫一個mockTaskData()方法來返回一個List<Task>。但這種代碼只能是開發階段有，最終apk不該該存在。

不能讓「模擬數據」的代碼處處散亂，在分層設計的方式下，能夠將真實的數據接口DataApi和模擬數據接口MockDataApi分別做爲兩個數據接口的實現模塊，這樣就能夠根據項目的構建類型來動態提供不一樣的數據接口實現。

實現MockDataApi的動態提供的方法也不止一種。
通常的java項目可使用「工廠模式+反射」來動態提供不一樣的接口實現類，再專業點就是依賴注入——DI框架的使用了。
目前gradle是java的最早進的構建工具，它支持根據buildType來分別指定不一樣的代碼資源，或不一樣的依賴。
能夠在一個單獨的類庫module（就是maven中的項目）中來編寫各類MockDataApi的實現類，而後主app module在debug構建時添加對它的依賴，此時數據接口的提供者DataApiManager能夠向UI層返回這些mock類型的實例。

爲了讓「正常邏輯代碼」和mock相關代碼的關聯儘可能少，能夠提供一個MockApiManager來惟一獲取各個MockDataApi的實例。而後在debug構建下的MockApiManager會返回提供了mock實現的數據接口實例，而release構建時MockApiManager會一概返null。

不一樣請求結果的模擬

MockApi在屢次請求時提供不一樣的網絡請求結果，如服務器錯誤，網絡錯誤，成功等，並模擬出必定的網絡延遲，這樣就很好的知足了UI層代碼的各類測試需求。

爲了達到上述目標，定義一個接口IMockApiStrategy來表示對數據請求的響應策略，它定義了方法onResponse(int callCount)。根據當前請求的次數callCount，onResponse()會獲得不一樣的模擬響應結果。很明顯，能夠根據測試須要提供不一樣的請求響應策略，好比不斷返回成功請求，或者不斷返回錯誤請求，或輪流返回成功和錯誤等。

關鍵代碼解析

下面就給出各個部分的關鍵代碼，來講明以上所描述的MockDataApi模塊的實現。

UI層代碼

做爲示例，界面MainActivity是一個「任務列表」的展現。任務由Task類表示：

[java]  view plain  copy
 
  1. public class Task {  
  2.   public String name;  
  3. }  

 

界面MainActivity使用一個TextView來顯示「加載中、任務列表、網絡錯誤」等效果，並提供一個Button來點擊刷新數據。代碼以下：

[java]  view plain  copy
 
  1. public class MainActivity extends Activity {  
  2.     private TextView tv_data;  
  3.     private boolean requesting = false;  
  4.   
  5.     @Override  
  6.     protected void onCreate(Bundle savedInstanceState) {  
  7.         super.onCreate(savedInstanceState);  
  8.         setContentView(R.layout.activity_main);  
  9.   
  10.         tv_data = (TextView) findViewById(R.id.tv_data);  
  11.   
  12.         getData();  
  13.     }  
  14.   
  15.     private void getData() {  
  16.         if (requesting) return;  
  17.         requesting = true;  
  18.   
  19.         ITaskApi api = DataApiManager.ofTask();  
  20.         if (api != null) {  
  21.             api.getTasks(new DataApiCallback<List<Task>>() {  
  22.                 @Override  
  23.                 public void onSuccess(List<Task> data) {  
  24.                     // 顯示數據  
  25.                     StringBuilder sb = new StringBuilder("請求數據成功：\n");  
  26.                     for (int i = 0; i < data.size(); i++) {  
  27.                         sb.append(data.get(i).name).append("\n");  
  28.                     }  
  29.   
  30.                     tv_data.setText(sb.toString());  
  31.                     requesting = false;  
  32.                 }  
  33.   
  34.                 @Override  
  35.                 public void onError(Throwable e) {  
  36.                     // 顯示錯誤  
  37.                     tv_data.setText("錯誤：\n" + e.getMessage());  
  38.                     requesting = false;  
  39.                 }  
  40.   
  41.                 @Override  
  42.                 public void onStart() {  
  43.                     // 顯示loading  
  44.                     tv_data.setText("正在加載...");  
  45.                 }  
  46.             });  
  47.         }  
  48.     }  
  49.   
  50.     public void onRefreshClick(View view) {  
  51.         getData();  
  52.     }  
  53. }  

 

在UI層代碼中，使用DataApiManager.ofTask()得到數據訪問接口的實例。
考慮到數據請求會是耗時的異步操做，這裏每一個數據接口方法接收一個DataApiCallback<T> 回調對象，T是將返回的數據類型。

[java]  view plain  copy
 
  1. public interface DataApiCallback<T>  {  
  2.   
  3.     void onSuccess(T data);  
  4.   
  5.     void onError(Throwable e);  
  6.   
  7.     void onStart();  
  8. }  

 

接口DataApiCallback定義了數據接口請求數據開始和結束時的通知。

DataApiManager

根據分層設計，UI層和數據訪問層之間的通訊就是基於DataApi接口的，每一個DataApi接口提供一組相關數據的獲取方法。獲取Task數據的接口就是ITaskApi：

[java]  view plain  copy
 
  1. public interface ITaskApi {  
  2.     void getTasks(DataApiCallback<List<Task>> callback);  
  3. }  

 

UI層經過DataApiManager來得到各個DataApi接口的實例。也就是在這裏，會根據當前項目構建是debug仍是release來選擇性提供MockApi或最終的DataApi。

[java]  view plain  copy
 
  1. public class DataApiManager {  
  2.     private static final boolean MOCK_ENABLE = BuildConfig.DEBUG;  
  3.   
  4.     public static ITaskApi ofTask() {  
  5.         if (MOCK_ENABLE) {  
  6.             ITaskApi api = MockApiManager.getMockApi(ITaskApi.class);  
  7.             if (api != null) return api;  
  8.         }  
  9.   
  10.         return new NetTaskApi();  
  11.     }  
  12. }  

 

當MOCK_ENABLE爲true時，會去MockApiManager檢索一個所需接口的mock實例，若是沒找到，會返回真實的數據接口的實現，上面的NetTaskApi就是。假若如今服務器還沒法進行聯合調試，它的實現就簡單的返回一個服務器錯誤：

[java]  view plain  copy
 
  1. public class NetTaskApi implements ITaskApi {  
  2.     @Override  
  3.     public void getTasks(DataApiCallback<List<Task>> callback) {  
  4.         // 暫時沒用實際的數據接口實現  
  5.         callback.onError(new Exception("數據接口未實現"));  
  6.     }  
  7. }  

 

MockApiManager

DataApiManager利用MockApiManager來獲取數據接口的mock實例。這樣的好處是模擬數據接口的相關類型都被「封閉」起來，僅經過一個惟一類型來獲取已知的DataApi的一種（這裏就指mock）實例。這樣爲分離出mock相關代碼打下了基礎。

在DataApiManager中，獲取數據接口實例時會根據開關變量MOCK_ENABLE判斷是否能夠返回mock實例。僅從功能上看是知足動態提供MockApi的要求了。不過，爲了讓最終release構建的apk中不包含多餘的mock相關的代碼，能夠利用gradle提供的buildVariant。

  • buildVariant
    使用gradle來構建項目時，能夠指定不一樣的buildType，默認會有debug和release兩個「構建類型」。此外，還能夠提供productFlavors來提供不一樣的「產品類型」，如demo版，專業版等。
    每一種productFlavor和一個buildType組成一個buildVariant（構建變種）。
    能夠爲每個buildType，buildVariant，或productFlavor指定特定的代碼資源。

這裏利用buildType來爲debug和release構建分別指定不一樣的MockApiManager類的實現。

默認的項目代碼是在src/main/java/目錄下，建立目錄/src/debug/java/來放置只在debug構建時編譯的代碼。在/src/release/java/目錄下放置只在release構建時編譯的代碼。

  • debug構建時的MockApiManager
    [java]  view plain  copy
     
    1. public class MockApiManager {  
    2.     private static final MockApiManager INSTANCE = new MockApiManager();  
    3.     private HashMap<String, BaseMockApi> mockApis;  
    4.   
    5.     private MockApiManager() {}  
    6.   
    7.     public static <T> T getMockApi(Class<T> dataApiClass) {  
    8.         if (dataApiClass == null) return null;  
    9.   
    10.         String key = dataApiClass.getName();  
    11.   
    12.         try {  
    13.             T mock = (T) getInstance().mockApis.get(key);  
    14.             return mock;  
    15.         } catch (Exception e) {  
    16.             return null;  
    17.         }  
    18.     }  
    19.   
    20.     private void initApiTable() {  
    21.         mockApis = new HashMap<>();  
    22.         mockApis.put(ITaskApi.class.getName(), new MockTaskApi());  
    23.     }  
    24.   
    25.     private static MockApiManager getInstance() {  
    26.         if (INSTANCE.mockApis == null) {  
    27.             synchronized (MockApiManager.class) {  
    28.                 if (INSTANCE.mockApis == null) {  
    29.                     INSTANCE.initApiTable();  
    30.                 }  
    31.             }  
    32.         }  
    33.   
    34.         return INSTANCE;  
    35.     }  
    36. }  

靜態方法getMockApi()根據傳遞的接口類型信息從mockApis中獲取可能的mock實例，mockApis中註冊了須要mock的那些接口的實現類對象。

  • release構建時的MockApiManager
    [java]  view plain  copy
     
    1. public class MockApiManager {  
    2.   
    3.     public static <T> T getMockApi(Class<T> dataApiClass) {  
    4.         return null;  
    5.     }     
    6. }  

由於最終release構建時是不須要任何mock接口的，因此此時getMockApi()一概返回null。也沒有任何和提供mock接口相關的類型。

經過爲debug和release構建提供不一樣的MockApiManager代碼，就完全實現了MockApi代碼的動態添加和移除。

MockApi的實現

模擬數據接口的思路很是簡單：根據請求的次數callCount，運行必定的策略來不斷地返回不一樣的響應結果。
響應結果包括「網絡錯誤、服務器錯誤、成功」三種狀態，並且還提供必定的網絡時間延遲的模擬。

IMockApiStrategy

接口IMockApiStrategy的做用就是抽象對請求返回不一樣響應結果的策略，響應結果由IMockApiStrategy.Response表示。

[java]  view plain  copy
 
  1. public interface IMockApiStrategy {  
  2.     void onResponse(int callCount, Response out);  
  3.   
  4.     /** 
  5.      * Mock響應返回結果，表示響應的狀態 
  6.      */  
  7.     class Response {  
  8.         public static final int STATE_NETWORK_ERROR = 1;  
  9.         public static final int STATE_SERVER_ERROR = 2;  
  10.         public static final int STATE_SUCCESS = 3;  
  11.   
  12.         public int state = STATE_SUCCESS;  
  13.         public int delayMillis = 600;  
  14.     }  
  15. }  

 

Response表示的響應結果包含結果狀態和延遲時間。

做爲一個默認的實現，WheelApiStrategy類根據請求次數，不斷返回上述的三種結果：

[java]  view plain  copy
 
  1. public class WheelApiStrategy implements IMockApiStrategy {  
  2.   
  3.     @Override  
  4.     public void onResponse(int callCount, Response out) {  
  5.         if (out == null) return;  
  6.   
  7.         int step = callCount % 10;  
  8.   
  9.         switch (step) {  
  10.             case 0:  
  11.             case 1:  
  12.             case 2:  
  13.             case 3:  
  14.                 out.state = Response.STATE_SUCCESS;  
  15.                 break;  
  16.             case 4:  
  17.             case 5:  
  18.                 out.state = Response.STATE_SERVER_ERROR;  
  19.                 break;  
  20.             case 6:  
  21.             case 7:  
  22.                 out.state = Response.STATE_SUCCESS;  
  23.                 break;  
  24.             case 8:  
  25.             case 9:  
  26.                 out.state = Response.STATE_NETWORK_ERROR;  
  27.                 break;  
  28.         }  
  29.   
  30.         out.delayMillis = 700;  
  31.     }  
  32. }  

 

方法onResponse()的參數out僅僅是爲了不屢次建立小對象，對應debug構建，倒也沒太大意義。

BaseMockApi

針對每個數據訪問接口，均可以提供一個mock實現。好比爲接口ITaskApi提供MockTaskApi實現類。

爲了簡化代碼，抽象基類BaseMockApi完成了大部分公共的邏輯。

[java]  view plain  copy
 
  1. public abstract class BaseMockApi {  
  2.     protected int mCallCount;  
  3.     private IMockApiStrategy mStrategy;  
  4.     private Response mResponse = new Response();  
  5.   
  6.     public Response onResponse() {  
  7.         if (mStrategy == null) {  
  8.             mStrategy = getMockApiStrategy();  
  9.         }  
  10.   
  11.         if (mStrategy != null) {  
  12.             mStrategy.onResponse(mCallCount, mResponse);  
  13.             mCallCount++;  
  14.         }  
  15.   
  16.         return mResponse;  
  17.     }  
  18.   
  19.     protected IMockApiStrategy getMockApiStrategy() {  
  20.         return new WheelApiStrategy();  
  21.     }  
  22.   
  23.     protected void giveErrorResult(final DataApiCallback<?> callback, Response response) {  
  24.         Action1<Object> onNext = null;  
  25.   
  26.         AndroidSchedulers.mainThread().createWorker().schedule(new Action0() {  
  27.             @Override  
  28.             public void call() {  
  29.                 callback.onStart();  
  30.             }  
  31.         });  
  32.   
  33.         switch (response.state) {  
  34.             case Response.STATE_NETWORK_ERROR:  
  35.                 onNext = new Action1<Object>() {  
  36.                     @Override  
  37.                     public void call(Object o) {  
  38.                         callback.onError(new IOException("mock network error."));  
  39.                     }  
  40.                 };  
  41.   
  42.                 break;  
  43.             case Response.STATE_SERVER_ERROR:  
  44.                 onNext = new Action1<Object>() {  
  45.                     @Override  
  46.                     public void call(Object o) {  
  47.                         callback.onError(new IOException("mock server error."));  
  48.                     }  
  49.                 };  
  50.                 break;  
  51.         }  
  52.   
  53.         if (onNext != null) {  
  54.             Observable.just(10086)  
  55.                     .delay(response.delayMillis, TimeUnit.MILLISECONDS)  
  56.                     .subscribeOn(Schedulers.io())  
  57.                     .observeOn(AndroidSchedulers.mainThread())  
  58.                     .subscribe(onNext);  
  59.         }  
  60.     }  
  61.   
  62.      public <T> void giveSuccessResult(final Func0<T> dataMethod, final DataApiCallback<T> callback, final Response response) {  
  63.         AndroidSchedulers.mainThread().createWorker().schedule(new Action0() {  
  64.             @Override  
  65.             public void call() {  
  66.                 Observable.create(new Observable.OnSubscribe<T>() {  
  67.                     @Override  
  68.                     public void call(Subscriber<? super T> subscriber) {  
  69.                         Log.d("MOCK", "onNext Thread = " + Thread.currentThread().getName());  
  70.                         subscriber.onNext(dataMethod.call());  
  71.                         subscriber.onCompleted();  
  72.                     }  
  73.                 }).  
  74.                 delay(response.delayMillis, TimeUnit.MILLISECONDS)  
  75.                 .subscribeOn(Schedulers.io())  
  76.                 .observeOn(AndroidSchedulers.mainThread())  
  77.                 .subscribe(new ApiSubcriber(callback));  
  78.             }  
  79.         });  
  80.     }  
  81.   
  82.     private static class ApiSubcriber<T> extends Subscriber<T> {  
  83.         private DataApiCallback<T> callback;  
  84.   
  85.         public ApiSubcriber(DataApiCallback<T> callback) {  
  86.             this.callback = callback;  
  87.         }  
  88.   
  89.         @Override  
  90.         public void onStart() {  
  91.             callback.onStart();  
  92.         }  
  93.   
  94.         @Override  
  95.         public void onCompleted() {}  
  96.   
  97.         @Override  
  98.         public void onError(Throwable e) {  
  99.             callback.onError(e);  
  100.         }  
  101.   
  102.         @Override  
  103.         public void onNext(T data) {  
  104.             callback.onSuccess(data);  
  105.         }  
  106.     }  
  107. }  

 

  • onResponse()
    方法onResponse()根據「響應策略」來針對一次請求返回一個「響應結果」，默認的策略由方法getMockApiStrategy()提供，子類能夠重寫它提供其它策略。固然策略對象自己也能夠做爲參數傳遞（此時此方法自己也沒多大意義了）。
    一個想法是，每個MockApi類都只須要一個實例，這樣它的callCount就能夠在程序運行期間獲得保持。此外，大多數狀況下策略對象只須要一個就好了——它是無狀態的，封裝算法的一個「函數對象」，爲了多態，沒辦法讓它是靜態方法。

  • giveErrorResult()
    此方法用來執行錯誤回調，此時是不須要數據的，只須要根據response來執行必定的延遲，而後返回網絡錯誤或服務器錯誤。
    注意必定要在main線程上執行callback的各個方法，這裏算是一個約定，方便UI層直接操做一些View對象。

  • giveSuccessResult()
    此方法用來執行成功回調，此時須要提供數據，並執行response中的delayMillis延遲。
    參數dataMethod用來提供須要的假數據，這裏保證它的執行在非main線程中。
    一樣，callback的方法都在main線程中執行。

上面BaseMockApi中的rxjava的一些代碼都很是簡單，徹底可使用Thread來實現。

提供MockTaskApi

做爲示例，這裏爲ITaskApi提供了一個mock實現類：

[java]  view plain  copy
 
  1. public class MockTaskApi extends BaseMockApi implements ITaskApi {  
  2.   
  3.     @Override  
  4.     public void getTasks(DataApiCallback<List<Task>> callback) {  
  5.         Response response = onResponse();  
  6.   
  7.         if (response.state == Response.STATE_SUCCESS) {  
  8.             Func0<List<Task>> mockTasks = new Func0<List<Task>>() {  
  9.                 @Override  
  10.                 public List<Task> call() {  
  11.                     // here to give some mock data, you can get it from a json file —— if there is.  
  12.                     ArrayList<Task> tasks = new ArrayList<>();  
  13.                     int start = (mCallCount - 1) * 6;  
  14.                     for (int i = start; i < start + 6; i++) {  
  15.                         Task task = new Task();  
  16.                         task.name = "Task - " + i;  
  17.   
  18.                         tasks.add(task);  
  19.                     }  
  20.   
  21.                     return tasks;  
  22.                 }  
  23.             };  
  24.   
  25.             giveSuccessResult(mockTasks, callback, response);  
  26.         } else {  
  27.   
  28.             giveErrorResult(callback, response);  
  29.         }  
  30.     }  
  31. }  

 

它的代碼幾乎不用過多解釋，使用代碼提供須要的返回數據是很是簡單的——就像你直接在UI層的Activity中寫一個方法來造假數據那樣。

小結

不管如何，通過上面的一系列的努力，模擬數據接口的代碼已經稍具模塊性質了，它能夠被動態的開關，不影響最終的release構建，能夠爲須要測試的數據接口靈活的提供想要的mock實現。

很值得一提的是，整個MockApi模塊都是創建在純java代碼上的。這樣從UI層請求到數據訪問方法的執行，都最終是直接的java方法的調用，這樣能夠很容易獲取調用傳遞的「請求參數」，這些參數都是java類。而若是mock是創建在網絡框架之上的，那麼額外的http報文的解析是必不可少的。
僅僅是爲了測試的目的，分層設計，讓數據訪問層能夠在真實接口和mock接口間切換，更簡單直接些。

最後，造假數據固然也能夠是直接讀取json文件這樣的方式來完成，若是服務器開發人員有提供這樣的文件的話。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程