pocket rpg dev page 1

test1

test2

test3

test4

留言

張貼留言

這個網誌中的熱門文章

AppScript如何串聯BloggerAPI

UrlFetchApp . fetch   這個物件與函數是呼叫BloggerAPI的方法。 因為BloggerAPI V3並不支援套件（即使是同為Google官方自己的服務），必須要使用URL API。 BloggerAPI使用的方式邏輯主要是.... [Blogger API URL] + / + [BloggerID] + / + [Blogger API code] + / + [BloggerPostID] 一般公開使用Blogger看到的Http網址上都是「部落格名稱」和「文章名稱」，要到編輯模式內的網址才會顯示「BloggerID」和「BloggerPostID」。 （這只是個Memo，如果有路人不小心點進來，可以自己實際操作看看就知道。真的，看一眼就知道。） 比較麻煩的是AppScript要取得「操作權限」的設定過程。 在Blogger的Google帳號下開啟「Google API Condole」。 建立一個新的API專案，並取得數字專案ID。要強調，是「數字」，不是「文字」。 在「API和服務」中，新增/開啟一項新的服務（BloggerAPI）。 在AppScript的「專案設定」中（一個齒輪形狀的按鈕），找到「Google Cloud Platform(GCP)專案」項目，在下面將數字專案ID加入。 這樣，這組AppScript就有操作BloggerAPI的權限了。 但實際上怎麼操做？（ StackOverflow說明與範例在此 ） 要呼叫BloggerAPI時，用下面這段作為Post資料與格式： var options = { method : "post" , contentType : "application/json" , headers : { Authorization : "Bearer " + ScriptApp . getOAuthToken ()}, muteHttpExceptions : true , payload : JSON . stringify ({ title : "Hello from Apps Script!" , content : "This p...
閱讀完整內容

factory模式 （建構子）

這其實應該算是「 constructor 」的衍伸。 因為factory模組要的就是如何產生物件實體。 如以下範例（取自「 壞蛋的密室 」）： class Symbol { final String name; static Map<String, Symbol> _cache; factory Symbol(String name) { if (_cache == null) { _cache = {}; } if (_cache.containsKey(name)) { return _cache[name]; } else { final symbol = new Symbol._internal(name); _cache[name] = symbol; return symbol; } } Symbol._internal(this.name); } 使用方式如下： var a = new Symbol('something'); var b = new Symbol('something'); assert(identical(a, b)); // true! 常識來說，constructor自預設「return 實體」做結尾，但Dart/Flutter的factory模組可以加在constructor中。 在constructor前面加上「factory」，同時必須要用「return返回實體」做constructor的結尾。 這樣的做法雖然在使用上很方便（不用再寫Factory模式），但在邏輯上和物件導向使用上，可能會帶來很嚴重的混亂。 最明顯的問題是：Factory模式並不預設return用來實作Factory的物件自己，總是會return一系列擴充了A介面或物件的A1/A2/A3/A4...。 如果物件自己就是Factory模式，那請問要怎麼返回子類別呢？ 這問題很奇妙。 因為這問題顯示了物件導向編譯程式並沒有想像中的符合人類的直覺或思考模式。 試想像一下：物件A在編譯的時候，要如何知道自己的子類別存在呢？ 但事實是：這樣的程式技巧確實存在。也就是說「編譯器能否編譯這樣的物件」決定...
閱讀完整內容