梅迪奇效應
2015/06/11
Working with files in JavaScript
Worth to read!
Working with files in JavaScript
Part 1: The Basics
Part 2: FileReader
Part 3: Progress events and errors
Part 4: Object URLs
Part 5: Blobs
Working with files in JavaScript
Part 1: The Basics
Part 2: FileReader
Part 3: Progress events and errors
Part 4: Object URLs
Part 5: Blobs
2015/06/05
Blank window issue on Safari Mobile and a quick solution
I am working on an embedded project. The device provides simple Web HTTP interface to interact with this device. It works fine on all browsers but Safari Mobile on iOS 8.3.
Surfing on Google, there are some problems on Safari Mobile (article 1, article 2, article 3, article 4, article 5). They sound like not same as what I am facing to. I monitor the packets captured by Wireshark, and found that Safari Mobile didn't load all resources(css, js, ttf, etc.) completely causes this problem. The Safari Mobile communicates with Web server in HTTP pipeline, while the others (Chrome, Firefox, Opera, IE, Safari Desktop, etc.) don't. (The others will reuse the connection, but won't pipeline them). That is the major difference!
In theory, the HTTP pipeline can speed up requests by reducing the number of round trip times. But there are some articles(articles 6, article 7, article 8) comment on this point. This is not what I want to discuss in this page. Let's back to my problem.
The HTTP pipeline raises lots of problem. Some developers submit tickets to Apple, but there is no plan to solve the problem. I try to find
I found an easy workaround for this issue at last. This problem can be solved by setting the connection field of the HTTP response header. I force the connection field to be "close" if the browser is Safari, and it works! In Java Servlet, you can set it as
(or you can set the header field in Filter), or in PHP
or you can set the field in Web server setting.
In Safari Mobile, it will close the connection when receive the response, and won't send further requests thru this connection. That is, no more HTTP pipeline from Safari Mobile. I am not sure is this the best solution or not, but it really solve my problem.
Surfing on Google, there are some problems on Safari Mobile (article 1, article 2, article 3, article 4, article 5). They sound like not same as what I am facing to. I monitor the packets captured by Wireshark, and found that Safari Mobile didn't load all resources(css, js, ttf, etc.) completely causes this problem. The Safari Mobile communicates with Web server in HTTP pipeline, while the others (Chrome, Firefox, Opera, IE, Safari Desktop, etc.) don't. (The others will reuse the connection, but won't pipeline them). That is the major difference!
In theory, the HTTP pipeline can speed up requests by reducing the number of round trip times. But there are some articles(articles 6, article 7, article 8) comment on this point. This is not what I want to discuss in this page. Let's back to my problem.
The HTTP pipeline raises lots of problem. Some developers submit tickets to Apple, but there is no plan to solve the problem. I try to find
I found an easy workaround for this issue at last. This problem can be solved by setting the connection field of the HTTP response header. I force the connection field to be "close" if the browser is Safari, and it works! In Java Servlet, you can set it as
response.setHeader("Connection", "close");
(or you can set the header field in Filter), or in PHP
header("Connection: close");
or you can set the field in Web server setting.
In Safari Mobile, it will close the connection when receive the response, and won't send further requests thru this connection. That is, no more HTTP pipeline from Safari Mobile. I am not sure is this the best solution or not, but it really solve my problem.
2015/05/19
你如何設計你的產品？
創業者請想清楚，該關注自己的產品還是需要解決的問題？
「每次他們發現新問題或新需求時，就不停地添加新功能。最終結果就是產品變得異常複雜，功能零亂，又沒法徹底解決用戶需求」
這篇文章讓我想起昨天在辦公室裡的事
昨天下午三點多接獲一個新指令，要做一個新功能。
思考了一下，把疑點跟主管討論了一下
嗯...這功能A在操作上會自己與自己抵觸
OK，主管決定修正為功能B
再思考了一下，覺得還是怪怪的
再去找主管，仔細的問這功能是要給誰(actor)用？這功能要呈現什麼價值(use case)？
被我這樣一問，大家才搞清楚誰是使用者，操作情境是如何，也才發覺原來功能A與功能B都不是最好的解法。從整個scenario重新構思，分析出我們的需求應該是功能C
在設計產品時，得不斷提醒自己，這是要給誰用？你的產品在那個情境中，能提供他們什麼價值？
「每次他們發現新問題或新需求時，就不停地添加新功能。最終結果就是產品變得異常複雜，功能零亂，又沒法徹底解決用戶需求」
這篇文章讓我想起昨天在辦公室裡的事
昨天下午三點多接獲一個新指令，要做一個新功能。
思考了一下，把疑點跟主管討論了一下
嗯...這功能A在操作上會自己與自己抵觸
OK，主管決定修正為功能B
再思考了一下，覺得還是怪怪的
再去找主管，仔細的問這功能是要給誰(actor)用？這功能要呈現什麼價值(use case)？
被我這樣一問，大家才搞清楚誰是使用者，操作情境是如何，也才發覺原來功能A與功能B都不是最好的解法。從整個scenario重新構思，分析出我們的需求應該是功能C
在設計產品時，得不斷提醒自己，這是要給誰用？你的產品在那個情境中，能提供他們什麼價值？
2015/05/04
iOS 7/8 Safari空白畫面
如果你的網站在Desktop版的Safari是正常，可是在iOS 7/8上的Safari卻會出現空白畫面，一直loading不停，那你可能遇到Safari的bug了。可參見：
http://tech.vg.no/2013/10/02/ios7-bug-shows-white-page-when-getting-304-not-modified-from-server/
這問題來自當要用Safari連上一個網址，這個網址你之前曾要連，但是因為網路、使用者中斷或是其他問題，造成某些resources(html, javascript, css, 圖檔等等)並未完成下載，但是Safari卻當成已完成下載。當使用者要重新連這網址時，在reload時會問server從上個時間點後有沒有改變過(雖然上次沒有完成下載，但是Safari卻當成已下載過)，而server此時可能回覆304 code表示沒有改變過。因此Safari就會從cache來取得這個resources，但是在cache裡的resources本來就不完整，造成Safari在呈現或呼叫webkit javascript engine執行時便發生錯誤，出現空白畫面或一直在下載中。
對此問題有興趣，可以用"ios safari 304"為keywords在google上搜尋，可以找到不少討論此議題的文章。
目前Apple似乎還未將這問題列為bug，所以可能還沒有修復的時間表。至於網路上有些人有提出些workarounds，主要都是將server-side改為不回應304，或是針對Safari不回應304，讓瀏覽器對所有的resources都一定重新取得，而不是使用cache裡的。不過這對使用iOS 7/8的iPhone/iPad來說，將會耗掉更多的電力與頻寬(如果不是吃到飽就要小心了)，但對網站經營者來說，為了達到Apple常掛在嘴上的「使用者體驗」，似乎也沒什麼其他的解法了。
這問題來自當要用Safari連上一個網址，這個網址你之前曾要連，但是因為網路、使用者中斷或是其他問題，造成某些resources(html, javascript, css, 圖檔等等)並未完成下載，但是Safari卻當成已完成下載。當使用者要重新連這網址時，在reload時會問server從上個時間點後有沒有改變過(雖然上次沒有完成下載，但是Safari卻當成已下載過)，而server此時可能回覆304 code表示沒有改變過。因此Safari就會從cache來取得這個resources，但是在cache裡的resources本來就不完整，造成Safari在呈現或呼叫webkit javascript engine執行時便發生錯誤，出現空白畫面或一直在下載中。
對此問題有興趣，可以用"ios safari 304"為keywords在google上搜尋，可以找到不少討論此議題的文章。
目前Apple似乎還未將這問題列為bug，所以可能還沒有修復的時間表。至於網路上有些人有提出些workarounds，主要都是將server-side改為不回應304，或是針對Safari不回應304，讓瀏覽器對所有的resources都一定重新取得，而不是使用cache裡的。不過這對使用iOS 7/8的iPhone/iPad來說，將會耗掉更多的電力與頻寬(如果不是吃到飽就要小心了)，但對網站經營者來說，為了達到Apple常掛在嘴上的「使用者體驗」，似乎也沒什麼其他的解法了。
訂閱：
文章 (Atom)