個人覺得Facebook Platform稍微有點困難的地方在於起步的時候, 因為要先理解整個App平台的架構包含一些名詞與App的各種驗證機制, 一但跨過了這些階段之後, API的操作其實就相當的直覺了, 畢竟我認定API的定義就是應該我代參數給你, 你就乖乖的回我該有的資料(Facebook API回傳資料是JSON), API有問題就發信去轟炸Facebook的龐大工程師群們.
<script src="http://static.ak.connect.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php" type="text/javascript"></script>
Platform Live Status, 一個主要是提供給App開發者的工具, 聚合了目前Facebook Platform上諸多重要資訊包括
Facebook平台狀態
最近發生的問題
Facebook API的平均回應時間表
錯誤記數
Deceloper Updates, 這裡會羅列出跟應用程式開發相關的各項消息, 包含即將釋出的新API, 即將Deprecating的功能或API, 經過強化(Refactoring)或修正(Modified)的API功能…etc
因為整個頁面上看起來相當直覺, 所以也就不多說了, 就直接進到我想談的主題上吧, 那就是Facebook的Bug Trace System
於Top Live Platform Bugs區塊中點擊任意一條Bug之後會連結到如下的頁面
點選log in連結會進入到一個登入頁. 在這個頁面裡要求你輸入的並不是你在Facebook的帳號, 而是需要另外註冊, 而且在這裡可以看到Facebook的Bug追蹤系統是採用Bugzilla建構起來的
點選create a new account
輸入合法的email, 因為要進行驗證
點選信件中進行驗證的連結
按照指示輸入名字與密碼, 一切順利的話應該會看到如下圖所示的頁面
點選Log In進入Bug追蹤系統的登入頁面
登入成功之後, 就可以進入Facebook Bug追蹤系統的首頁, 如下圖所示
哈, 不過因為目前沒有關於Facebook App開發上的Bug要進行回報(我個人相信應該很快我就有東西要
回報了c(￣ܫ￣)a ), 所以待下一篇在進行回報流程的介紹.
步驟一
首先請先確認你於Facebook是處於登出狀態, 接下來當你連結到範例網站之後, Facebook JavaScript Client Libraries中的FB.Facebook.apiClient.requireLogin方法會檢查目前的URL中是否有session這一個參數, 假如沒有的話, 你就會被強制的重導向到Facebook的登入頁, 並在URL後方附加上許多相關的GET變數, 包含你的API Key以及Callback URL等等資訊.
http://www.facebook.com/login.php?api_key={應用程式的API Key}&extern=0&fbconnect=1&next={應用程式的Callback URL}&return_session=1&v=1.0&locale=en_US
步驟二
如果return_session設定為1, 當登入成功之後, 頁面會重導向回Callback Page URL, 而瀏覽器路徑會顯示如下, 在Callback URL後會附上許多GET參數
http://www.6yeah.com/fb_apps/js_demo/?session={%22session_key%22%3A%223.drvv_pxbWgtdgo1dqmbL9g__.86400.1256907600-638368594%22%2C%22uid%22%3A%22638368594%22%2C%22expires%22%3A1256907600%2C%22secret%22%3A%22BnOyOpZJ8E9VWhhJUKUn9Q__%22%2C%22sig%22%3A%225a1856eac374f80cd115f41b8c5db5b8%22}
如果於登入頁中我們手動的將return_session設為0, 當登入成功之後, 頁面同樣的會重導向回Callback Page URL, 但是瀏覽器路徑列中多了一個auth_token的參數
此時依舊會執行到FB.Facebook.apiClient.requireLogin並發現URL(document.URL)中有一個session參數
步驟三
回傳的session資訊會被寫入Cookie之中, 也就是說就算把Callback URL後面的參數都刪除掉再重新連線一次(ex:http://www.6yeah.com/fb_apps/js_demo/)你依舊會被FB.Facebook.apiClient.requireLogin判定為已登入的狀態.
小結
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head> <title>Cross-Domain Receiver Page</title> </head> <body> <script src="http://static.ak.facebook.com/js/api_lib/v0.4/XdCommReceiver.js?v2" type="text/javascript"></script> </body> </html>
最主要的變更在於最上頭導覽列下的Live Feed與News Feed
根據Facebook官方Blog的解釋其兩者的差別在於
Facebook在這一波的Redesign中還將一些使用者可能會感興趣的資訊加入了News Feed
之中, 包含朋友們被下標籤在那些相片上以及成為了那些頁面(Page)的粉絲, 加入了哪些
新朋友與群組以及RSVP了哪些事件…etc
先來實做一個簡單的範例, 一個極為簡單的Facebook App, 其唯一的功能只有列出User所有朋友的頭圖, 當然前提是User已經完成對App的授權(Allow)之後.
<?php
require_once('./facebook-platform/php/facebook.php');
require_once('./facebook-platform/php/facebookapi_php5_restlib.php');
$appapikey = '{API Ley}';
$appsecret = '{APP Secret}';
$facebook = new Facebook($appapikey, $appsecret);
$user = $facebook->require_login();
$friend_uids = explode(',',$_POST['fb_sig_friends']);
?>
<div style="border:solid 2px gray;padding:5px;float:left;clear:both;">
<?php
foreach ( $friend_uids as $uid ){
?>
<div style="float:left;margin:5px;">
<fb:profile-pic uid="<?php echo $uid; ?>" linked="true" size="square"/>
</div>
<?php
}
?>
</div>
結果會如下圖所示 進入Demo頁面
Facebook在應用程式的授權上, 講單純一點, 最主要的分別就是使用者是否曾經"Allow"過它, "Allow"這項動作決定了應用程式往後能跟使用者進行互動的程度, 以下就分各個不同的情境來觀察這事關重大的機制
除了Facebook Chat某個程度上突顯出了IFRAME模式的優點, XFBML的引入更讓IFRAME的運作更有效率. 在XFBML之前, IFRAME模式下如果要取得Facebook上的Social Content, 必須在你的應用程式伺服器上與Facebook Server進行多次的API Call, 然後才能將整合了Social Content的頁面內容回傳到使用者的瀏覽器中. 但是在使用了XFBML之後, 身為開發者的你可以直接在IFRAME呼叫的程式裡勘入FBML的Tags, 然後透過引入Facebook所提供的Javascript去掃描整個頁面的DOM去取出所有位於fb命名空間下的Tag進行 一次批次性的API Call去取得social Content然後進行DOM的替換, 而其他不屬於fb Namespace下的DOM元素將會在API Call完成之前就顯示於頁面之上, 甚至開發者還能將一些資訊於應用程式伺服器上進行快取, 連API call的Round Trip都能省了下來, 這樣的做法大大的提升了IFRAME的效能.
以下我嘗試拆解整個流程
對於初次開發Facebook App的Developer而言,最難以抉擇也模糊不清的應該就是究竟Canvas Page上要用FBML還是IFRAME來呈現您的程式,下面簡單的列出兩者之間的差別
但是IFRAME的模式在近期Facebook新增的Facebook Chat這項新功能上就顯著的優於FBML, 因為Facebook Chat這項功能在初始化時需要載入大量的Javascript與CSS, 雖然在第一次載入頁面的時候兩種模式都會需要耗用資源去執行Chat所需要的運算, 而且初始後這些Javascript與CSS會被快取在瀏覽器中. 但是FBML模式下的頁面每重新載入(page reload)一次就必須要耗用CPU資源去執行顯示Chat Bar的Javascript, 反之IFRAME模式下的APP就只會變更IFRAME裡面的頁面內容, 不會影響到Facebook Chrome已載入並初始化好的Chat Bar.
除了Facebook Chat某個程度上突顯出了IFRAME模式的優點, XFBML的引入更讓IFRAME的運作更有效率. 在XFBML之前, IFRAME模式下如果要取得Facebook上的Social Content, 必須在你的應用程式伺服器上與Facebook Server進行多次的API Call, 然後才能將整合了Social Content的頁面內容回傳到使用者的瀏覽器中. 但是在使用了XFBML之後, 身為開發者的你可以直接在IFRAME呼叫的程式裡勘入FBML的Tags, 然後透過引入Facebook所提供的Javascript去掃描整個頁面的DOM去取出所有位於fb命名空間下的Tag進行 一次批次性的API Call去取得social Content然後進行DOM的替換, 而其他不屬於fb Namespace下的DOM元素將會在API Call完成之前就顯示於頁面之上, 甚至開發者還能將一些資訊於應用程式伺服器上進行快取, 連API call的Round Trip都能省了下來, 這樣的做法大大的提升了IFRAME的效能.
所謂的Facebook應用程式的運作過程大致可以拆為六個步驟
