當最煩人的session問題解決之後,就該試著跟Facebook要點資料來瞧瞧了。
這一篇會大概解說一下Flash api如何跟Facebook索取資料的動作。
基本上Facebook Flash api在這方面的流程很簡單,其實就是先產生一個「命令」然後把這個命令丟給Facebook類別往外post出去就好,要做什麼動作就去產生相對應的命令類別就可以了。
所有的命令類別都繼承com.facebook.net.FacebookCall,有興趣的人可以直接去說明文件看這個類別,它就有列出所有它的子類了。
說明文件在這邊:
http://facebook-actionscript-api.googlecode.com/svn/release/current/docs/index.html
幾乎所有的命令類別都是在com.facebook.command的package裡。
相對於發出命令的簡易,Facebook Flash api在接收資料時的繁複卻是不可思議到讓人惱怒。有時一個命令發出後,收到的資料型別居然要層層解析,動輒用到四五個類別,再加上說明文件的陽春,所以往往需要不斷的一直trace,最後才能得到你想要的資料。
這個部份待會的code就會見識到…。
接下來,我們繼續接著上一篇的去修改,Html的部份就不用動了,這次沒動到javascript,所以只改ActionScript。
我們這次要從Facebook取得自己的個人資料,因此在上次的connectHandler裡驗證成功後馬上執行這個動作:
使用到的是com.facebook.commands.users.GetInfo;這個類別。
GetInfo這個類別是用來跟Facebook索取會員資料用的,它可以允許一次索取很多人的,因此第一個參數是會員uid組成的Array。然後也可以指定要索取哪一些欄位,這些欄位的定義都在GetInfoFieldValues這個類別裡的靜態屬性,一樣是Array的形式,如果你要索取所有的欄位,那就直接帶入GetInfoFieldValues.ALL_VALUES就好,它本身就是一個Array型態。
接下來就是要處理事件回傳的結果:
開發Facebook application時,一直trace回傳的FacebookEvent會是一個好習慣…。FacebookEvent的形態基本上會是這樣:
[FacebookEvent type="complete" success=true data=[object GetInfoData] error=null]
type就不用講了,要注意的是success及data。
success就只有true或false,通常都是true,除非你跟Facebook之間的connection斷了,那success就會是false然後error會有東西。
data則是主要的資料,data會依照你命令的種類不同而有不同的資料型態,理論上命令的類別都是在com.facebook.command.xxxx的package裡,相對應的資料型態類別則會放在com.facebook.data.xxxx的package裡。
也就是送出命令時是去command裡找,接收到事件時就回來data這邊找。
這次的命令是com.facebook.command.users.GetInfo,收到的資料是com.facebook.data.users.GetInfoData。
但是其實討人厭的就在這邊,光一個GetInfoData還不夠,真的資料是存在GetInfoData類別裡的userCollection屬性 (com.facebook.data.users.FacebookUserCollection類別),所以只好不斷的轉型別把它轉成陣列,最後陣列裡儲存的是一個一個的com.facebook.data.users.FacebookUser型別的資料…。
因此光解析個人資料就要動用三個型別… 加上發出命令的類別的話一共是五個,老實說,說明文件夠好的話這都還ok,偏偏不是,所以開發Facebook application的話一直trace會是一個好習慣。
當熟悉它的運作方式後,十分建議自己寫一些類別來整合簡化這些步驟。
如果沒意外的話,當登入後就可以看到自己的名字跟照片顯示在畫面上了。
下一篇
Facebook Flash Application開發心得(4) – Iframe的架構下取得Session
2009年8月20日 星期四
2009年8月19日 星期三
FP9操作影格造成child MovieClip裡的動畫暫停的bug
這問題是奶綠前兩天發現的。
通常我們很習慣在操作動畫時,有時為了要控制快轉倒轉,常常會使用nextFrame()及prevFrame(),而且通常是配合Event.EnterFrame來使用。
但是奶綠發現,如果這個MovieClip有一個child MovieClip自己裡面有動畫在跑的時候,這樣的操作會造成這個child MovieClip的動畫「停止」,等到parent不再受到nextFrame()及prevFrame()的命令時,child MovieClip才會繼續跑它的動畫,因此就造成了不同步的狀況。
我自己試驗了一下,其實child MovieClip裡的動畫不是真的停止了,而是「跑得比較慢(應該說非常慢)」而已。
我猜可能是因為nextFrame()及prevFrame() (gotoAndStop()也一樣)所花掉的效能讓Flash Player無法同時處理child MovieClip的影格,因此造成child MovieClip的動畫delay。
目前似乎無解。
但是奶綠發現Ticore之前有提到在Flash Player 10之下這個問題就不會再發生。
也許是Flash Player 10有發現這一點並做了修正了吧?
通常我們很習慣在操作動畫時,有時為了要控制快轉倒轉,常常會使用nextFrame()及prevFrame(),而且通常是配合Event.EnterFrame來使用。
但是奶綠發現,如果這個MovieClip有一個child MovieClip自己裡面有動畫在跑的時候,這樣的操作會造成這個child MovieClip的動畫「停止」,等到parent不再受到nextFrame()及prevFrame()的命令時,child MovieClip才會繼續跑它的動畫,因此就造成了不同步的狀況。
我自己試驗了一下,其實child MovieClip裡的動畫不是真的停止了,而是「跑得比較慢(應該說非常慢)」而已。
我猜可能是因為nextFrame()及prevFrame() (gotoAndStop()也一樣)所花掉的效能讓Flash Player無法同時處理child MovieClip的影格,因此造成child MovieClip的動畫delay。
目前似乎無解。
但是奶綠發現Ticore之前有提到在Flash Player 10之下這個問題就不會再發生。
也許是Flash Player 10有發現這一點並做了修正了吧?
Facebook Flash Application開發心得(2) - FB Connect - 接上Flash
使用FB.init初始化Facebook之後,除了要藉由javascript的api來應用Facebook的一些功能以外,其實最重要的就是要取得Facebook的登入session資訊。
由於Facebook的判別登入權限是由很多參數所記錄及驗證的,flash的api也需要這些參數來進行資料的傳遞,因此取得這些參數是很必要的。
這些參數裡有兩個值是最重要的,分別是session_key及secret,前者是此次使用者登入的session值,後者則是facebook動態產生的secret值,這個secret值跟Application設定時所看到的secret不太一樣,基本上Facebook官方建議我們不要將Application設定畫面上的secret值直接寫在程式裡,因為很容易被有心人破解取得,所以Facebook的javascript api在進行驗證時會自己從Server取得一組由Facebook動態產生的secret來使用,但是Flash api就辦不到,必需要將secret寫死在flash或是flashvars裡,這也就是要使用javascript api來進行登入動作的原因之一。
另一個使用javascript api的原因就是session的取得,雖然官方的flash api的文件裡建議我們使用com.facebook.utils.FacebookSessionUtil類別來統一處理session,文件裡說FacebookSessionUtil會自己判斷是該使用DesktopSession、JSSession或是WebSession,但是我發現FacebookSessionUtil是有bug的,即使在網頁上跑flash,它仍然會使用DesktopSession來做為session的處理類別,但是這麼一來一但當頁面被refresh時,flash將會失去session的相關處理能力,需要再次重新登入一次,對使用者來說這會變得非常的不友善。
雖然說FacebookSessionUtil有這種缺點,但是它在iframe架構的application裡卻可以運作正常且很好用,因此關於FacebookSessionUtil的部份就留到iframe的時候再講,目前為止在FB connect的部份我將會直接使用WebSession。
現在要將flash放入到FB connect的application裡,會延用到上一篇的東西,但稍作改寫,由於我假設我們是要開發全Flash的application,因此我也將登入Facebook的按鈕從html裡搬到flash裡。
整個主要程式的運作流程會是:
1. 載入swf。
2. Swf呼叫javascript進行FB.init。
3. Javascript去跟Facebook驗證使用者是否已經登入。
4. 若是已經登入,javascript取得必要的session_key及secret,並將這兩個值傳給swf。
5. Swf依照這兩個參數進行WebSession的初始化。
一、 HTML上javascript的改寫:
應該很直覺,不用再多做解釋。
二、 Flash裡的處理:
因為code不算多,直接全部po出來,加上註解。
三、 其它解說:
在Flash裡,我捨棄了使用Flash api裡的login method,而決定呼叫javascript來處理的原因,是因為如果沒有將application secret傳出的話,facebook.login()不知為何一直無法正常運作,但是如果我把application secret寫入,那就又失去了安全性,因此我才又將登入動作交還給javascript處理。
FB.Connect.requireSession有兩個參數,第一個是登入後的callback function,由於我們已經實作了ifUserConnected,因此這個function可帶入null,第二個參數是決定是否要另開一個視窗當登入窗口,通常這個參數可以忽略,在純html的狀況之下呼叫FB.Connect.requireSession一定會另開,不過如果這個動作是由flash所觸發的話,預設值會是直接蓋在頁面上,可是flash的wmode沒有設成transparent的話flash反而會蓋在登入畫面之上,因此我特別將第二個參數設成true來強迫它另開一個視窗出來。
更正:經過實驗,似乎只有在IE才會跳出新視窗,FireFox裡好像不管怎樣都是跳lightbox...
這個程式的整個流程還沒有完全的完整,但是已經有考量到使用者是先登入再到這頁面或是來到這頁面才進行登入動作的兩種狀況,在一般自己的網頁上來處理應該是足夠了,但是還沒處理到使用者半途登出Facebook的情況,這一點可以事後再繼續補足,至少最麻煩的session取得已經解決。
接下來我也許會先介紹幾個從Facebook取得資料的類別,然後就可以再回過頭來介紹iframe的架構,其實iframe與FB connect最多最大的差別就只在於session的取得,其它的都大同小異。
下一篇
Facebook Flash Application開發心得(3) - 由Flash Api從Facebook取得資料
由於Facebook的判別登入權限是由很多參數所記錄及驗證的,flash的api也需要這些參數來進行資料的傳遞,因此取得這些參數是很必要的。
這些參數裡有兩個值是最重要的,分別是session_key及secret,前者是此次使用者登入的session值,後者則是facebook動態產生的secret值,這個secret值跟Application設定時所看到的secret不太一樣,基本上Facebook官方建議我們不要將Application設定畫面上的secret值直接寫在程式裡,因為很容易被有心人破解取得,所以Facebook的javascript api在進行驗證時會自己從Server取得一組由Facebook動態產生的secret來使用,但是Flash api就辦不到,必需要將secret寫死在flash或是flashvars裡,這也就是要使用javascript api來進行登入動作的原因之一。
另一個使用javascript api的原因就是session的取得,雖然官方的flash api的文件裡建議我們使用com.facebook.utils.FacebookSessionUtil類別來統一處理session,文件裡說FacebookSessionUtil會自己判斷是該使用DesktopSession、JSSession或是WebSession,但是我發現FacebookSessionUtil是有bug的,即使在網頁上跑flash,它仍然會使用DesktopSession來做為session的處理類別,但是這麼一來一但當頁面被refresh時,flash將會失去session的相關處理能力,需要再次重新登入一次,對使用者來說這會變得非常的不友善。
雖然說FacebookSessionUtil有這種缺點,但是它在iframe架構的application裡卻可以運作正常且很好用,因此關於FacebookSessionUtil的部份就留到iframe的時候再講,目前為止在FB connect的部份我將會直接使用WebSession。
現在要將flash放入到FB connect的application裡,會延用到上一篇的東西,但稍作改寫,由於我假設我們是要開發全Flash的application,因此我也將登入Facebook的按鈕從html裡搬到flash裡。
整個主要程式的運作流程會是:
1. 載入swf。
2. Swf呼叫javascript進行FB.init。
3. Javascript去跟Facebook驗證使用者是否已經登入。
4. 若是已經登入,javascript取得必要的session_key及secret,並將這兩個值傳給swf。
5. Swf依照這兩個參數進行WebSession的初始化。
一、 HTML上javascript的改寫:
應該很直覺,不用再多做解釋。
二、 Flash裡的處理:
因為code不算多,直接全部po出來,加上註解。
三、 其它解說:
在Flash裡,我捨棄了使用Flash api裡的login method,而決定呼叫javascript來處理的原因,是因為如果沒有將application secret傳出的話,facebook.login()不知為何一直無法正常運作,但是如果我把application secret寫入,那就又失去了安全性,因此我才又將登入動作交還給javascript處理。
FB.Connect.requireSession有兩個參數,第一個是登入後的callback function,由於我們已經實作了ifUserConnected,因此這個function可帶入null,第二個參數是決定是否要另開一個視窗當登入窗口,通常這個參數可以忽略,在純html的狀況之下呼叫FB.Connect.requireSession一定會另開,不過如果這個動作是由flash所觸發的話,預設值會是直接蓋在頁面上,可是flash的wmode沒有設成transparent的話flash反而會蓋在登入畫面之上,因此我特別將第二個參數設成true來強迫它另開一個視窗出來。
更正:經過實驗,似乎只有在IE才會跳出新視窗,FireFox裡好像不管怎樣都是跳lightbox...
這個程式的整個流程還沒有完全的完整,但是已經有考量到使用者是先登入再到這頁面或是來到這頁面才進行登入動作的兩種狀況,在一般自己的網頁上來處理應該是足夠了,但是還沒處理到使用者半途登出Facebook的情況,這一點可以事後再繼續補足,至少最麻煩的session取得已經解決。
接下來我也許會先介紹幾個從Facebook取得資料的類別,然後就可以再回過頭來介紹iframe的架構,其實iframe與FB connect最多最大的差別就只在於session的取得,其它的都大同小異。
下一篇
Facebook Flash Application開發心得(3) - 由Flash Api從Facebook取得資料
訂閱:
文章 (Atom)