저는 버튼 누르는것에 대해서 별로 좋지 못한 느낌이 있어서 ㅎㅎㅎ....

정전기야 뭐 기기 켜지면 터치스크린 전체에 흐르는걸 생각하면 얼마나 더 떨어질까 싶기도 하네용

화면 가장자리에 터치센서를 두고 메뉴 화면으로 이동한다거나 특정 이벤트를 발생시키는 트리거로 동작하는 기능은 이미 특허뿐 아니라 실용기기로 오래전에 나온거라, 특허를 내기 위해서는 삼성이나 애플처럼 법무능력과 로비능력이 엄청나게 강하지 않으면 안될 듯 합니다. ㅎㅎ

기기 보안을 위한..... 거죠 ㅋㅋ

ㅋㅋㅋ 역시 개발자의 마인드~

저는 그저 그냥 옵션 하나 더 추가해줬으면 좋을 뿐이죠~ 위에 블러킹은 간단한 예외 처리 하나 넣으면 해결되겠네용~

흐흐~ 기획팀에선 "개발자들은 사소한 트집을 잡는다." "개발자들은 너무 협소한 시선을 가진다" 라고들 하잖아요. 근데 뭐 어쩔수 없드라구요.

위에 블러킹을 깊게 따지고 들어가서 역시 개발자로서 이야기해보자면, 이런 간단한 예외 처리가 들어가면 들어갈수록 코드의 분기가 많아지고 CPU 처리량이 계속해서 늘어나거든요. "분기 = 퍼포먼스 하락" 이니깐요. 특히 하드웨어와 연동되는 기능에 분기와 예외가 들어가는 경우에는 하드웨어와 통신을 계속 해야 하고 값이 오는걸 무작정 loop를 돌려 기다려야 하기 때문에 심하게 느려져버릴 수 있습니다.

여기에 극단적으로 끔찍했던 사례가 있는데요.

과거 Windows Mobile 시절의 경우 CDMA 칩과 메인 프로세서가 통합되지 않았고, 두 칩을 씨리얼통신이나 USB로 연결하였죠. 씨리얼통신은 느리고 USB는 메인 프로세서에 통합되어 있다보니, 어느걸 써도 만족스러운 속도가 나오질 않았어요. 그래서 한번 신호가 왔다갔다 하는데 무작정 몇번이고 while loop가 난무하게 되었고, 중간에 signal이 사라져버리는데 이걸 전부 예외처리해버려야 하죠. 거기다 ma3 음원을 지원해야 하다보니 별도로 들어가는 야마하 칩셋까지, 전화가 오거나, 전화를 하거나, 문자를 주고받기 위해서는 총 3개의 칩셋이 3^2승의 조합을 가지고 온갖 분기에 들어가 수도 없는 while loop를 버텨야만 했습니다. (심지어 완전히 뒤틀린 신호가 날라가서, 기지국이 멈춰버립니다.)

이걸 해결하기 위해서는 전용 OS + 전용 프로세서 또는 그걸 아우르는 프로토콜이 나와주어야 하는데 그러질 못했고 (MS는 독과점 소송에 정신없었고...) 그 결과 나온게 수많은 쓰레기 품질의 PPC 폰, WM 폰들이었어요.

애플은 그러한 하드웨어 조합, 사소한 예외사항 조차도 허용하지 않는 완전한 폐쇠 시스템을 구축했고, 안드로이드도 애플이 앞장서서 성공한 덕분에 OS에 맞춰 하드웨어가 개발되는 혜택(?)을 누릴 수 있었구요.

이런 이유로, 구글에서는 기획자나 디자이너도 전부 공학 분야나 프로그래밍 언어의 숙지 정도를 주기적으로 테스트하고 인사평가에 반영하고 있어요. 하드웨어랑 연관된 기획자들과 디자이너들은 전기 공학에 대한 소양이 충분히 갖추어져 있어야 한다고 하는거죠. 개발자가 UX나 디자인, 포토샵에 대해 아는 정도를 기획자나 디자이너들에게 요구한다느 거죠.