아실지 모르겠지만 필자는 여러 플랫폼에서 동일한 UI를 제공할 수 있도록 하는 UI Library를 제작하는 사람입니다.

여러 단말에 아직은 많지 않지만 이것 저것 만들어보고 있는 중이죠.

그런데 방금 갑자기 생각이 난 것이...

우리는 단말 화면을 pixel resolution만으로 생각하고 있었다는게 너무 아쉽네요. 하나의 어플이 여러 단말에서 동작하게 하려면, 각 단말의 resolution에 맞게 이미지나 사이즈를 조절하는 작업이 필요한데 실제로 이러한 작업 이외에는 한게 없어 보입니다...

그런데 문득 생각난 것이... 같은 resolution이지만, pixel per inch가 다른 장치들이 많다는 거죠. 물론 이론상 알고는 있지만 말입니다.

같은 resolution이라고 해서 사용자에게 실제로 보여지는 크기가 같지 않다는 말이죠...

14인치 lcd에서 1024*768 해상도와 17인치 lcd에서 1024*768 해상도를 생각해보시면 될 것 같습니다.

아.. 사용성을 높이는데 고려해야 할 점이 하나 더 늘었군요...

이점에서 iPhone은 일승을 거두었네요... 언제나 동일한 해상도와 lcd사이즈를 가졌으니.....

제가 좀 깨닫는 속도가 많이 느린가 봅니다 허허 ^^;;

저작자 표시 비영리 동일 조건 변경 허락
신고

박상건 - gunnih

베를린에서 일하는 외국인 노동자 » Contact Me: gunnih@gmail.com




  1. rageworx

    2009.12.08 01:44 신고


    절대 좌표와 상대 좌표가 있는 이유가 그런거이기도 해 ..
    진보적인 거지 , 그런걸 보면 애플은 .

1. 운동량 계산 방식


운동량을 계산하기 위해서 시간과 거리에 대한 기준을 두고 계산을 합니다.

예를 들어250ms 동안 100pt를 이동하면 운동량은 500pt가 됩니다. (여기에 질량을 이용한 가속도를 추가하셔도 괜찮을 것 같습니다.)

따라서, 운동량 P는 다음과 같은 선언을 기준으로

#define FLICK_BASE_TIME_GAP 250

#define FLICK_BASE_DISTANCE_GAP 100

#define FLICK_BASE_MOVE_DISTANCE 500


다음과 같이 계산이 가능합니다.


// FLICK_BASE_DISTANCE_GAP : moving_distance = FLICK_BASE_MOVE_DISTANCE : P 가 성립하므로

P= (moving_distance*FLICK_BASE_MOVE_DISTANCE)/FLICK_BASE_DISTANCE_GAP;

// 위와 같은 방법으로 FLICK_BASE_TIME_GAP : moving_time = FLICK_BASE_DISTANCE_GAP : P 가 성립하므로

P = P*FLICK_BASE_TIME_GAP/moving_time;


2. 마찰력 계산 방식

총 운동량이 계산되면 마찰력을 곱해서 시간에 따라 속도를 감속 시킬 수 있습니다.

다음과 같이 마찰 계수와 최대 마찰 계수를 선언하고

#define COEFFICIENT_OF_FRICTION 50

#define MAX_COEFFICIENT_OF_FRICTION 1000


다음 식을 수행하면, 마칠력이 적용된 힘을 얻을 수 있습니다.

P = P*( MAX_COEFFICIENT_OF_FRICTION  - COEFFICIENT_OF_FRICTION)/MAX_COEFFICIENT_OF_FRICTION;


3. 유효 이동 거리 및 유효 이동 시간 구하는 방법

정전압 터치 패널이 아닌 접점식 터치 패널은, 손가락으로 이용할 경우, 원하는 형태로 터치 event를 받아들이지 못하는 경우가 많습니다.

따라서 다음과 같은 조건을 두고 전달되는 이벤트를 계산해서 유효 이동 거리와 유효 이동 시간을 구합니다.


1)마지막으로 touch up 이벤트의 좌표는 무시한다. (손가락을 이용하여 한 방향으로 긁으면, 대부분 touch up event의 좌표는 마지막 move 이벤트 좌표를 기준으로 전체 방향성의 반대 방향의 위치로 전달 되게 됩니다. 이는 손가락 접점이 넓기 때문에 발생하는 현상입니다.)

2)표본 수집 시간을 정해 놓습니다. 최대 수집 시간을 500ms로 설정하면, 마지막으로 발생한 이벤트의 시간에서 500ms 이전의 이벤트들은 무시하도록 합니다.

3)표본 수집 이벤트 개수를 정합니다. 시작 점과 도착 점을 수집하기 위한 최대 이벤트 검색 개수를 정해 놓습니다. 만약 표본 수집 최대 개수를 10으로 정하면 마지막 이벤트부터 최대 10개 까지의 이벤트만을 계산 공식에 반영하도록 합니다.

4)접점 방식은 사용자가 계속 누르고 있다고 생각하나, touch uptouch down이 굉장이 짧은 시간 안에 여러 번이 발생할 수 있습니다. 이에 대한 skip 프로세스를 설정해주어야 하는데, skip invterval300ms로 주면, 마지막 touch up 이벤트의 발생 시간을 기준으로 300ms 이내에 발생하는 touch downup 이벤트는 무시하도록 하는 조건을 주는 것이 좋은 것 같습니다.

5)마지막으로 표본으로 사용할 수 있는 이벤트의 개수가 1개일 경우, 2개일 경우, 3개일 경우, 그 이상일 경우로 분리하여 이동 시간과 거리를 계산하는 방식을 따로 구현하는 것이 좋을 것 같습니다. 특히 표본이 1개일 경우는 분석 가능하지 않기 때문에 skip하는 것이 최대한 오동작을 줄이는 방안일 것 같습니다.

(위의 각 설정 값들을 잘 조정하면, 감도가 좋은 효과를 낼 수 있을 것 같습니다.)

저작자 표시 비영리 동일 조건 변경 허락
신고

박상건 - gunnih

베를린에서 일하는 외국인 노동자 » Contact Me: gunnih@gmail.com




아주 옛날부터 이런 고민은 많은 사람들이 해왔고 많은 해결책이 있는 걸로 안다...

근데 단말 환경... 정확히 지금까지의 단말 환경에서는 math api의 제약이라던가 부동소수점 연산의 제약이라던가...

머 이런 저런 이유 때문에 많은 개발자들이 선을 그리지 않고 이미지로 대체한다. 사실 이미지로 하는게 훨씬 이쁘다.

공통적으로 발견되는 문제점은

1. 각도 계산에 대한 어려움 (왜냐... 그냥 플랫폼이 지원하는 math함수가 내가 원하는 각에 대한 값을 정확하게 올려줄지 확신할 수 없음, 그 다음으로 속도가 잘 나올 것인가에 대한 불신)이 있다.

위의 문제를 해결한 후 고민해야 보아야 할 사항은 시간을 가리키는 시침, 분침, 초침을 뾰족하게 그릴 것인가, 아니면 그냥 직사각형의 형태로 그릴것 인가가 문제인데

일단 직사각형으로 그릴 경우의 문제점을 이야기해 보면,

2-1. 대부분(? 확실하지 않다. 단 현재 내가 작업하는 플랫폼은 그렇다.)의 모바일 플랫폼은 두께를 가지는 선을 그리는 api를 제공하지 않는다.

2-2. 두께를 여러개의 라인을 그려서 나타내려 하면 빈 공백이 생긴다.
    예를 들어 원래 0,0 에서 5,10 으로 선을 그리는데, 1,0에서 6,10 그리고 0,1에서 5,11로 선을 그리면 중간 중간 공백이 생긴다.

위의 문제들을 해결하기 위해서 내가 사용한 방법은,

2-1. 선을 그리는 알고리즘을 따로 구현한다.
2-2. 선의 점을 찍을 경우 각도에 따라 그리고자 하는 두께 만큼 세로선 or 가로선을 그리면서 목표점까지 그려나간다.
    45도 이상 135도 미만은 가로, 135이상 225미만은 세로... 이런식으로 360도를 지나 원래 45까지만 와서 그리면 두께를 표현하는 선을 그릴 수 있다.

두번째로 뾰족하게 침을 그리고 싶은 경우 생기는 문제에 대해 이야기 하면

3-1, 여러 점에서 목표점 하나를 향해서 선을 그리면 꼭 공백이 생긴다.

이를 해결하는 방법은 2-2의 응용으로 해결할 수 있다.

3-1 시작 지점에서의 두께를 기준으로 총 선의 길이와 비례적으로 라인의 두께를 줄여나간다. 각 점의 길이를 계산해서 비례적으로 줄어든 두께를 이용하여 2-2와 같은 방식으로 선을 그려나간다.

여기서 한가지 짚어볼 점은 3번 항목의 문제를 해결하면 각에 따라 삼각형이 너무 한쪽으로 치우치는 현상을 볼 수 있다.
이 문제를 해결하기 위해서는 두께를 표현하기 위한 선을 그릴때, 해당 선의 시작점과 끝점을 각도에 따라 계산을 해서 그려야 한다. (해보니 좀 느려지기는 하는것 같다.)

실제로 시계를 만들어 그리는데 필요한 각의 개수는 15개 나머지는 15의 각을 기본 +,- 연산만으로 계산할 수 있으니 속도에 영향을 주지 않는 듯 하고, sin, cos은 해당 값을 << 10 (*1024)한 값으로 2byte 변수에 저장하였으니,

아날로그 시계를 그리는데 필요한 변수 메모리는 최대 80 byte를 넘기지 않는다는 대단한 결과가......홍홍홍...


저작자 표시 비영리 동일 조건 변경 허락
신고

박상건 - gunnih

베를린에서 일하는 외국인 노동자 » Contact Me: gunnih@gmail.com




1 2

티스토리 툴바