翻了一下舊資料，自己動手寫Android程式已經十二年前啦
當年有寫了一個很簡單的連線程式，在工作上協助Debug
然後也一路挑戰到Java的JNI(Java Native Interface)運作
(撰寫Android NDK程式)
不過終究是與工作相關性太低，想寫的東西，人家開發的都弄得比自己好，還免費
弄完那一個後就沒有繼續進行開發
即便中途還有再想著要重啟，但一安裝完Android Studio看著那陌生不已的介面
還是又默默地移除它，下次再說
最近，看著Google也推出了，用嘴(描述)就可以寫程式的Antigravity後
就又非常有興趣想要切入
因為用描述寫程式，可以不用太深入語法問題，只要專注於程式結構與目標
尤其我對Android舊官方語言的Java已經不是很熟，新推的kotlin更陌生
以往經驗來說從做中學是最速成，而且AI還可以帶教學說明細節
就決定來寫一個想做的APP
只是剛好看到Antigravity出狀況把人家的D槽給砍了
(Google開發平台Antigravity爆嚴重事故 用戶硬碟被無預警格式化)
加上它不是Android專屬的開發環境
無法預覽UI的板面，模擬執行，還有看LOG
最終還是使用Genimi+Android Studio進行開發與學習(？)
(以下文多沒有程式碼與圖像)
對，學習打了個問號
因為一開始我覺得不太算學習，算是在看戲
雖然說也是有加減學一些東西，不過其實大部分都在看Genimi3在表演
看它怎麼只靠著我的提示，還有從其它寫好的APP截圖，把程式碼給寫出來
而且幾乎都能好好執行，就算有問題，也是再描述一下就可以解決的
真的是好好體會一下什麼是之前正夯的Vibe Coding
不得不說，！！！超爽的！！！
讓我在第一次使用的那兩天都用的非常開心
不過Vibe Coding使用後的感想，就跟Genimi描述的一樣
是個好用的工具，可以提供程式專案初期快速建構的原型
甚至對我可以說是「神速」的等級
可是因為我對kotlin與android開發的方式不熟
所以也像Genimi說的，無底層知識，難以維護或解決深層問題
寫到一半卡住時，有兩次還是要讀懂程式碼才知道發生什麼狀況，然後才能解決
因為產出其實沒有明顯的錯誤，但不符合我的需求，怎麼跟AI說都不聽，只能自己來
但在能讀懂程式碼前，我還是在Vibe Coding中有所發揮啦
眼看Genimi把一堆程式碼都擠在一起寫(畢竟一開始又沒叫它分開寫)
意識到未來維護還是擴充有可能很麻煩，很初期就下令以朝專案分工的方式分類切開
如果初期沒這麼搞，後面其實擴充上就很麻煩了
在看懂程式碼可以自己改後，用Vibe Coding的另一個問題就出現了
有時候自己改(微調)比較快，然後程式碼難以再用描述的寫下去
因為我自己改了後，這產生了衝突
就算我上傳我改好的程式碼到同一對話串
AI還是不理我，繼續用它自己產生的繼承下去寫
然後我也開始覺得Genimi在網頁上跑起來怪怪的，跑起來有點慢
AI的問題AI解決，問完Genimi後，答案很明確
同一對話串越長，吃記憶體越兇，然後效率也不好
要開新對話重來就可以解決
至於如何繼承舊的對話串記憶，當然要先請舊對話生出記錄文件
而程式碼的部分，很單純，就是收集所有的程式碼與檔案架構產生一個txt檔後
就可以突破Genimi檔案數量的限制(最大上傳10個檔案)，讓新對話串知道之前的所有程式碼
同時如果程式碼手動有修改到的，也可以趁這時候上傳
上傳後，AI會問新開發要依新的程式碼，還是舊的對話記錄，這時就可以選擇朝新方向前進
以上算是Genimi的部分
回到技術的主體，Android程式設計
首先講一下現在Android的官方主推語言Kotlin還有新的板面配置Jetpack Compose
切入閱讀kotlin程式碼算是沒什麼太大的障礙
反正，函數還是函數，只是換成fun，變數還是變數，只是有var與val
物件還是物件，class仍然是class，if else還是if else
講的輕浮一點就像上面這樣，似乎只有關鍵字不同，甚至有的根本一樣
當然細部上使用就不完全一樣了，尤其是var跟val的差異之奇特
一開始以為只是沒const跟有const的區別
但在Mutablelistof的使用下，就算是val也能重新賦值，這對我來說一開始難以理解啊
不是都定為常數不動了，還能給新數值？
總之，Genimi邊寫，我邊學，其實一路以來大多也都是這樣在學程式的
想不出來就先照著複製，然後從修改中理解那個規則，進而再吸收成自己的東西
不過相較於Kotlin的好入門
新的UI設計方式Jetpack compose就真的讓我頭痛了好一陣子
難以理解啊，為什麼要用類程式碼的方式寫？然後還沒辦法「簡單」的看到配置
所以一開始雖然語言是用Kotlin，但版面還是用XML
用XML版面配置，很好懂啊，畫什麼是什麼
新的還不是一樣要畫(寫出來)，然後還更麻煩再加一堆程式碼
只是最終還是轉新的Jetpack Compose進行開發
會轉的原因是，開發途中搜尋Jetpack compose的文章，發現2020年就有繁中介紹的資料
從2020到2025途中歷經幾次Android改版，Jetpack Compose都沒被換掉
代表這東西真的有它獨到之處，那就邊寫邊學吧
就這樣抱著疑惑跟它奮戰了兩週左右，透過實戰才理解好用的點在哪裡
首先就是它吹捧的，直接在版面處理顯示邏輯
雖然這功能的缺點就是設計UI的人也要懂程式
但優點很顯著的，讓原本程式只專注在處理資料，不用再管要讓UI怎麼變了
而所有顯示都集中到負責顯示的程式碼上，一目了然，也方便修改與變化
整個程式碼也因而變得清爽簡潔
預覽板面的部分，有使用變數顯示的地方需要給資料才能用@Preview顯示
只有固定資料，像是Label之類的顯示可以直接用@Preview秀出來
一開始覺得這樣麻煩，懂了，會用以後，反而覺得比舊的XML好
因為它可以在還沒編譯階段就看到變數給值後的結果
而舊的XML，如果有用到變數給值的話，一定要開模擬器後才知道長什麼樣子
固定版面可能還沒什麼感覺，浮動板面的話，就是超大的福音
而且也不用強制全寫在同一個檔案
一樣可以一頁一個檔案，維護修改上也是很方便的
目前開發算是順利啦
完全是個可以運作的APP，前前後後也不過花了三週
更嚴格地說，應該不到24小時吧
開發算超快的，只是隨之而來的小問題也不少
這點沒辦法，畢竟開發這事，一直都是這樣的
很多時候只有個大方向，對於細節總是沒辦法一開始就想得很徹底
剩下就是一直朝目標持續修正啦
現在有了AI就更方便啦，只是還是得對目標的程式語言有一定的了解
這樣針對要修改的地方描述才能夠精確
愈精確，AI的反饋才會愈正確，這是接下來的努力方向
加油，還有個幾天，新曆過年前把成品搞出來
沒有留言:
張貼留言