'Android'에 해당되는 글 4건

아이폰은 다운로드 헤더를 대충 만들어도, 알아서 잘 보여준다.

그런데, 안드로이드 단말기는 그렇지 못한다.

지금까지 확인해 본 바로는 Content-Type의 mime type 과 Content-Disposition의 filename을 정확히 만들어 주는것이 아주 중요하다.

여기 저기 검색을 해 보면, 3가지 규칙을 얘기한다.

1. Content-Type을 application/octet-stream으로 할것

2. Content-Disposition을 파일명을 Double Quotation mark로 감쌀것.

3. 파일명의 확장자는 대문자로 할것.

하지만 이 규칙마저도 안드로이드 프로요 버전 이하일 경우에 해당하는 것 같다.

지금은 위 규칙에서 2번, 3번을 꼭 지키지 않아도 충분한것 같다.

참고로 아래는 일반적인 다운로드 코드이다.(IE를 잘 지원하기 위해서는 별도의 코드가 더 필요하다. ㅡㅡ)

Header("Content-type: ".$mime_type); Header("Content-Length: ".(string)(filesize($file))); Header("Content-Disposition: attachment; filename=$file_original_name"); Header("Content-Description: PHP3 Generated Data"); Header("Pragma: no-cache"); Header("Expires: 0"); $fp = fopen($file, 'rb'); if (!fpassthru($fp)) fclose($fp);

하지만, 이번의 경우에는 파일 다운로드를 브릿지 역할을 하는 중간 서버를 통해서 해야 했기 때문에, 이렇게 간단하지가 않았다.

원본 서버에서 다운로드할 파일명과 mime-type을 HTTP Header에 내려줬기 때문에, 브릿지 역할의 서버에서는 이러한 정보를 간단한 방법으로는 안드로이드 단말기로 내려줄 수가 없었다.

아무 정보 없이, 확장자도 없이 다운로드 되는 케이스가 있었으며, 이 경우에 아이폰은 알아서 잘 보여줬지만, 안드로이는 정상적으로 보여주지 못하거나, 다운로드 실패가 되었다. 아..........

결국, 브릿지 서버에서 해당 화일을 HTTP Header 를 확인하여서 Header 정보를 바탕으로 파일을 저장하고, 이를 다시 내려주기로 했다.

Header 정보를 얻기 위해서는 curl의 옵션을 아래와 같이 사용했다.

class Download { private $OriFileName; public function call_down($url) { $data = $this->_curl_down($url); //헤더 정보 세팅 //다운로드 } public function _curl_down($url) { //curl 다운로드 $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HEADERFUNCTION, array(&$this, '_readHeader')); //콜백 함수 등록 ob_start(); $data = curl_exec($ch); curl_close($ch); ob_end_clean(); return $data } public function _readHeader($ch, $header) { //콜백 함수에서 헤더 정보 확인 $filename = $this->_extractCustomHeader('Content-Disposition: attachment; filename=', '\n', $header); if ($filename) { $this->OriFileName = trim($filename); } return strlen($header); } private function _extractCustomHeader($start,$end,$header) { $pattern = '/'. $start .'(.*?)'. $end .'/'; if (preg_match($pattern, $header, $result)) { return $result[1]; } else { return false; } } }

다운로드 브릿지 서버를 사용해야 하는 이상한 상황이어서 더더욱 해매고 말았다.

새삼스럽게 'iOS가, Safari가 정말 잘 만들었진거구나' 라는 생각을 하게 되었다.

최근에 Adobe Labs에서 Adobe Shadow라는 것을 내놓았다.

간단히 설명하자면, PC에서 보는 웹페이지 화면을 모바일 단말기와 싱크해서 모바일에서는 어떻게 보여지는 확인 할 수 있게 해 준다.
이 뿐만 아니라, Inspector와 같은 크롬용 개발자 도구를 모바일에 연결해서 볼 수 있게 해준다!!!!!
정말 이런 기능이 필요했다.

올바른 작동을 위해서 맥또는 윈도우에서 구동될 호스트 프로그램, 확장 기능이 설치된 크롬 브라우저, 동일 네트워크에서 구동이라는 조건이 필요하다. (윈도우일경우에는 봉주르 서비스 설치가 추가로 필요하다)

백문이 불여일견 아래의 소개 동영상을 보자. 

 

동영상에서 보여주는것처럼, 아이폰, 아이패드, 안드로이드 등의 모바일 단말기를 한번에 연결해서 볼 수 있다.
맥에서 설치해서 해보니, 간혹 Inspector가 연결을 잘 못하는 경우가 있었지만 대체적으로 쓸만했다.

 
자세한 소개 및 설치 방법은 아래의 공식 사이트에서 확인하면 된다.

http://labs.adobe.com/technologies/shadow/ 

이제 뉴 아이패드 한국 발매 시점에 맞추어, 아이패드의 필요성을 회사에 강조하기만 하면 되겠다!!

모바일용으로 디자인된 페이지를 작업하면서, 그 동안 해결하지 못하고 계속 궁금해 했던 문제를 드디어 해결했다.

다름이 아니라, 상단 메뉴바를 만들때, UL과 LI로 메뉴를 구성하다 보면 넓이를 도합 100%가 되도록 정확히 구성했음에도 불구하고, 100%를 차지하지 못하는 경우가 생긴다.

예를 들어, 메뉴가 3개라고 하면, 34%, 33%, 33%로 구성하거나, 33.33%로 새개 모두를 구성하게 된다.
그런데 이렇게 하면 아래 그림과 같이 오른쪽 끝에 빈 공백이 생긴다.

디자이너가 이와 같은 문제를 가지고 여러번 문의해 왔지만, 정확한 해결책을 찾지 못해 고심했다
그러다가 오늘, 본격적으로 이 문제를 짚고 나가야겠다는 생각을 했다.

문제는 webkit 계열 브라우저에서 width 속성을 퍼센트로 주었을때 발생하는것이었다.

아이폰 기준으로 320px의 넓이를 3등분하면, 106.666666.....px이 나온다. 아마도 webkit 계열 브라우저는 소수점 이하 값을 무시하고 넓이를 계산해서 렌더링하는것으로 보인다.
때문에, 소수점이 없이 정확히 떨어지는 퍼센트 값에 대해서는 정확하게 보여줄 수 있었던 반면, 소수점이 나오는 값에 대해서는 실제보다 작게 계산되어 여백이 생기는것 같다.

그렇다면, 이에 대한 해결책은 무엇일까?

약간의 꼼수 같지만, 위와 같은 스타일로 보기 싫은 공백 없이 메뉴바를 보여줄 수 있게 되었다.
최종 결과 화면은 아래와 같다.

깔끔하게 문제를 정리하게 되었다.