也就是在 apps.facebook.com 上所有的網站都算是。
之前想要玩 android ，
不過 android 的版本實在是變得太快了，
連買手機的人都可以感覺得到，
想要著手開發程式更是覺得困擾，
想說等它穩定一點再來玩玩，
就先跳到 facebook了。
沒想到 facebook apps 變動的更快，
而且連官方說明也是非常的簡略，
並且官方曾經公佈的 api 也很容易就又全盤的推翻，
實在是很意外，
曾經挾著數億會員而公佈標準的公司，
這種官方文件說明有點讓我傻眼了。
首先，
經過了幾個波折，
目前繁體中文的書籍，
我找得到的只有2本。
其他如果真的很有閒又有錢的話，
也是可以買一本介紹使用者介面的書來翻一下，
雖然只要認真的玩個幾天，
就知道 facebook ui 了，
但是這一類的書還不少，
所以請大家努力消費，
刺激台灣的內需市場。
如果想要買關於 facebook 行銷的話，
我覺得就不用了，
因為這不是看個一、兩本書就可以理解的，
重要的是對於網路的熟悉度。
我是用 php 當作畫布頁的，
當然還有 使用了 javascript SDK，
其他的申請應用程式流程，
就上網搜一下就有了。
iframe & fbml
不過先來講一下應用程式的兩種方式，
一種是 fbml ，
一種是 iframe。
fbml 就是在你的網頁中使用類似於 html 的 fbml 標籤，
然後在應用程式在 facebook 的伺服器就會去取得標籤，
重新把 fbml 改寫成 html 的方式呈現。
而 iframe，
真的很好理解，
就和 html 中的 iframe 是一樣的東西。
上述的2本書都有提到 iframe 和 fbml 之間的不同，
不過都是讓人有聽沒有懂。
而且2者都寫了 iframe比 fbml 容易學，
其實我覺得 fbml 比較容易學，
原因就是只要照著 fbml 操作，
呈現出來的東西是固定的，
即然固定…不就是比較容易嗎？
不過之所以有「iframe比fbml容易」的說法，
應程是指 iframe 不需要再另外使用 fbml，
直接使用 html 就可以了。
所以我一直被上面的說法誤導了，
等我都試過2種之後，
有以下的幾點心得。
- fbml 是由 facebook 伺服器再幫忙編譯過的，所以風格和 facebook 網站非常相近，幾乎就是一模一樣；由此，如果是想要擁有自己風格的網站，就直接使用 iframe，因為選用了 fbml 開放，還需要再由 css 去調整，等於是加了一道手續。
- iframe 在寬度在官方文件中的公告是 760px，不過萬一超出來，各家瀏覽器預設的 scroll 寬度至少需要再加 15px ，算於是作業的範圍只剩下 745px。我試過了 ie、firefox、chrome，最寬可以使用到730px沒問題，不過為了美觀，我都以720px 去設計。其他如opera、safari這2應該相去不遠。
- fbml和 iframe 都需要由 api 去取得使用者資料，這一個判斷式通常是
if(is使用者){ 進入程序; } else{ 顯示登入網頁; }在官方 developer 的程式設定中，
就有範例可供參考。
不過隨著 php 環境的不同，
還是有一些需要調整的地方，
最重要的是… - curl
- json
- session 以上應該是 PHP 伺服器必備的， 不過我試過幾家免費php虛擬空間服務， 都可以讓我們無法開放 facebook， 不知是故意或是巧合。 如果無法使用， 試試把 php 的 session_start(); 用上。
- 在 fbml 中，
只要一經過認證，
無論是轉到應用程式的哪一頁，
都可以記錄使用者的session。 - 在 iframe 中利用官方範例的 rest class ，
也可以記憶使用者，
不過有少數 session 會因環境的關係無法由 api 記憶，
這時候自己寫一個會比去了解 facebook class 還要快。 - 在 iframe 時這可以利用一個 xhtml技術，
就是做用 javascript 把部份的 fbml 標轉譯在 iframe 之中，
不過可以轉譯的標籤並不是全部的 fbml。 - 基於官方網站將在今(2011)年第一季停止新應用程式設定為 fbml 版，
所以我會直接選用 iframe 作為所有應用程式的方式。
多重方法的困擾
有很多方式可以開放 faceboook 應用程式，像是我們常玩的 flash 遊戲即是，
基本上 facebook 只是提供基本資料給應用程式，
其他工作都是由應用程式自己去作業的，
像是 flash 遊戲的話，
最重要的是使用者認證之外，
還有就是朋友清單、發佈權限，
除此之外…都和 fb 沒有關係了。
所以幾乎世界上和 web 有關係的程式都可以開放 fb應用程式，
像是官網有列到的 php、python、javascript、ios、android，
還有官網沒列到的…太多不想寫。
決定要用什麼語言來寫並不困難，
畢竟常人了不起學了1、2種語言，
說好是常人的嘛！
不過世界上還是有很多精通10幾種語言的怪才，
(畢竟邏輯是一樣的)
怪才的困擾讓怪才去承擔就好，
我只會一種不太在行的 PHP，
所以完全沒問題。
問題是在現在正是 facebook 應用程式換季大拍賣之時，
就是舊的還可以用，
新的也可以用，
不過我個人認為…要嘛都用舊的，
要嘛都用新的，
不然組合起來，
原始碼實在是亂到一個極限。
新的 api 支援文件實在精略，
舊的一樣精略，
不過網路資源集中在舊的 API，
但是舊不如新，
所以我一開始就盡量採用新的 API。
新的 API 如 graph api、javascript SDK、 dialogs，
舊的有 Old REST API、Old JavaScript Client Library…等，
半舊不新的如 FBML->不建議使用的，
所以說呀！
很多方法可以用，
上網 google 時…就很難指定新舊之分了。
不是我不會用搜尋…是關鍵字都很接近。
- 官方的範例程式，
裡面拉拉雜雜的用了很多技術，
例如說明文件所指出的 Old REST API、Old JavaScript Client Library(最新的稱為 javascript SDK)，
在我開始準備時，
官方文件已經指出不建議使用 REST 和 JavaScript Client Library，
所以我直接就不考慮了。 - 現在使用的 graph 和 rest 相比，
rest 多了很多功能，
像是在 facebook 使用者的個人牆上自定一個區塊，
或是可以多增加選單之類的，
現在多不支援了，
所以我直接使用 graph api。 - 另外 fql 是應用程式可以先向系統要求一些資料，
如使用者的朋友表列之類的，
但只限一次。
取得使用者的授權之後，
使用 graph 也可以無限次數向系統要求回報使用者個資，
所以也比 fql 好用。 - 取的使用者的大頭照十分重要，
因為「大頭照」與其代表的「人」是 facebook 組成的重要單位，
所以我會一直讓應用程式盡可能使用「大頭照」來替代使用者自己和他的朋友，
fbml和 graph都有很快的方法。 - 身為一個應用程式，
瘋狂的讓使用者 PO 文到他自己及朋友的頁面留言十萬分重要，
畢竟這是宣傳應用程式唯2的方式。
另一個方式是花錢買廣告。
不過所有的po文都應用由使用者同意後執行，
不然狂轟猛炸的誰受得了，
馬上會被 fb 停權。
學習的流程
我來講一下我個人認為需要學習的東西：- 使用官方範例，看一下裡面到裡是發生什麼事了。
- 一定要用 iframe，這樣引用 js 的時候會比較自由。
- 使用 graph api，並且試著查詢所有的資料，就知道 fb 也沒有給我們很多東西。
- fb 只是幫我們認證使用者，並且跟我們講他是誰，有哪些朋友。
- fb 中請求使用者授權給應用程式取得或是代發訊息的方式，有很多種，只需要學習一種，不然很浪費時間。
- 在 iframe 中最重要的是不要重覆 redirect回facebok，不然卡在哪裡，如果是使用 js 轉頁的話，在 ie 中好像會出錯，又是ie。
- 另外不相干的事，使用uml，加速架構程式，因為 facebook 可以提供的真的不像想像中的多，所以加上自己的資料庫是需要的。