본문 바로가기
프로그래밍 놀이터/안드로이드, Java

[android/안드로이드] 무결성을 위한 앱 설계시 고려할 사항들.

by 돼지왕 왕돼지 2012. 2. 8.
반응형


안녕하세요 돼지왕왕돼지입니다.
오늘은 무결성을 위한 앱 설계시 고려할 사항들에 대해 알아보겠습니다.
 
 

다음의 디자인 issue들은 사용자에게 문제를 야기시킬 수 있다.

 
  1. 다른 어플리케이션이나 다이얼로그의 예상치 못한 타이밍의 팝업.
  2. 계획되지 않은 상호작용
  3. 데이터의 부주의한 손실
  4. 의도되지 않은 멈춤
 
 
 

무결성을 위한 디자인 고려사항.



다이얼로그 팝업을 피하라.


 일반적인 무결성 문제는 서비스 또는 브로드캐스트 리시버 등이 어떤 이벤트에 응답하여 다이얼로그를 팝업할 때 발생합니다.
이것은 실제 디바이스 상에서 다른 어플리케이션이 많이 설치되어 있는 환경에서 자주 발생합니다.
다이얼로그를 띄우는 시점에서 focus를 가지지 못하는 상황도 발생하곤 하죠.
따라서 무언가를 알리기 위해서는 다이얼로그보다는 최대한 Notification을 사용하는 것이 좋습니다. (focus 방해 최소화하기 위해서)
 
 

Activity의 생명주기에 정확한 구현을 해주어라. ( 데이터를 누락시키지 말아라 )

 
Activity의 onPause() 를 비롯한 생명주기 함수들을 정확하게 구현하지 않으면, Activity의 상태나 사용자 데이터를 부주의하게 상실하게 되는 경우가 많습니다. 다른 액티비티가 어떤 순간에 내 액티비티 위에 팝업될 수 있다는점을 항상 상기하여 디자인 및 코딩해야 하죠. 이 현상은 onSaveInstanceState()와 onPause()를 호출하기 때문에 정보보존을 위해 onSaveInstanceState()를 override하여 적절한 구현을 해주어야 합니다.
 
 



 

원시 데이터를 드러내지 말아라.


 원시데이터 제공은 다른 앱이 내 데이터의 포맷을 이해하도록 해야 한다는 단점이 있습니다. 따라서 컨텐트 프로바이더가 좋은 방법이죠.
 제작하는 앱이 데이터를 공유해야 한다면, world-readable 원시파일이나 DB를 직접 제공하기보다는, 컨텐트 프로바이더를 통해 보여주는 것이 좋습니다.
 
 

사용자를 방해하지 마라.


 백그라운드에서 실행되는
브로드캐스트 리시버나 서비스에서 startActivity() 또는 Dialog.show()를 호출하면 좋지 않습니다. 위에서 언급한 2가지 결절사항을 다른 앱에 도출시킬 수 있기 때문입니다. 즉 현재 user 와 interact 하고 있는 activity 를 방해하게 됩니다. 이것을 전문적으로(?) keystroke bandit (키 입력 도둑놈) 라고 합니다. 따라서 가능한한 Notification 을 통해 어떤 event 를 알려야지, activity 를 띄운다거나 다이얼로그를 띄우는 것은 지양되어야 합니다.
 
 
 

해야 할 것이 많다면, 쓰레드에서 하라.


  이 부분은 너무 저명하죠? Main Thread 에서 많은 일을 오래 하게 되면, UI Event 를 Block 시키기 때문에 ANR 문제를 야기시킵니다.
 
 
 

단일 액티비티 스크린에 View 오버로드를 주지 마라.


  한 화면에 너무 많은 View 를 배치한다면, UX 적으로 좋지 않습니다. 사용자가 모든 기능을 한눈에 파악하기 힘들 뿐더러, 터치 이벤트들이 정확히 들어가지 않을 가능성도 높아지죠. 이런 경우에는 여러개의 액티비티를 사용해서, View 와 기능들을 분배하는 것이 좋습니다.
 
 
 

시스템 테마를 확장하라.


꼭 기능적 무결성을 떠나, 한 Application 은 여러개의 Activity 와 View 를 가지고 있다고 해도, 동일한 앱이라는 느낌을 주어야 합니다. 따라서 디자인상으로 비슷한 느낌을 창출하도록 해야하는데, 시스템 테마를 확장하여 적용하면 Look-and-feel 을 맞추기가 좋습니다.
 
 
 

다양한 스크린 해상도에서 작동하도록 UI를 디자인하라.


요즘은 해상도가 다른 단말들이 너무나도 많이 쏟아져나오고 있습니다. 해상도 차이를 고려하지 않은 앱들은 해상도가 달라지면 예상치 않은 모습을 보여주곤 합니다. 같은 해상도라도 Portrait 모드와 Landscape 모드일 때의 Layout 도 다릅니다. 따라서 Orientation 을 고려한 layouting 과, 해상도를 고려한 dip 단위 사용이 추천됩니다. 가장 좋은 방법은 다른 해상도를 위한 각각의 artwork 를 제공하는 것이지만, App 용량이 늘어난다는 단점을 가지고 있죠. 
 
 
 

네트워크가 느리다는 것을 가정하라.

 에뮬레이터는 유선을 보통 이용합니다. 즉 우리가 쓰고 있는 광랜을 주로 사용한다는 거죠. 그 속도에 속지마시길 바랍니다.
추가적으로 인터넷 강국이라 불리는 한국에서도, 3G나 LTE, WI-Fi 가 매우 취약한 지역이 많이 있습니다. 그런 환경도 "고려"되어야 합니다.
따라서 가능하면 정말 안정적인 네트워크 환경이 나올 때까지는
네트워크가 느리다는 것을 가정해야 합니다. 
 
 
  

터치 스크린 또는 키보드를 가정하지 말아라.


단말이 터치 스크린을 반드시 지원한다던지, 키보드가 있다면 반드시 QWERTY 라던지 이런 것을 가정해선 안 됩니다.
터치 스크린을 지원하지 않는 경우도 있을 수 있고, 키보드는 QWERTY, 40key, 12key 등 종류가 많습니다.
 
 

디바이스 배터리를 절약하라.

  
 베터리 전원의 가장 큰 세 소비자는 디스플레이, 프로세서( CPU )와 라디오( 전파 )입니다.
 가능한 적게 프로세서를 사용하는 것은 효율적인 코드로. 가능한 드물게 네트워크 사용하는 코드로, 가능한 디스플레이를 적게 쓰는 코드를 사용해야 합니다.
 ( 예를 들어 한번 실패하면 꼭 필요한 경우가 아니라면 네트워크 오퍼레이션을 계속 재시도 하지 마라. )



사실 무결성이라고 하는 것이 모든 App 에 무조건 적용되어야 하는 사항이 아닙니다.
주로 마켓에 배포되는 녀석이 가져야 할 특징이 무결성입니다.

Software 회사 등에서 Target Device 가 딱 지정된 경우는 위에 제시한 무결성을 위한 설계 중 몇가지는 제외될 수 있습니다.
항상 모든지 "완벽히" 들어맞는 것은 없는 것 같습니다. 상황에 맞게 현명하게 무결성을 위한 설계 룰을 적용하시기 바랍니다~

그럼 이만~ 
 
로그인 없이 추천 가능합니다. 손가락 꾸욱~


반응형

댓글