CM の CS 見聞

1. 編譯 idegen.jar make idegen 或 mmm development/tools/idegen/ 2. 產生 android.iml 和 android.ipr development/tools/idegen/idegen.sh 3. 在 android.iml 加入以下內容，避免載入不必要的模組（這邊只保留 frameworks 和 packages） <excludeFolder url="file://$MODULE_DIR$/.repo" /> <excludeFolder url="file://$MODULE_DIR$/art" /> <excludeFolder url="file://$MODULE_DIR$/bionic" /> <excludeFolder url="file://$MODULE_DIR$/bootable" /> <excludeFolder url="file://$MODULE_DIR$/build" /> <excludeFolder url="file://$MODULE_DIR$/compatibility" /> <excludeFolder url="file://$MODULE_DIR$/cts" /> <excludeFolder url="file://$MODULE_DIR$/dalvik" /> <excludeFolder url="file://$MODULE_DIR$/developers" /> <excludeFolder url="file://$MODULE_DIR$/development" /> <excludeFolder url="file://$MODULE_DIR$/device" /> <excludeFolder url="file://$MODULE_DIR$

前言 Zxing 是知名的條碼辨識函式庫，可以整合在 Android、iOS......等平台的 App 上。 網路上已經搜尋的到許多使用教學，不過在深度客製化（如自訂 layout）上，多半都是用修改原始碼的方式去實現。直接修改原始碼固然方便快速，但缺點就是當有兩種以上客製需求時，必須撰寫額外的判斷式去處理。以模組化的概念來看，這樣的作法不是很漂亮。 因此，本篇文章著重在運用繼承和撰寫 layout XML 檔的方式實作客製化。 自訂掃描介面佈局 Zxing 最簡單的使用方式是利用 IntentIntegrator 物件去呼叫掃描器並接收回傳的掃描結果，而缺點也顯而易見的是無法客製化整個介面佈局。 基本的客製化方式是自行在 res/layout 目錄下建立 XML 檔，然後加入 <com.journeyapps.barcodescanner.DecoratedBarcodeView> 元件。如此就可以讓掃描畫面呈現在 App 畫面的某個區塊，而不用佔滿整個畫面。 其中有些屬性可以再進一步客製化 DecoratedBarcodeView 本身的外觀樣式，常用的有： app:zxing_framing_rect_width=掃描框的寬度 app:zxing_framing_rect_height=掃描框的高度 app:zxing_scanner_layout=套用自訂的 layout 而 app:zxing_scanner_layout 套用的 layout 中必須要包含繼承自 BarcodePreview 和 ViewfinderView 的兩個元件才能構成一個完整的掃描器。 客製化掃描框樣式 ViewfinderView 負責描繪掃描畫面中的掃描框，我們可以繼承並覆寫它的 onDraw() 方法。 下面範例的頂端幾個變數和 onDraw() 方法中的 [Custom start/end] 之間的程式碼是我所增加的部份，其他是直接從原始碼複製過來的。 下圖是客製化的結果，在掃描框四個角落加上了橘色邊邊。 客製化掃描框位置 BarcodePreview 負責顯示相機拍到的畫面以及定義解析區域在畫面上的範圍大小（ 前面提到的 ViewfinderView 只是像濾鏡一樣覆蓋在

前言 從 Android 9 開始，App 的 SQLite 日誌模式預設採用 SQLite 在 3.7.0 版加入的 WAL (Write-Ahead Logging) 模式。 相較於原本的 TRUNCATE 模式，有寫入速度較快、讀和寫不會阻塞......等優點。 詳細內容可以參考 SQLite 官方網站，這邊就不詳述了。 Write-Ahead Logging 採用 WAL 前後的檔案結構差異 原先的 databases 目錄下有 *.db 和 *.db-journal 兩個檔案。 採用 WAL 的 databases 目錄下則改為 *.db、*.db-shm、*.db-wal 三個檔案。 交易模型 (Transaction Model) 日誌 (journal) 的主要目的是為了要讓 SQLite 可以支援「交易」(TRANSACTION)，當交易失敗或中斷時可用此檔案來還原。 而 SQLite 對於日誌的處理有兩種作法： 回滾日誌檔 (Rollback Journal)： 先將原內容則備份至 Rollback Journal 中，再將要異動的內容直接寫入 DB。當需要 rollback 時，再將原內容由日誌檔寫回 DB；若要 commit 變更時，則只要將該檔案刪除即可。 而 rollback 的日誌模式又可細分為 4 種：DELETE (SQLite 預設值)、TRUNCATE (Android 版 SQLite 預設值)、PERSIST、MEMORY WAL (Write-Ahead Log)：  作法與 Rollback Journal 剛好相反。原內容仍保留在原 DB 之中，但新的異動則 append 至 WAL 檔。而當 COMMIT 發生時，僅代表某筆記錄已 append 進 WAL 檔了，但並不一定有寫入原 DB (當 WAL 檔案大小到達 checkpoint 的閥值時才會寫入) 。如此可讓其他資料庫連結繼續對原 DB 內容進行讀取操作，而其他連結也可同時將異動 COMMIT 進 WAL 檔。 啟用/停用 WAL 在繼承 SQLiteOpenHelper 的 class 中覆寫 onConfigure 方法，加入一行指令就行！ 參考資料 https://

如果 Android App 有資料備份的需求，可以考慮使用 Google 雲端硬碟的服務。本篇文章會簡單說明一下實作必要流程與介紹官方工具的使用。

最近因為專案需求，進行了一些藍牙通訊的研究。 首先來看官方線上文件： Bluetooth overview - Connect devices 前面描述開啟藍牙或搜尋、被搜尋……等較為基本的部份先跳過。從連接裝置（Connect devices）這一節開始，首先要將兩個裝置配對，然後使用 BluetoothAdapter 的 getBondedDevices() 方法取得已配對的裝置資訊，並從中取出 MAC address。 接下來我們需要一組 UUID （通用唯一識別號）作為藍牙服務的識別碼。在網路上有許多 UUID 產生器，例如： https://www.uuidgenerator.net/ 。找一個喜歡的使用即可。 因為藍牙的連接模式是由一個 Client 端主動發起連線給被動監聽的 Server 端，因此程式碼需要分別撰寫 Server 與 Client 端的動作。 首先來看接收藍牙連接的 Server 端程式碼： 接受連接的步驟為： 調用 listenUsingRfcommWithServiceRecord(String, UUID) 取得 BluetoothServerSocket 調用 accept() 開始監聽連線請求 在 manageConnectedSocket(socket) 副程式中管理 socket 連線。這部份後面再詳述。 調用 close() 關閉監聽連線請求 然後是藍牙連接的 Client 端程式碼： 發起連接的步驟為： 調用 createRfcommSocketToServiceRecord(UUID) 取得 BluetoothSocket。 調用 connect() 發起連接 在 manageConnectedSocket(socket) 副程式中管理 socket 連線。 到這邊可以發現到，Client 和 Server 都在第三步驟調用了 manageConnectedSocket(socket) 副程式，但是官方線上文件並沒有進一步說明這個副程式的內容。 所幸我在官方範例程式中找到了藍牙連接的範例程式： BluetoothChat 從中得知，原來是要啟動另一個 Thread：ConnectedThread 而 ConnectedThread 的程式