《一個Android工程的從零開始》-5、base(四) BaseActivity——方法封裝
先扯兩句
昨天發了一篇GitHub版本控制的整合後,今天終於迴歸正事,繼續我們的《一個Android工程的從零開始》,真心有點小開心呢。
今天也是base的BaseActivity完結掉了,昨天我也查了一下其他人的BaseActivity封裝,發現卻比我的篇幅少了不少,不過既然要從基礎說起,自然廢話也就多了一些,請大家見諒。
既然昨天已經發了GitHub的版本控制,那麼這篇開始就發GitHub的連結了,碼雲的就暫停更新維護了,另外onstraintLayout的也相差不多,只是佈局的部分不同,但是由於很少有用程式碼部分完成的,這裡就不予以展示了。
正文
本次的內容總共有如下四點:
- 常用常量、變數;
- 介面跳轉;
- 網路監聽;
- 提示框。
這個順序很顯然是本著我個人一貫偷懶成癮的套路排列的,不過這不重要,我們還是開始今天的內容吧。
常用常量、變數
這個部分的內容放在最簡單的位置上,其實主要還是由於我所能寫的東西有限,但實際上就那四點而言,這個部分是最複雜的,因為不同的工程專案,對這部分的需求往往是更不相同的,我們也無法一概而論的給出一個具體的實現方式,所以就再此做一個簡要的分析。
這部分如果做簡單分類呢,就是兩個點:其一是使用者相關;其二是程式設計相關
- 使用者相關
使用者相關的東西,在這裡主要是一些常用的資訊,例如使用者id、使用者聯絡方式、使用者頭像等等。這部分的做法有兩種,其一,這些資訊分別儲存,用的時候直接呼叫;其二建立一個使用者類,將常用的使用者資訊儲存起來,在後面需要的時候,在使用者類中去對應取值。
原因是,一般而言,我們會將使用者資訊儲存起來,當然,也就是有兩種方式,伺服器儲存、資料庫儲存。在我們後期使用使用者資訊的時候,基本都是從這三種途徑獲取,必不可少的,自然數伺服器儲存,但是如果每次我們使用,都要去請求一邊伺服器,是很浪費資源,而且完全沒必要的。所以一般情況下(個別安全性嚴謹的除外),都是隻有第一次登入賬戶的時候,獲取一下個人的資訊,儲存在本地,用的時候直接呼叫。而至於在本地是使用資料庫儲存,或許有人比較喜歡SharedPreference,不過個人不建議,畢竟儲存的資料量比較大。
但無論使用哪種,繁複訪問資料庫也是一個很耗時的操作,所以很容易影響到使用者的體驗,所以這個時候就可以選擇在BaseActivity中保留一個使用者資訊的部分,方便之後使用,不過個人建議保留一些常用的即可,沒必要將整個使用者資訊都暴露出來。
由於專案不同,所需也不盡相同,這部分就並予以展示了。 - 程式設計相關
這部分呢,我主推Context (也就是傳說中的上下文),建立一個Context 的共有變數,在onCreate中賦值
public Context context;
public Activity activity;
//在onCreate中
context = getApplicationContext();
activity = this;
大家看到這部分可能或疑惑,畢竟關於BaseActivity的封裝,也不是我一個人在寫,之前看到的或許在BaseActivity中就不存在context,或者是使用的Activity。而無論是使用的Context還是Activity的,在onCreate中,也不過是使用的context = this;為什麼到我這裡卻非要圖個不一樣,一定多要寫一個context = getApplicationContext(),我們分開來闡述。
- 為什麼定義Context
這個部分,最開始呢,我只是為了與BaseFragment相統一,方便後續編碼,至於原因,就先劇透一下了,那就是在Fragment中使用getActivity()方法,容易導致空指標異常,至於原因,我們就先買個關子,到了BaseFragment中,再為大家剖析。
偷懶的解決方法就是在BaseFragment中獲取一個上下文資訊,後面需要使用的時候直接呼叫就可以,所以為了程式碼統一,在BaseActivity中就定義了一個,而且還是那句話,畢竟我們可以偷懶啊,不用每次getContext或者getApplicationContext來獲取上下文了。隨著查資料,我有發現了一個原因,就是為什麼我寫了一個Context的同時又寫了一個Activity。 - 為什麼要多出來一個context = getApplicationContext();
先需要說明的是,其實Application與Activity都是Context的子類,下面開始正是解釋。
getApplicationContext主要的用處就是防止記憶體洩漏,尤其是一些靜態的類需要持有context的時候,如果我們傳入了Activity,那麼這個靜態類沒有被銷燬之前,對應的Activity也不會被銷燬,這樣就會導致記憶體洩漏,而getApplicationContext得到的是整個應用的Context,也就是說,只要Application還在,那麼這個Context物件就一直在,哪怕是被靜態或者其他可能會導致記憶體洩漏的方法或者類持有,也不會導致記憶體洩漏。
但是,如果完全使用getApplicationContext就可以嗎?你可以試試,知道遇到“Caused by: java.lang.IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity.”這個錯誤。
這是在使用AlerDialog的時候,出現的錯誤,我查到的是如下原因,所以對應這部分我們就要使用activity,也就是this。
在語句 AlertDialog.Builder builder = new AlertDialog.Builder(this); 中,要求傳遞的 引數就是一個context,在這裡傳入的是this,那麼這個this究竟指的是什麼東東呢? 這裡的this指的是Activity.this,是這個語句所在的Activity的this,是這個Activity 的上下文。網上有很多朋友在這裡傳入this.getApplicationContext(),這是不對的。 AlertDialog物件是依賴於一個View的,而View是和一個Activity對應的。 於是,這裡涉及到一個生命週期的問題,this.getApplicationContext()取的是這個應 用程式的Context,Activity.this取的是這個Activity的Context,這兩者的生命週期是不同 的,前者的生命週期是整個應用,後者的生命週期只是它所在的Activity。而AlertDialog應 該是屬於一個Activity的,在Activity銷燬的時候它也就銷燬了,不會再存在;但是,如果傳 入this.getApplicationContext(),就表示它的生命週期是整個應用程式,這顯然超過了它 的生命週期了。 所以,在這裡只能使用Activity的this。
所以,暫且理解為控制元件相關就使用activity,方法相關就使用context。不過如果實在難以區分的情況下,對與記憶體洩漏要求不嚴格,可是隻使用activity,遇到記憶體洩漏時再替換成getApplicationContext,不過相對於這種解決方式,我還是比較傾向於,兩個都建立,先使用context,直接報錯的情況下,再換成activity。
再其他的與程式設計相關的就是一些資料庫的引用、SharedPreference的引用,還有就是常量,大多數在BroadCast Reciever中使用的不較多。
Tips
這部分,除了activity與context的部分,其他均建議在utils目錄下建立一個Const類,將這些存入其中呼叫,以減輕BaseActivity。
介面跳轉
這部分說白了就是startActivity和startActivityForResult的封裝,在Android開發中,這兩個方法的使用頻率就不用我多說了,那是相當多啊,所以發揮我一貫偷懶的準則,這麼能忍每次都要建立Intent這麼麻煩事呢。
所以封裝瞭如下兩個方法:
/**
* 跳轉頁面
*
* @param clz 所跳轉的目的Activity類
*/
public void startActivity(Class<?> clz) {
startActivity(new Intent(this, clz));
}
/**
* 跳轉頁面
*
* @param clz 所跳轉的Activity類
* @param requestCode 請求碼
*/
public void startActivityForResult(Class<?> clz, int requestCode) {
startActivityForResult(new Intent(this, clz), requestCode);
}
這樣,我們在使用的時候,就可以傳遞目標Activity.class就可以實現跳轉頁面的目的了。
當然,我們除了這麼跳轉之外,還會有需要傳參的時候,對於這部分內容,對於這部分,我們可以使用Bundle來完成,方法如下:
/**
* 跳轉頁面
*
* @param clz 所跳轉的目的Activity類
* @param bundle 跳轉所攜帶的資訊
*/
public void startActivity(Class<?> clz, Bundle bundle) {
Intent intent = new Intent(this, clz);
if (bundle != null) {
intent.putExtra("bundle", bundle);
}
startActivity(intent);
}
/**
* 跳轉頁面
*
* @param clz 所跳轉的Activity類
* @param bundle 跳轉所攜帶的資訊
* @param requestCode 請求碼
*/
public void startActivityForResult(Class<?> clz, int requestCode, Bundle bundle) {
Intent intent = new Intent(this, clz);
if (bundle != null) {
intent.putExtra("bundle", bundle);
}
startActivityForResult(intent, requestCode);
}
當然,大家如果認為麻煩的話,傳參的部分直接使用Intent的方法也是可以的,畢竟使用Bundle就程式碼量上而言,並沒有得到實質性的優化。
除此之外,關於跳轉頁面還有一些運用。
在工程中,經常會出現退出程式,或者異地登入的情況,出現這種情況的時候,就需要將當前的所開啟的Activity中除MainActivity外的其他Activity都關閉。
還有就是,完成一些列可回退的操作後,需要一次性關閉掉過程中所開啟的所有Activity。
以上這些操作就需要我們使用下面的部分做處理。
首先需要建立一個List儲存我們過程中開啟的所有Activity,並在onCreate中新增到List中。
private static List<Activity> activities = new ArrayList<>();
//在onCreate新增
if (!(this instanceof MainActivity)) {
activities.add(this);
}
//在onDestroy新增,防止空指標或者記憶體洩漏
activities.remove(this);
可能大家會發現上面我使用了一個if判斷,其作用就是防止MainActivity被新增到列表中,便於後面的運用,因為大多數的app在徹底退出app之前很少有會將MainActivity關閉的,這樣就可以便於後面的運用,防止將所有的Activity都關閉了導致程式都退出了。
再就是運用部分了,首先是所有都關閉,這個比較簡單,就是遍歷一邊,挨個關閉就可以
/**
* 關閉所有Activity(除MainActivity以外)
*/
public void finishActivity() {
for (Activity activity : activities) {
activity.finish();
}
}
可能有人會疑惑,這樣關閉就不需要將被關閉的Activity從Activity集合中移除嗎?這點大家可以放心,因為finish方法執行的時候,會執行對應Activity的onDestroy方法,因此,就不需要額外新增remove方法了。
最後就是跳轉到指定的以開啟Activity,並將其堆疊上方的Activity全關閉的方法
/**
* 跳轉到指定的Activity
*
* @param clz 指定的Activity對應的class
*/
public void goTo(Class<?> clz) {
if (clz.equals(MainActivity.class)) {
finishActivity();
} else {
for (int i = activities.size() - 1; i >= 0; i--) {
if (clz.equals(activities.get(i).getClass())) {
break;
} else {
activities.get(i).finish();
}
}
}
}
判斷部分是看,是否是跳轉到MainActivity,如果是,那麼就將所有的都關閉即可,也就是呼叫finishActivity方法即可,當跳轉的不是MainActivity的時候,就要遍歷一下List了,for迴圈從i–的目的就是從上而下清理堆疊,到達我們想要跳轉的目標Activity時,跳出迴圈即可。
而如果使用過程中,你發現,不是MainActivity卻跳轉到了MainActivity,那麼恭喜你,你填寫的Activity並不在List內,這樣也是一個避免bug的檢驗。
網路監聽
想必大家在使用APP的時候,都體會過,在忽然斷網的時候,自己還沒反應到,APP就已經提醒你了,現在斷網了。
或者是當看視訊到一半,忽然提示你,wifi斷了,當前使用的是流量是否繼續觀看。
還有就是我之前在工作中遇到的,實時顯示出當前所連wifi的wifi名。
所以無論上面的哪種情況,都需要我們對網路做一個監聽,而這部分內容,十分感謝mxiaoyem的Android 實時監測(監聽)網路連線狀態變化幫了個大忙,按照其部落格所說的內容就可以實現,這裡我就不加以贅述了,在我的git上也能找到具體的應用。
只是其中有一個地方需要大家注意一下,那就是一定要在AndroidMenifest.xml中註冊你所建立的NetBroadcastReceiver。當然,也可以直接複製部落格中所寫的內容,但是需要注意的一點是,我們的包或許與作者的不同,所以需要做修改,不然會報紅,方法很簡單,如下圖:
找到對應的NetBroadcastReceiver回車即可。
提示框
這部分呢,一共分為了兩部分,分別是:1、Toast;2、網路載入提示框。
1、Toast
Toast是簡單的文字提示的時候使用,封裝起來也很簡單,直接上程式碼了。
/**
* 訊息提示框
*
* @param message 提示訊息文字
*/
public void showToast(String message) {
Toast.makeText(context, message, Toast.LENGTH_SHORT).show();
}
/**
* 訊息提示框
*
* @param messageId 提示訊息文字ID
*/
public void showToast(int messageId) {
Toast.makeText(context, messageId, Toast.LENGTH_SHORT).show();
}
以上兩個方法,對應的分別是,直接傳遞字串和傳遞string.xml中的string對應的id。
2、網路載入
這部分實際上就是一個網路載入的ProgressBar,但是為了方便使用,所以巢狀在了ProgressDialog內。
懂我套路的一定會猜到,我又該提出感謝了,哈哈哈。十分感謝哇牛Aaron的Android progressdialog自定義背景透明的圓形進度條類似於Dialog幫了個大忙。當然這部分我就沒有上面網路監聽部分那麼偷懶了,而是做了一定的簡化,只要了實現我預期功能的部分,其他的內容暫時沒有新增到專案中,如果大家也只是想實現一個效果的話,可以看一下我下面貼出來的程式碼,如果想深入的瞭解一下的話,可以看一下上面對應的這篇部落格。
先上一下效果圖:
沒錯,就是中間的那個圈,至於那個一如既往的醜的背景,辛苦大家暫且忍受一下。
首先是一個ProgressDialog的佈局檔案:
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="@android:color/transparent">
<ProgressBar
style="@style/progress_dialog_loading"
android:id="@+id/progress_progress"
android:indeterminateDrawable="@drawable/progressbar_load"
android:layout_width="48dp"
android:layout_height="48dp"
android:padding="3dp"
android:layout_centerInParent="true"
android:visibility="visible" />
<TextView
android:id="@+id/progress_text"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_below="@+id/progress_progress"
android:layout_centerHorizontal="true"
android:layout_marginTop="@dimen/size_17"
android:textSize="@dimen/size_17" />
</RelativeLayout>
先說一下比較次要的TextView吧,它的功能主要就是一個文字提示,例如比較常見的“玩命載入中。。。”之類的,只要根據id找到控制元件,對應setText就可以了。
再就是我們主體ProgressBar,其中有兩個屬性之前部落格沒提到過:1、style,就是一個設計風格,也是一個比較常用的屬性,對應內容下面會貼出;2、android:indeterminateDrawable,設定的是非進度條(也就是那個圈)的動畫Drawable,程式碼後面也會貼出來。
貼程式碼嘍。
style(裡面只有一條,就是背景透明,這個style很快在後面會再用到):
<style name="progress_dialog_loading" parent="@android:style/Theme.Dialog">
<item name="android:windowBackground">@android:color/transparent</item>
</style>
然後是Drawable對應的動畫xml:
<?xml version="1.0" encoding="utf-8"?>
<rotate xmlns:android="http://schemas.android.com/apk/res/android"
android:fromDegrees="0"
android:pivotX="50%"
android:pivotY="50%"
android:toDegrees="360" >
<!-- 這裡畫了一個灰色的環形 -->
<shape
android:innerRadiusRatio="3"
android:shape="ring"
android:thicknessRatio="8"
android:useLevel="false" >
<!-- 徑向漸變 -->
<gradient
android:centerColor="#ffffff"
android:centerX="1.0"
android:centerY="1.0"
android:endColor="@android:color/darker_gray"
android:gradientRadius="90"
android:startColor="@android:color/darker_gray"
android:type="radial"
android:useLevel="false" />
</shape>
</rotate>
drawable的主要內容就是繪製一個環,背景白色,漸變角度90°,開始與結束都設定成了深灰色。
以上幾部分配合,就完成了我們的ProgressDialog的佈局內容,當然,當然,如果大家看了上面的 哇牛Aaron 的部落格就會發現,我做的化簡只要將style中的屬性做了刪減。
下面就該進行下一部分了,就是ProgressDialog的自定義,還是先上打碼在分析:
package com.mybaseapplication.widget;
import android.app.ProgressDialog;
import android.content.Context;
import android.os.Bundle;
import android.widget.TextView;
import com.mybaseapplication.R;
public class CustomProgressDialog extends ProgressDialog {
private String message = "";
public CustomProgressDialog(Context context, int theme) {
super(context, theme);
}
public CustomProgressDialog(Context context, int theme,
String message) {
super(context, theme);
this.message = message;
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.laod_progressbar_layout);
//dialog彈出後點擊物理返回鍵Dialog消失,但是點選螢幕不會消失
this.setCanceledOnTouchOutside(false);
//dialog彈出後點擊螢幕或物理返回鍵,dialog都不消失
//this.setCancelable(false);
if (message != null){//message不為空,則設定
((TextView)findViewById(R.id.progress_text)).setText(message);
}
}
}
其中大家可以看到,我使用了兩個構造方法,一個是:
public CustomProgressDialog(Context context, int theme)
另一個是:
public CustomProgressDialog(Context context, int theme,
String message)
先說一下共通的引數,context上下文資訊,這個是每個控制元件都需要的一個引數,與當前的Activity繫結在一起,也就是前面所說的activity引數,而不能使用context。
theme主題,也就是前面我們定義的style,用途還是將ProgressDialog的背景設定為透明,如果不設定這個style的話,那麼出來的就會有白色的背景,即便你將ProgressDialog解析的佈局檔案的背景和ProgressBar的背景都設定成了透明也一樣。錯誤效果如圖:
而第三個引數message,就是我們想要顯示的文字,類似“玩命載入中。。。”通過構造方法傳入進來,就可以顯示了,如圖:
然後是在BaseActivity中如何呼叫,第一步先建立一個私有的CustomProgressDialog
/**
* 載入提示框
*/
private CustomProgressDialog customProgressDialog;
第二步,在onCreate中例項化(也就是new 一下):
//不傳文字
customProgressDialog = new CustomProgressDialog(activity, R.style.progress_dialog_loading);
//傳遞文字
customProgressDialog = new CustomProgressDialog(activity, R.style.progress_dialog_loading, "玩命載入中。。。");
再就是顯示與隱藏的方法了。
/**
* 顯示載入提示框
*/
public void showLoadDialog() {
customProgressDialog.show();
}
/**
* 隱藏載入提示框
*/
public void hideLoadDialog() {
if (customProgressDialog != null && customProgressDialog.isShowing()) {
customProgressDialog.dismiss();
}
}
不過這裡我們使用的是直接顯示的或隱藏,如果在主執行緒中如此使用,自然沒有問題。也能正常顯示,就如同我上面截圖一樣,但是如果你想把顯示或者隱藏的方法放在子執行緒中使用的話,這兩個方法就沒法起到作用了。
原因參見WongWoo1991的子執行緒中progress不顯示問題,裡面也給出瞭解決方法,那就是將ProgressDialog的操作巢狀在runOnUiThread內,這樣就可以使其正常運行了,修改後的方法如下:
/**
* 顯示載入提示框
*/
public void showLoadDialog() {
runOnUiThread(new Runnable() {
@Override
public void run() {
customProgressDialog.show();
}
});
}
/**
* 隱藏載入提示框
*/
public void hideLoadDialog() {
runOnUiThread(new Runnable() {
@Override
public void run() {
if (customProgressDialog != null && customProgressDialog.isShowing()) {
customProgressDialog.dismiss();
}
}
});
}
如此,這篇部落格的內容終於都寫完了,BaseActivity的封裝到此也就結束了,當然還有一些方法,例如Log日誌輸出,還有一些工具類的建立,不過就像是前面所說第一部分常用常量、變數中所說的一樣,這些方法還是建議在Utils包下建立Const完成,免得BaseActivity中內容太過冗雜。
還有就是一些資料庫訪問的或者全域性SharedPreference的訪問介面,也可以放在BaseActivity中,但是這部分比較複雜,在對應使用的地方再加以說明。
以上內容均為我個人的粗淺理解,大家如果發現問題或者可以新增的部分,可以留言,大家一起加油進步哦。
附錄
相關推薦
《一個Android工程的從零開始》-5、base(四) BaseActivity——方法封裝
先扯兩句 昨天發了一篇GitHub版本控制的整合後,今天終於迴歸正事,繼續我們的《一個Android工程的從零開始》,真心有點小開心呢。 今天也是base的BaseActivity完結掉了,昨天我也查了一下其他人的BaseActivity封裝,發現卻比我的篇
從零開始學習OpenCL開發(四)shader
這裡介紹關於OpenCL中program函式的寫法,program函式通常是文字形式的,然後使用clCreateProgramWithSource這樣的介面load進來。在Shader程式設計中也經常使用這種形式書寫GPU上執行的程式碼,所以為了表述清楚和理解方
從零開始實現放置遊戲(四)——實現掛機戰鬥(2)實現後臺數值配置
上一章我們將RMS後臺管理系統搭建完畢,本章我們就在這個系統上實現錄入遊戲配置的功能。目前我們需要配置四項,每個等級的人物屬性,每個等級的升級經驗,遊戲地圖,地圖中的怪物。下面我們以遊戲地圖配置為例子,實現對它的增刪查改功能。 一、資料訪問層的實現 首先,我們需要定義地圖類,這個類在各個模組通用,
從零開始學Electron筆記(四)
在之前的文章我們介紹了一下Electron的這個remote模組,接下來我們繼續說一下Electron的右鍵選單的製作。 在我們日常我們使用的軟體中都會存在右鍵選單的情況,比如我們用到的瀏覽器,開發所用到的程式碼編輯器都有右鍵選單,可以方便我們的日常操作,接下來我們就來看一下用Electron如何實現右鍵選單
[Golang] 從零開始寫Socket Server(3): 對長、短連接的處理策略(模擬心跳)
microsoft ted 每次 range 點擊 關閉 ade 而在 href 通過前兩章,我們成功是寫出了一套湊合能用的Server和Client,並在二者之間實現了通過協議交流。這麽一來,一個簡易的socket通訊框架已經初具雛形了,那麽我們接下來做的
從零開始微信機器人(一):wxpy簡介(登入、訊息傳送、註冊回覆)
在過去的幾個月中,由於在新生群中回答問題費時費力,同時又有許多重複而又有固定答案的回答,我受到一些知乎文章的啟發,維護了一個基於itchat的群聊機器人。從剛開始接入圖靈機器人時只會尬聊的機器人,之後又加入了api.ai的按照訊息內容自動回覆,而後再加入了回覆表情功能
[Golang] 從零開始寫Socket Server(3): 對長、短連線的處理策略(模擬心跳)
通過前兩章,我們成功是寫出了一套湊合能用的Server和Client,並在二者之間實現了通過協議交流。這麼一來,一個簡易的socket通訊框架已經初具雛形了,那麼我們接下來做的,就是想辦法讓這
從零開始實現放置遊戲(七)——實現掛機戰鬥(5)RMS系統後臺引數校驗
前面幾章實現了在RMS系統中進行資料的增刪查改以及通過Excel批量匯入。但仍有遺留的問題,比如在新增或編輯時,怪物的生命值、護甲等資料我們可以輸入負值,這種資料是不合理且沒有意義的。本章我們就實現服務端對引數的校驗。 一、新增依賴項 在rms模組的pom.xml中,新增校驗元件的依賴項(注意:之
從零開始學習OpenCL開發(一)架構
處理器 多媒體 c++ stl context 實驗 通用 必看 是你 同時存在 1 異構計算、GPGPU與OpenCL OpenCL是當前一個通用的由很多公司和組織共同發起的多CPU\GPU\其他芯片 異構計算(heterogeneous)的標準,它是跨平臺的。旨在充
從零開始學Linux系統(一)
系統啟動 linux 自定義 管理 如果 level 技術 int 沒有 Linux系統:分時多用戶多任務的操作系統; Linux系統引導流程: inittab配置文件中: 定義了linux系統的運行的7個級別:從0~6 0、6:分別代表關機和重啟,不建議設置為默認的
[Python接口自動化]從零開始學習python自動化(1):環境搭建
help ins cnblogs 文件中 ssi 空格 plugins 變量 mod 第一步:安裝python編譯環境 安裝python編譯環境之前,必須保證已安裝jdk哈,如果為安裝,請參考https://jingyan.baidu.com/article/6dad507
[Golang] 從零開始寫Socket Server(6)【完結】:日誌模組的設計與定時任務模組模組
好久沒寫文章啦。。。今天把golang挖的這個坑給補完吧~ 作為一個Server,日誌(Log)功能是必不可少的,一個設計良好的日誌模組,不論是開發Server時的除錯,還是執行時候的維護,都是非常有幫助的。 因為這裡寫的是一個比較簡化的Server框架,因此我選擇對Golang本
[Golang] 從零開始寫Socket Server(4):將執行引數放入配置檔案(XML/YAML)
為了將我們寫好的Server釋出到伺服器上,就要將我們的程式碼進行build打包,這樣如果以後想要修改一些程式碼的話,需要重新給程式碼進行編譯打包並上傳到伺服器上。 顯然,這麼做過於繁瑣。。。因此常見的做法都是將Server執行中
[Golang] 從零開始寫Socket Server(2): 自定義通訊協議
在上一章我們做出來一個最基礎的demo後,已經可以初步實現Server和Client之間的資訊交流了~ 這一章我會介紹一下怎麼在Server和Client之間實現一個簡單的通訊協議,從而增強整個資訊交流過程的穩定性。  
[Golang] 從零開始寫Socket Server(1): Socket-Client框架
第一次跑到網際網路公司實習 。。感覺自己進步飛快啊~第一週剛寫了個HTTP伺服器用於微信公共號的點餐系統~ 第二週就直接開始一邊自學GO語言一邊寫用於Socket的伺服器了。。。 因為發現Golang這一塊資料挺少的,接下來我會在Blog裡把整個Server的Coding,還有遇到的坑都記錄
從零開始學後端(4)——JDBC的重構設計
重構(Refactoring)就是通過調整程式程式碼,改善軟體的質量、效能,使其程式的設計模式和架構更趨合理,提高軟體的擴充套件性和維護性。 問題1:每個DAO方法中都會寫:驅動名稱/url/賬號/密碼,不利於維護. 如果現在我們從MySQL遷移到Oracle中去,此時就得修
從零開始Vue專案實戰(三)-專案結構
現在在瀏覽器中輸入http://localhost:8083,可以看到初始的“Welcome to Your Vue.js App”頁面了 目錄結構 ├── README.md 專案介紹 ├── index.html 入口頁面 ├── build
從零開始Vue專案實戰(二)-搭建環境
1、下載node.js並安裝 下載地址:https://nodejs.org/en/download/。 下載.msi 格式的直接連續下一步就可以了。安裝完成後可以用 node -v 和 npm -v 檢視版本號。 2、安裝vue-cli 腳手架構建工具 在命令列中輸入npm ins
從零開始Vue專案實戰(一)-準備篇
從前參與過一個react專案的程式碼編寫,大神搭建的框架,我主要負責業務邏輯程式碼編寫,現在回想起來似乎又什麼都不會,現在為了鞏固前端知識,決定用Vue來做這個專案的移動端網站,我本人Vue是從零開始的,一邊學習一邊寫程式碼,在這裡記錄一下過程。 專案說明: 主要功能實現一個投資平臺,會員身份為融資人或投
從零開始學習HTML+CSS(2)安裝Emmet
如何在Sublime Text3中安裝Emmet外掛 方法:參考官網 https://packagecontrol.io/installation 可能遇到的問題及處理辦法 問題:在安裝時彈出這樣顯示的視窗 Error while loading PyV8 binary: e