Android 建立新專案在 SDK 22.6 後的變化

Android SDK 在 2014 年 3 月時升級到 22.6 版 (for eclipse),依慣例,也發生了一些問題 XD。

不過本篇這次不探討那些問題,這次要提的東西是,因為升級到這個版本後,尤其對使用 Eclipse / ADT 的開發者來說,會比較不習慣,甚至是不知道為何多出了一些東西。所以接下來就是稍微為各位介紹一下更新到這個版本後,對使用 Eclipse 這個 IDE 的開發者來說,大概多了什麼。

 

我們先就平常自己在練習時,或是在開啟一個新專案的流程來看,若是都沒有什麼特殊需求,就是在新增專案的過程中,不斷地下一步進行下去。在專案建立完成後,會在專案列表中看到如下畫面,

Package Explorer for v22.6

圖中用紅線圈了兩個部份:

  • Layout

在 Layout 目錄中,過去都只有一個 activity_main 介面,而這邊多了一個 fragment_main.xml,從這個檔案名稱來看,相信也滿清楚的,他就是一個 fragment 的畫面檔,而過去習慣的介面設計也可以從 activity_main 改到這裡來。這個對於新手或是不慣用 fragment 的開發者來說,的確有可能會是一個障礙,所以,也這是接下來各位開發者需要花點時間去了解的東西,而這個對於在使用 Android Studio 的開發者來說,可能還會覺得,這有什麼好大驚小怪的,Android Studio 從一開始就一直是這個樣子了 XD。

那既然在介面檔有所變化,這當然也意謂著,原始碼中也多了點什麼。所以,這個時候,我們再到打開 src/[package name] 目錄的 MainActivity.java,跟原本一樣的就先不說了,這裡一樣有兩個不同處。先是 activity 的繼承的父層從 Activty 變成 ActionBarActivity,

 這個就留待 Project Library 時再一起介紹,先跳過 onCreate() 往下看到最後,有一個 Fragement 類別,

這裡就是跟 fragment_main.xml 成對的主要物件,而 Fragment 也是官方希望開發者能將 android app 開發成 responsive design 的一個關鍵,這個可以讓畫面被重覆使用,或是在做畫面切割、分層時,很好的一個利器。而 fragment 也有自身的生命週期,原則上,筆者會建議對這個物件不熟的朋友,先了解他如何運作,把這個 fragment 獨立成一個物件檔,會比將他放在 activity 裡面要好。

這邊算是 fragment 物件定義,那實作他的地方,我們再看回 onCreate(),

這段時是使用 fragment 的起手式,這邊大概提一下,如果您開發的 app 是從 4.0 開始支援,那只要將 getSupportFragmentManager() 改成  getFragmentManager() 就好;而要從 2.x 的版本開始支援,便要記得有  android-support-v4.jar 這個函式庫。

再來, add(R.id.container, new PlaceholderFragment()) 這段程式碼是指,我們要在  R.layout.activity_main 這個介面裡 id 為 R.id.container 的 frame layout (請打開 activity_main.xml 就可以看到),新增一個名為 PlaceholderFragment() 的 fragment 物件。而 layout 元件的宣告,也盡可能的習慣在 PlaceholderFragment 裡的 onCreateView  處理,以這個例子來說,語法大概就是像: (TextView) rootView.findViewById(R.id.textId) 。

  • Project Library

另一個新加入的東西是名為 appcompat_v7 的專案函式庫,這個是官方在 2013 年推出的 ActionBar 函式庫,各位也可以參考拙作「Android – ActionBarCompat (AppCompat) 的基本套用」。也算是一統江湖上流傳的各種 actionbar 甚至是 Navigation Drawer 的函式庫,讓操作的方式一致化。

可是,這樣看來,這個函式庫讓我們看到的好像也只有讓本來繼承的「Activity」改為「ActionBarActivity」而已。但若是大家有先實際將新專案執行在 2.x 的機型上的話,便可以看到我們不用再多套用什麼東西,就能在 2.x 的機型上看到 3.0 以上的版本才能看到的 actionbar 了。再進階一點的話,在建立新專案時,我們於最後一個動作稍微做點改變,如下圖:

Navigation Type: Navigation Drawer

Navigation Type 改為 Navigation Drawer ,建立完成後,會在 layout 目錄中看到多一個名為 fragment_navigation_drawer.xml 的介面檔案,而這也就是我們在有遵守官方設計指南的 APP 中,能看到的側邊欄,至於 navigation drawer 的操作,也請各位參考拙作「Android – Navigation Drawer 實作」。

當使用 navigation drawer 的類型建立完後,會發生專案被打上紅色的叉叉了,不過別擔心,順著 IDE 的畫面資訊找進去,可以看到錯誤是在  NavigationDrawerFragment 這個原始檔裡,如下圖:

Create Error: Navigation Drawer Type

嗯~就是這麼單純,多了一個「分號」@@,移除他就好了。

以上,大概是對開發者來說,比較有感的改變吧。從這邊也可以看到官方希望開發者能夠將 android app 打造得更貼近設計指南的想法,像是 actionbar、navigation drwer 等。

接著,再討論一個較為特別的狀況,現在更新後,我們只要每增加一個專案,就會增加一個「appcompat_v7」這個函式庫專案。只要存在這個函式庫專案,並且同名的話,他就會以「appcompat_v7_n」(n 為從 2 開始遞增 1 的數值) 這種方式命名。

appcompat_v7_n

其實還滿煩的 XD,不過,這也是一種貼心的設計,避免蓋掉原本的專案。若是您的專案都沒有動過,其實可以將多出來的移除,把其他會用到 appcompat_v7 的專案,將他們的 Library 改指向同一個就好了。

最後,也許有人會問說:「我可以不要這個專案嗎?」

答案是~可以的,當您在建立專案時,將專案的最低支援拉到 API 14: Android 4.0 即可。

其實,站在筆者個人立場,會跟各位說,我們可以的話就盡量依 android 官方的設計指南去做吧。畢竟在筆者撰文的這個時間, 2.x 的裝置,在官方的統計數據,還佔了兩成的數量,讓 app 可以向下支援,在這個時間點來看,好像也是必要之惡。

最後也是希望看到本篇的朋友們,盡可能拋棄 iOS 式的設計吧,這是 android 平台,官方也大力的在推動屬於 android 的設計指南,相信要遵循並請設計師設計一套符合指南又有質感的介面,應該也不會相當困難。而這些元件其實我們是可以對之進行設計、改變的,而官方在 android 的 play store 上,也不斷地在推薦符合設計指南,又有設計感的 android app 可以參考。所以,也不用擔心自己的 APP 會跟別人長得一樣,只要有良好的設計,相信也是可以做出很不一樣,並且有質感的 android app 來。

 

本部落格採用創用CC 姓名標示-非商業性-禁止改作 3.0 台灣 授權條款授權,如欲轉載請記得註明「莫希爾(Mosil) 手札

Loading Facebook Comments ...

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *