Do everything with your passion: 10月 2014

2014年10月30日星期四

Android 開發(七十四) extract string to xml

相信每個開發app的開發人員都會有這個經驗，每次要將字串抽到string.xml裡的時候
都要花很多時間，不知道android studio有沒有提供什麼快速的方法呢?

答案當然是有的

首先先選取字串 -> 按下 alt + enter -> extract string resource -> keyin your resource name -> done

話說...最近越來越懶人模式了XD

2014年10月28日星期二

Android 開發(七十三) jsonToJava

我相信目前大部分的人都是使用Gson來接資料，
但是在接資料的時候會發現，每次新的api都要自己建model很麻煩....
尤其是當model很多層的時候就會花很多時間在這個上面

好啦...其實是我很懶...

所以，我就稍微搜尋了一下相關的tool 然後就找到了
http://jsontojava.appspot.com/

這個要怎麼用？首先將你的dummy api或者是實際上要串接的api的網址丟入
並且填入你要的package name 和 folder name 還有是否要使用parceable/gson

接著等個幾秒鐘，你的model就完成了
最重要的是，他有提供command line，所以只需要寫個簡單的script就可以在local
快樂的使用這個功能了!!

2014年10月23日星期四

Android 開發(七十二) Regex開發

我想有一點開發經驗的developer都會遇過同樣的情形，

在android上寫regex是非常痛苦的一件事，

因為語法不熟，所以常常要測試語法是否有寫錯，可是

總不能每寫一次語法就build一次，這樣實在太花時間，為了解決這個問題

我稍微搜尋了一下android studio的plugin

Regex Tester個人覺得是蠻方便的工具

只需要在上方打入reg語法，下方寫入你要match的文字，他就會自動幫你check了
不再需要build就可以直接測試，速度快多了

設定環境變數

當要設定環境變數時，可以利用以下的方式做設定，

vi ~/.bash_profile

然後在文件裡key入路徑即可

export ANDROID_SDK_HOME=~/Documents/adt-bundle-mac-x86_64-20140321/sdk

export PATH="$ANDROID_SDK_HOME/tools:$ANDROID_SDK_HOME/platform-tools:$ANDROID_SDK_HOME/build-tools/17.0.0:$PATH"

2014年10月22日星期三

Android 開發(七十一) Gradle 查詢可執行command

常常會遇到要下gradle command的時候卻不知道該怎麼去下command

例如我今天想要看 dependencies tree ，可是卻不知道該如何下commnad

gradle 有內建一個非常方便的功能

gradle -q task --all

這個commnad會將所有可執行的task 列出來，有點像是ls的感覺...

你可以利用這個command找到你希望執行的command

以下是我下 gradle -q task --all的部分可執行 command

Android tasks

-------------

actionbarsherlock:androidDependencies - Displays the Android dependencies of the project

app:androidDependencies - Displays the Android dependencies of the project

DataDroid:androidDependencies - Displays the Android dependencies of the project

FacebookSDK:androidDependencies - Displays the Android dependencies of the project

slideMenu:androidDependencies - Displays the Android dependencies of the project

viewpager:androidDependencies - Displays the Android dependencies of the project

從上面可以很清楚的知道，假設我要看我project的 dependencies

我只需要執行 gradle app:androidDependencies

2014年10月16日星期四

Android 開發（六十九）DrawerArrowDrawable

我想用過 material design L 的人都看過以下的ui

但是有人想過這個功能要怎麼完成嗎?

前幾天看到ChrisRenke po出了一篇完整分析的文章，他的做法令人非常的驚豔(至少我是如此XD)

接下來我們就來介紹他是如何完成的

首先他針對menu上的三條線做了分析，

from chrisrenke

以上這張，有三個顏色，紅，藍，菊，分別代表著上，中，下，三條線，
所以這張圖可以完整地看出三條線的移動路徑，不過非常的雜亂，所以作者經過整理之後
變成了下面這張圖

from chrisrenke

這張圖其實就是在說明，線實際運作的軌跡，我們可以用下面這張圖來進一步說明，

from chrisrenke

上面較長的黑色橫線就是一開始最上面的那條線，然後結束之後會抵達，斜約45度角的線，
實際上的樣子會是如下圖

一開始是走藍色的路徑，當數值大於0.5的時候就會走黑色的路徑
我想這樣大家應該比較看得懂，他的路徑是怎麼走的了，
既然我們已經了解了他實做的方式，接下來我們就需要在我們的android中實做出來，

首先，我們必須實做上面的兩個圓弧，
so....我們可以利用 path 來完成這個功能，

也就是如下的程式


	first = new Path();
	first.moveTo(5.042f, 20f);
	first.rCubicTo(8.125f, -16.317f, 39.753f, -27.851f, 55.49f, -2.765f);
	second = new Path();
	second.moveTo(60.531f, 17.235f);
	second.rCubicTo(11.301f, 18.015f, -3.699f, 46.083f, -23.725f, 43.456f);
	scalePath(first, density);
	scalePath(second, density);
	joinedA = new JoinedPath(first, second);

	first = new Path();
	first.moveTo(64.959f, 20f);
	first.rCubicTo(4.457f, 16.75f, 1.512f, 37.982f, -22.557f, 42.699f);
	second = new Path();
	second.moveTo(42.402f, 62.699f);
	second.cubicTo(18.333f, 67.418f, 8.807f, 45.646f, 8.807f, 32.823f);
	scalePath(first, density);
	scalePath(second, density);
	joinedB = new JoinedPath(first, second);
	topLine = new BridgingLine(joinedA, joinedB);

上面的四個path就代表著藍色黑色弧形，JoinedPath其實只是要方便參照，當值<0.5時參照
JoinedPath的first Path當>0.5時參照second Path,
而其中最關鍵的技巧就是，measureFirst.getPosTan(lengthFirst * parameter, coords, null);
利用這個當 <0.5時，就會去參考 JoinedA的 first Path 與 JoinedB的 first Path的第一個點，

也就是上圖的兩個藍色圓弧的第一個點，也就是橫線時的起始點，
當完成了第一條線，剩下的兩條線也是相同的邏輯，在這裡就不再多提

只能說想出這個解法的人真的很厲害，相信他花了很多時間才完成這個功能，不過同時
我們也從他的這個方法中學到如何利用path以及param的改變，來改變view.

真的是獲益良多!!~ 最後歡迎有興趣的各位可以去參考他的source code

http://chrisrenke.com/drawerarrowdrawable/
https://github.com/ChrisRenke/DrawerArrowDrawable

2014年10月2日星期四

[RefactoringToPatterns] Replace Constructors with Creation Methods

最近開始看 RefactoringToPatterns 最近應該會開始分享這本書的一些心得，
今天就先來分享 Replace Constructors with Creation Methods吧
作者在一開始就列出了兩個範例

哪個看起來比較能清楚表達我們要創建什麼物件?

我相信大家都會選擇下方的選項，
Replace Constructors with Creation Methods的意思就是

以目的清楚, 返回物件實體的Creation Method 取代建構式

然而使用這個方法雖然能夠讓我們清楚了解要創建什麼物件，相對的他也帶來了部分的缺點

優點：

比建構式更能表達要創建哪種物件
突破建構式的限制，不能同時擁有兩個引數個數和引數型別君相同的建構式
更容易找出未使用的創建式

缺點：

創建的方式變得不標準，以上面loan的例子來說：我們可以用new Loan(...)
也可以用 Loan.createTermLoad(...)

至於該如何實做，這邊附上一個很小的範例

public class Loan {

    public Loan(int a, int b) {

    }

}

原本的建構式是長這個樣子，經過refactoring 之後

public class Loan {
    
    private Loan(int a,int b){
        
    }
    
    public static Loan createTermLoan(int a,int b){
        return new Loan(a,b);
    }
}

可以很清楚地看到，我們使用了static method來創建我們的Loan
這樣之後要創建Loan時我們只需要call Loan.createTermLoan即可

最後，作者也有提到，當我們的物件裡含有太多的creation method，
而這些method開始混淆這個class原本該做的事情時，根據單一責任原則，
我們可以將Creation method 再度重構為Factory.
如下圖所示

2014年10月30日 星期四

2014年10月28日 星期二

2014年10月23日 星期四

2014年10月22日 星期三

2014年10月16日 星期四

2014年10月2日 星期四

2014年10月30日星期四

2014年10月28日星期二

2014年10月23日星期四

2014年10月22日星期三

2014年10月16日星期四

2014年10月2日星期四