Teaching in Taiwan, ESL, EFL Jobs in Taiwan. 使用 Google Maps API (v3) 中的 Image Map Type. 使用 ImageMapType 讓你的 Maps 更有自己的風格! 前情提要 因為義務幫忙今年的 COSCUP 製作了一個 webapp 供參加者來使用,目前已經接近完成(因為有別的事在忙,所以拖了有點久)的階段,過幾天會正式放出來給大家使用,不過我先寫一些製作的心得分享文。 什麼是 ImageMapType 在 COSCUP Mobile WebApp 中的「Maps」部份,為了顯示出活動地點的室內平面圖,這個東西是我參考 Google I/O 2010 提供的會場地圖的方式而製作出來,使用自己繪製的平面圖疊加在原本的衛星圖資之上,它的顯示效果如下所示: 如果你曾經有注意過 Google 與電影「赤壁」合作過的活動網頁,你會發現其中有一個呈現赤壁古戰場風貌的地圖小工具(Mapplet),而它也是利用了 ImageMapType 的方式將古地圖貼上去。
若是你也有類似的開發需求,不必抓破頭煩惱怎麼把自己的圖片疊上去而寫出複雜的 JavaScript 程式碼,只需要利用 Google Maps JavaScript API v3 中的 ImageMapType 部份的 API 就可以完成,只不過在實務上該怎麼進行,以及要注意的事項在目前的官方文件並沒有寫得很清楚,這篇文章將會介紹我是如何完成這個效果,以及開發時的心得。 Google地圖圖資規格 Google 地圖的圖資是以一堆正方形的 tiles 所組成,每一個 tile 的大小是 256px * 256px(不論縮放,不同縮放大小就是不同的 tile,但大小都是 256px * 256px),而每個 tile 有 z, x, y 三個屬性,z 是表示縮放大小,而 x, y 則是 tile 在全球圖資中的 x, y 座標(與經緯度的值相關,但座標系統不一樣)。 這個示意圖我以紅線作為 tiles 的分界(只是畫個大概,不用真的去量是不是 256px * 256px),而淺藍色的座標數字則表示該 tile 的z, x 及 y 值。 為了方便起見,我將這兩張圖的檔案名稱根據 Google Maps 圖資的座標來命名為「t_18_219626_112227.png」及「t_18_219626_112228.png」,數字分別對應到 z, x, 及 y,至於為什麼要這樣做,接下來就要介紹 ImageMap Overlay 的使用作法。 結論. 開發手機版網頁. 稍微整理一下最近開發行動版網站的心得。 最近因為工作的關係,開始接觸手機版網頁的開發,不過我沒有參考什麼書籍,翻了幾個網頁、看了幾個網站的成果,再加上自己的想法,整理出來一些開發的心得,希望有各方好手能不吝賜教。 為什麼要做手機版的網頁? 隨著 smart phone 愈來愈流行,除了過去的 Windows Mobile 或是 Symbian 系統之外,現在的環境又多了 Apple 主推的 iPhone 以及 Google 的 Android 平台,未來以 smart phone 作為上網平台的人口照趨勢來看只會成長(不然也不會有這麼多大公司來競爭),所以如果一個提供服務的網站能夠有行動(手機)版本,對於使用者來說黏度會更強(當然前提是要夠好用)。
無縫連上行動版本 當一個網站品牌經營夠久時,使用者(或是搜尋引擎)所記得的大多是首頁的網址,所以當使用者用手持裝置連上網站首頁時,網站最好能偵測使用者目前是用手持裝置上網而直接導引到行動版本(不管是 redirect 到不同網址,或是根據手機換不同的 view ),這樣使用者不用特別記住行動版本的特殊網址也能夠享受到行動版的服務。 要做這件事其實不難,就我所知可以判斷三件事: 檢查 HTTP header 中的 Accept 欄位,看看之中有沒有 text/vnd.wap.wml 或是 application/vnd.wap.xhtml+xml 值檢查 HTTP header 中有沒有 X-Wap-Profile, Profile, X-OperaMini-Features 或 UA-pixels 等欄位如果不幸上述兩個動作都沒有,那就看看 User-Agent 欄位,來根據不同的手機品牌來作 match,比方說看看有沒有 sony, nokia, java, moto 等等字串 如果上述三個條件任一為真,那就幾乎可以判定 client 是一個手持裝置,而將之帶到行動版網頁。 當然,如果使用者需要,應該還是要提供一個回到完整版的連結,像 iPhone 或 G1 的使用者也許就想直接打開普通版的網站來使用。 網頁設計的語言 但其實現在許多手機的瀏覽器也做得很強,不那麼標準的 XHTML MP 也可以正常顯示 不過我的看法是 JavaScript 能少用就少用,除了支援度的問題以外,還有下一個部份會提到的問題。 要提供什麼內容? 畫面大小的制約 結論.