Posts match “ facebook ” tag:

angular-easyfb v0.2.0 released!

http://github.com/pc035860/angular-easyfb

  • AngularJS $q promise support
  • Fix minified code run-time error

0.2.0 加入了 $q promise 的支援,因此 增加了在 view 裡面使用的彈性

更新:AngularJS 1.2.0 之後將 promise 在 view 中自動 unwrap 的功能 deprecate 了,因此支援 promise 可能未來並不會增加在 view 裡面使用的彈性。

API demo (promise version)

angular-easyfb v0.2.2 released!

https://github.com/pc035860/angular-easyfb/releases/tag/v0.2.2

  • setInitFunction() in configure block for initialization customization
  • Make $FB.Event.unsubscribe unsubscribes events properly

2014 的第一天修掉了一個可怕的 bug。

之前照著人家回報的 issue 做了一個 plunk,意外發現 $FB.Event.unsubscribe 竟然沒有作用(雖然那 issue 不是回報這個),查了 Facebook 的 doc 才發現 FB.Event.unsubscribe 需要帶上原本 call FB.Event.subscribe 時用的 listener function 才能夠順利運作。

老實說以目前的 implementation 要讓這件事可以 work 還蠻玄妙的,總之還是改好了 YA!
FB.Event 應該算是蠻常用到的 API ,出 bug 真是太可怕了...

angular-easyfb v0.3.0 released!

https://github.com/pc035860/angular-easyfb/releases/tag/v0.3.0

  • 可以自訂 FB JS SDK 的載入
  • 所有 Facebook social plugin 變成內建 directive,換句話說什麼都不用做就會 work
  • 承上,deprecate 之前為達相同功能所使用的 ezfbXfbml directive

加上 test 的二三事

其實推上 v0.3.0 的最後推手是加上了全部的 unit test spec... 來說說想加上 test 的原因吧!

angular-easyfb 這個 module 其實說來開發起來蠻麻煩的... 基本上從第一版寫完之後,後來我再繼續改都是用第一版的 demo plunk 做為依據,換掉其中載入在 GitHub Pages 的 script,改成載入另外的開發用版本。為什麼? 因為似乎在本地開 server 來做開發的話,Facebook JavaScript SDK 跑不起來(但老實說我沒有真的試過... 去 developer panel 裡改一些 domain 相關的設定可能會有機會吧)

不斷把程式碼貼來貼去的厭煩度終於在 v0.2.x 達到了巔峰。我知道寫了 test 之後,應該可以大大改善這情況,畢竟我不再需要載入真正的 SDK 來確保我所有的功能都可以正常運作(在 test 裡面 mock FB SDK 的 API 就好了),也就可以從來回剪貼程式碼於 Plunker 跟 Sublime Text 的循環中解脫了!

看著之前在 GitHub repo 的 README 裡面寫下的

TODO
  • test

心裡默默的覺得時機已經成熟,就差臨門一腳。詳見 AngularJS test 新手上路 (1) - 基本環境設定

自訂 SDK 載入,帶來新的可能

這版新增了可以自訂 SDK 載入的功能,讓這個 module 有了使用在 Apache Cordova (or Phonegap) 裡的可能。透過 Apache Cordova Facebook Plugin,只需要載入本地的 facebook-js-sdk.js 後再自訂一下觸發 FB.init() 的時機即可。

這個 Simple example 為例,與 AngularJS 及 angular-easyfb 結合之後要能夠順利 init 只需要加上

// angular config phase

.config(function ($FBProvider) {
  $FBProvider.setInitParams({
    appId: "{APP ID}", 
    nativeInterface: CDV.FB, 
    useCachedDialogs: false 
  });

  $FBProvider.setLoadSDKFunction(function ($document, $fbAsyncInit) {
    // 上面的 HTML 已經用 <script> 載入了 facebook-js-sdk.js,這邊就不用載了

    $document.on('deviceready', function () {
      $fbAsyncInit();
    });
  });
})

就可以順利運作了。 (相關 issue)

未來展望

angular-easyfb 作為一個讓 AngularJS 與 Facebook JavaScript SDK 合作更輕鬆且密切的 module,老實說 v0.3.0 已經接近它最後的樣貌了。現在整個 module 的彈性與方便性都好到一個不行!

結論,我真的不知道還要加什麼功能了... 所以這個 module 基本上應該會轉型為只修 bug 的狀態一直 maintain 下去,在這邊就先下台一鞠躬,謝謝收看。

angular-easyfb v0.3.1 released!

https://github.com/pc035860/angular-easyfb/releases/tag/v0.3.1

  • 內建的 social plugin directive 們支援套用動態字串參數

不知道算是「修 bug」還是「加 feature」

寫 directive 的給參數方式其實完全看到底想怎麼用,基本上我本人是沒有需要動態改參數的需求...
不過似乎有些使用者在切換 route path 之後就會發生參數沒帶到而無法顯示的情況(參數我想主要是 href 之類的),看來大家都很自然的把這些東西寫在 $scope.xxx 啊...

超難寫的 test

這個小改版,我大部分時間都花在寫 test 上了...
不過是餵個參數,竟然這麼難寫... 不知道是不是我自己想太多的關係

https://github.com/pc035860/angular-easyfb/blob/master/test/unit/social-plugin-directive.spec.js

angular-easyfb v1.0.0 released!

https://github.com/pc035860/angular-easyfb/releases/tag/v1.0.0

  • $FB service 改名為 ezfb
  • 一些 local 的 DI 也都改名了
    • $fbInitParams -> ezfbInitParams
    • $fbAsyncInit -> ezfbAsyncInit
    • $fbLocale -> ezfbLocale

就在前天,出現了一條 issue: Best practice: don't $-prefix this service

一看發現竟然是 Angular team 的 Brian Ford 大大...

原來是兩個多月以前有一個好心的路人覺得這 module 不錯用,經過自己的一番比較與研究之後(也有寫了自己的 FB service),似乎覺得可以把這個 module 擺到 Angular docs 裡面某處推薦的連結裡,於是他就發了一個 PR

Brian Ford 終於有一天審到這個 PR,就來 angular-easyfb 這邊逛了一下,發現我的 service 叫做 $FB,如果要擺入docs 推薦的連結似乎不妥,因為 Angular team 方面認為 $-prefixed 的 service 基本上是保留給 Angular native 的。

我以前不知道這回事,也看很多別的非 native module 用 $-prefixed 的 service 用得很過癮(例如 angularFireui-router),所以當年才會取了 $FB 這個直覺上跟原本的 FB 很搭的名字。

總之既然知道有 best practice 可以 follow,我就改一下好了。說不定還有機會擺進官方 docs 推薦連結 ㄆㄆ

另外因為是個 breaking change,版號直上 1.0.0 了。

angular-easyfb v1.1.0 released!

https://github.com/pc035860/angular-easyfb/releases/tag/v1.1.0

Facebook 似乎總是對開發者釋出善意,但我個人感覺實際上做的事情卻往往是不友善的...

幾個月前的 F8 大會上,Facebook 大動作想要讓他們的平台更迭系統化一點,終於推出了殺手級的改動 - platform versioning。於是很自然的也更新了一些原本 JavaScript SDK 的部分,這次 angular-easyfb 的更新基本上就是順應 Facebook 的野心...

續集: 週末長知識: Facebook Platform Versioning

週末長知識: Facebook Platform Versioning

f8.png

angular-easyfb v1.1.0 released! 中提到是為了這個 Facebook 的 platform versioning 而做了一次更新,所以這個 platform versioning 到底是?

還記得日前有新聞說 Facebook 將推出匿名登入功能嗎? 第一次聽到這消息真是超驚為天人,畢竟目前大部分 "Connect with Facebook" 的運作模式就是靠著取得授權之後的 Facebook user ID 來進行諸如登入之類的操作,如果當真是 "anonymous" 的話,表示基本上就拿不到使用者的真實 Facebook user ID (必須「不能知道那名使用者是誰」),一定會造成許多 Facebook 相關的登入功能崩壞。

為了上述這個,以及往後到來的革命性的變動,Facebook 可能發覺以目前的 API 更動速率沒辦法有效的讓他們快速將新功能推向開發者們。與其每次都要告知開發者們「必須 migrate」的時間點,不如推出一個統一的機制省掉這些麻煩...

於是這個 platform versioning 應運而生。

Tip: 一般來說最大的版號有更動的時候,表示這兩個版本會發生不相容的情況。換句話說在 v1.0 運作正常的程式,在 v2.0 可能會壞得體無完膚

v1.0

就是我們在 2014/04/30 之前使用的 platform,2015/05/30 退役。
雖然可以透過附加 v1.0 在路徑裡的方式來使用 v1.0 的 API ,但這僅限於 2014/04/30 前建立的 Facebook app。

v2.0

2014/04/30 後建立的 Facebook app 一律採用 v2.0

改動超多,簡列如下:(詳見 changelog)

Read on

angular-easyfb v1.2.0 released!

https://github.com/pc035860/angular-easyfb/releases/tag/v1.2.0

我發現 Parse 的人好像真的不少。

最近一次被路人推薦之後,馬上下面對話就有人問 Parse,而且同一串還有兩個人在講。

之後應該會找時間來 setup 一下測試 Cordova / Parse 的環境,確定沒問題之後就穩定添加到 README 吧!

週末長知識: Facebook's "theater" View

Facebook 長久以來有個顯示 post 的模式(多用在照片/FB影片),稱為 theater

Theater 說穿了其實就是平常蠻常見到的所謂 modal 的效果,搜尋 "jquery modal" 之類的關鍵字可以找到一大堆,那這樣這篇文章是想要說些什麼呢?

常見的 modal 實作

雖然 modal 們乍看都是一樣,互動上還是會因為實作方式的不同而產生不一樣的結果。

基本上可以分成三種。

絕對定位型

  • 依據產生當下的網頁畫面位置做定位
  • 可以捲動主網頁
  • 捲動時,modal 不會跟著瀏覽器可視範圍

Facebook JS SDK 呼叫 FB.ui() 產生出來 iframe 式的 dialog 就是屬於這種。

有捲軸可捲浮動型

  • 永遠保持在畫面內
  • 可以捲動主網頁(捲軸、滾輪)
  • 看得到捲軸

大部分的 modal 是屬於這種,因為它不需要在一些多餘的地方動手腳(誤)。

無捲軸可捲浮動型

  • 永遠保持在畫面內
  • 可以捲動主網頁(滾輪)
  • 看不到捲軸

為了達到不捲動主網頁的效果,通常會對 <html><body> 元素的 CSS overflow 動手腳;若不另外費工寫 JavaScript 處理捲軸寬度問題,會造成開啟 modal 瞬間的視覺體驗不佳。

Bootstrap 的 modal就是屬於這種,並且它有處理捲軸寬度,在打開 modal 的同時給予 <body> 一個 padding-right 來補上捲軸的寬度,便不會有視覺的落差出現。

Bootstrap 提供的 modal 在本身內容超過畫面高度的時候,會產生自己的 scrollHeight 並顯示屬於 modal 的捲軸,此時是無法對主網頁進行捲動的。

不可捲浮動型

  • 永遠保持在畫面內
  • 不可以捲動主網頁

理論上用普通方法難以實現的類型,僅管可以透過 overflow: hidden 讓捲軸消失,瀏覽器還是會聰明的讓滑鼠滾輪可以作用。

參考 http://stackoverflow.com/a/11336442/2378741 ,大概可以瞭解,完全阻止捲動的方法只有讓它其實不用捲;然而其中提到的將 <body>height 限制住的方法有一個致命的缺點 - 無法保留主網頁的捲動位置。造成的視覺落差甚至超過上面提到的「使用 overflow: hidden 卻不處理捲軸寬度」的 case,也因此實際上並沒有看到什麼網頁使用此類的 modal。

Facebook "theater"

現在的 theater 用了一種我以前從來沒見過/想到的方法實作出了不可捲浮動型

Read on

angular-easyfb v1.3.0 released!

https://goo.gl/ky60u0

  • 把預設的 ezfb.init() 中的 version 拉到 v2.0
  • 新增 Page plugin 支援

要說今晚為什麼一事無成都是因為在忙這個

原本只是想說把人家發的 PR 處理一下,畢竟那個 PR 延宕已久,之前寫 comment 給發來的人請他改一下他遲遲沒有回應,我只好親自下海修正再 merge 了。

想不到就在 merge 的前後冒出了一個神秘印度人表示他疑似試了並不 work,render 出來的 plugin 寬度不太正常。我試了一下還真如他所說,還好我還沒 push tag 上去。

趕緊查了 Facebook 官方的 Page plugin 頁面,發現這個 plugin 搭配了一個玄妙、不同於以往的莫名奇妙功能叫作 Adaptive Width : https://developers.facebook.com/docs/plugins/page-plugin#adaptive-width

The plugin will automatically adapt to the width of its parent element on page load (min. 180px / max. 500px)

這敘述聽起來是滿美好的... 讓我們繼續看下去

The Page plugin works with responsive, fluid and static layouts. You can use media queries or other methods to set the width of the parent element, yet:

Yet 來了...

  • The plugin will determine its width on page load
  • It will not react changes to the box model after page load

總而言之就是基本上它 adaptive width 的決定性 render 就只有一次,之後還是要靠自己... 然後它就造成我 angular-easyfb 的 directive rendering 發生了神秘的錯誤 Orz

總之由於實作 Angular directive -> Facebook plugin 的對應上我是使用 FB.XFBML.parse ,而它只針對參數的 child element 做 parse,為了不影響到其它的 element,在 parse 前我原本是會先用一個看不到的 <span> 把 plugin 的元素整個包起來。

這個 adaptive width 破壞了這項平衡... 總之現在碰到 adaptive width 的 plugin 我就一律改用 <div> 來包,也索性不加太多隱藏用的 style,畢竟這個 adaptive width 大概是需要去抓 parent element 的寬度的。

好了,總之經過一番千辛萬苦總算修正完成,連 test 部分也一併改好,終於 release 了!

剛剛上面提到恰好出現的神秘印度人一整個就因為剛好碰到我在解這個 issue,他就在線等 XD

Awesome!!! Its working perfectly.. Really thanks a lot for the quick fix..

真的是超級 quick fix wwwww

angular-easyfb v1.4.0 released!

https://goo.gl/9tPWeC

  • 支援 Ad Preview Plugin
  • 有鑑於支援 Ad Preview Plugin,將預設的 platform version 改為最新的 2.4

這次再版號上面其實是有點糾結的,主要是因為經歷了 Facebook Platform 從不需要帶 version 到需要帶 version 的這個轉換。

FB 1.0 -> FB 2.0

原本 init parameters 裡面不帶版號就使用的人再升到 FB 2.0 可能會遇到的問題是

  • 沒有帶版號所以預設使用 FB 2.0,造成自己有再使用的某些 API 崩壞

FB 官方的 API 文件其實是有明確表示需要帶版號的

然而從今年三月過後 FB 1.0 完全 deprecated,我為了盡量不造成人家的 app 掛掉,選擇預設帶入最舊的版號 2.0

FB 2.0 -> FB 2.4

結果前幾天一個新的 PR 表示想要支援一個新的 Facebook plugin 叫做 Ad Preview,這個 plugin 需要的是 FB 2.4。而這真的是尷尬到了極點啊~~~~

經過長考(!?)之後,還是決定以後都就直接帶入最新的 platform version 好了,反正依據官方文件這樣才是正確的行為。

於是乎,為了盡量造成最小的損害,我還是讓 version 的中間版號加了個 1 ,表示這還算是個有點大的改動。

Release 之後還是小小的擔心啊...