android - Custom Lock Screen

Custom Lock Screen

안드로이드는 루팅하지 않은 단말기에서 락스크린을 교체할 수 없다. 런처처럼 정상적인 방법으로 대체하는 방법을 제공하지 않는다.

다만 Android 4.2 부터 락스크린에 위젯을 표시할 수 있는 락스크린 위젯 기능이 추가되었다.
하지만 4.1 이하 단말기에서는 사용할 수 없다.

Android Version에 영향을 덜 받고 원하는 화면을 락스크린에 표시할 방법은 없을까?
락스크린과 유사한 동작을 하는 어플을 만들고자 한다면 필요한 기능은 무엇일까?

• 기존의 락스크린이 표시되거나 해제되는 시점을 알 수 있어야 한다. 최소한 락스크린이 표시되는 시점은 알아야 한다.
• 기존의 락스크린 위에 화면을 표시 할 수 있어야 한다.
• 기존의 락스크린을 해제할 수 있으면 좀더 유연한 동작이 가능할 것 같다.
• 보안이 설정된 락스크린은 어떻게 처리하는게 바람직한가?
• 전화, 메시지, 기타 락스크린을 사용하는 알림 기능에 대해 대처해야 한다.

구현이 가능한지 여부를 확인해보자.

락스크린의 상태변경에 대한 콜백기능이 없다.

SCREEN_ON, SCREEN_OFF 상태를 브로드캐스트 메시지로 수신할 수 있다. 다만 코드로 등록하는 경우만 해당 메시지 수신이 가능하여 통상 서비스를 이용한다.

서비스는 LMK에 의해 종료될 수 있기에 SLEEP 상태에서 화면 On/Off 메시지를 수신할 방법이 필요하다.
AlarmManager를 이용하여 주기적으로 서비스 구동요청을 할 수 도 있고 foreground service 기능을 사용할 수 도 있다.

Android 5 부터 WindowManager.LayoutParams의 FLAG_SHOW_WHEN_LOCKED 플래그 설정으로 락스크린 위에 표시되는 액티비티를 지원했다.

Android 1 부터 KeyguardManager를 이용해 보안이 적용되지 않은 락스크린을 해제하는 기능을 제공했으며 이 기능을 Android 5 부터는 WindowManager.LayoutParams의 FLAG_DISMISS_KEYGUARD 플래그 설정으로도 제공하고 있다.


결론 

화면 On/Off 시점을 알고 액티비티를 락스크린 위에 표시하는 기능과 기존 락스크린을 해제할 수 있는 기능을 조합해 기존 락스크린을 어느정도 대체할 수 있고 이를 이용한 많은 락스크린 앱들이 플레이 스토어에 올라와 있다.

락스크린과 유사한 UX를 구현하고 보안 락이 걸려있지 않은 경우 기존의 락 스크린을 해제하여 락스크린 기능을 대체하여 사용할 수 있다.

개인적인 사견으로는 정상적인 방법으로 락스크린 자체를 대체하는 방법을 제공하지 않는데는 보안문제가 가장 큰것 같다.

programming paradigm - AOP (Aspect Oriented Programming)

영역 지향 프로그래밍 또는 국면 지향 프로그래밍

 - 프로그램의 영역이 수행 프로그램의 컴파일 방법을 결정하는 프로그래밍 방법

Aspect : 프로그램의 성격을 나타내는 서브 프로그램, 단위 모듈

실예)
 - 단위 모듈(로깅, 예외처리, 트랜잭션, 보안 등)을 설정파일로 로직의 수정없이 적용
 - plugin


AOP를 지원하는 패턴

DI (Dependency Injection) 또는 IoC (Inversion of Control)

 - 코드의 의존성을 설정 (DI Tool)
 - 코드의 의존성을 제거 (DI Pattern)
 - 불필요한 의존도를 줄여 직교성을 높임

DI 종류

 - 생성자 기반 DI
 - Setter 기반 DI
 - Annotation 기반 DI
 - 설정파일 기반 DI


AOP를 지원하는 툴

AspectJ

 - compile된 bytecode에 대한 re-compile을 통한 새로운 bytecode 작성으로 인한 AOP가 갖는 성능 저하의 최소화
 - pointcut, advisor 의 직접적인 선언을 이용한 보기 쉬운 코드작성

 참고)

• Pointcut : AOP가 적용되는 시점을 정의
• Advice : Pointcut과 연동되어 AOP가 적용될 method를 의미
• Advisor : Point + Advice로 정의된 class를 의미

Spring AOP

architecture - GoF Design Pattern

GoF Design Pattern (Gang of Four : Erich Gamma, Richard Helm, Ralph Johnson, Jone Vlissides)


디자인 패턴 관계도

(출처 : http://nasir.files.wordpress.com/2009/11/design_patterns1.jpg)

객체생성에 관한 패턴

1. Factory Method : 팩토리 메소드 패턴
 - 객체를 생성하는 작업을 대신해주는 패턴
 - 객체 생성이 복잡할때 유용

2. Singleton : 싱글톤 패턴
 - 클래스의 인스턴스가 오로지 하나만 존재해야 하는 경우 사용
 - 무분별한 객체 생성을 방지

3. Prototype : 프로토타입 패턴
 - 동일한 객체를 여러번 생성해야 하는 비용을 줄이기 위한 패턴으로 한번 로딩된 객체를 복제하여 사용

4. Builder : 빌더 패턴
 - 복합 객체의 생성 과정과 표현 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴
 - 객체를 이루는 구성요소를 분리하여 객체의 세부 구성요소 클래스를 별도로 만들고 그 구성요소 클래스를 조합하여 하나의 객체를 만드는 것

5. Abstract Factory : 추상 팩토리 패턴
 - 인터페이스를 통해 생성하려는 객체의 실제 타입을 은닉


행동에 관한 패턴

1. Iterator : 반복자 패턴
 - 내부 구현에 대한 이해 없이 자료의 집합체를 탐색할 수 있게 해줌

2. Template Method : 탬플릿 메소드 패턴
 - 메소드 실행 순서를 추상 클래스에서 정의하며 실제 동작하는 알고리즘은 구현 클래스에서 정의하도록 함

3. Strategy : 전략 패턴
 - 알고리즘 인터페이스를 정의하고 각각의 알고리즘을 클래스별로 캡슐화 하여 각각의 알고리즘을 교체가 가능하게 함
 - 유지보수의 효율성을 높이기 위해 동적으로 알고리즘을 변경할 수 있는 패턴

4. Visitor : 방문자 패턴
 - 객체의 구조와 기능을 분리시키는 패턴
 - 구조는 변하지 않으며 기능만 따로 추가되거나 확장되는 경우 사용
 - Composite Pattern과 함께 사용되는 경우가 많음

5. Chain of Responsibility : 책임 연쇄 패턴
 - 요청을 처리할 수 있는 기회를 하나 이상의 객체에게 부여함으로써 요청하느 객체와 처리하는 객체 사이의 결합도를 없애는 패턴
 - 요청을 해결할 객체를 만날 때까지 객체 고리를 따라서 요청

6. Mediator : 중재자 패턴
 - 모든 클래스간 복잡한 로직을 캡슐화하여 하나의 클래스에 위함하여 처리하는 패턴

7. Observer : 옵저버 패턴
 - 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 통지하여 자동으로 갱신처리 되는 패턴
 - 일방적 통지 방식의 패턴

8. Memento : 메멘토 패턴
 - 객체의 상태 정보를 저장 및 복원하는 패턴
 - 객체의 내부 상태정보만 가지는 클래스를 따로 생성하여 관리하는 구조

9. Command : 커맨드 패턴
 - 메소드(작업요청)을 객체의 형태로 캡슐화하는 것
 - 특정한 일을 하는 기능을 따로따로 객체화하여 요청의 종류와는 무관하게 프로그램 작성이 가능하게 함

10. Interpreter : 해석자 패턴
 - 문법 규칙을 클래스화 한 구조로 일련의 규칙으로 정의된 언어를 해석하는 패턴
 - 스크립트나 컴파일러 등 언어분석기
 - 통신 프로토콜, SQL 구문 분석기 등

11. State : 상태 패턴
 - 객체의 상태에 따라 각각의 행위를 변경할 수 있게 캡슐화


구조에 관한 패턴

1. Adapter
 - 클래스의 인터페이스를 사용자가 기대하는 인터페이스 형태로 적용시킴
 - Wrapper 와 유사

2. Bridge : 브리지 패턴
 - 구현부에서 추상층을 분리하여 각자 독립적으로 변형할 수 있게 하는 패턴
 - 상속을 이용한 패턴으로 확장 설계에 용이

3. Composite : 컴포지트 패턴
 - 객체와 객체 그룹을  구분없이 하나의 인터페이스로 다룰 수 있게함

4. Decorator : 데코레이터 패턴
 - 객체에 기능을 덧 붙이는 패턴
 - 기능 확장시 서브클래스의 대안

5. Facade : 파사드 패턴
 - 통일된 인터페이스를 통해 복잡한 서브시스템들을 간단히 사용하도록 만든 패턴

6. Flyweight : 플라이웨이트 패턴
 - 데이터를 공유 사용하여 메모리를 절약하는 패턴
 - 객체는 풀로 관리

7. Proxy : 프락시 패턴
 - 실제 사용하려는 객체를 대신해서 역할을 해주는 패턴으로 원래 객체의 접근제어를 목적으로 사용됨


참고)

GoF Design Pattern Reference Card

http://www.mcdonaldland.info/files/designpatterns/designpatternscard.pdf

architecture - UML

UML (Unified Modeling Language)

 객체지향 소프트웨어 모델링을 위한 표준 그래픽 언어


요구사항 표현

1. 사용사례 다이어그램(Use case diagram)

 1) 설명

 - 시스템과 외부와의 상호 작용을 묘사하는 다이어그램

 2) 다이어그램 표시 요소

 - 사용사례 : 시스템의 목적
 - 액터 : 사용사례를 이용하는 사람이나 외부 시스템
 - 관계: 액터와 사용사례간 관계

 3) 관계 표현

  - 확장(Extension) : 선택적인 인터랙션을 명시적으로 나타낼때 또는 예외적인 사례를 다룰때 사용(상속개념과 유사)
  - 일반화(Generalization) : 여러 유사 사용사례로 일반화 함
  - 포함(Inclusion) : 여러 사용사례의 공통적인 부분을 표현

 4) 장점
  - 시스템의 범위를 정하는데 도움이 됨
  - 개발과정을 계획하는데 도움이 됨
  - 요구를 개발하고 검증하는데 사용됨
  - 테스트케이스를 정의하는데 기초가 됨
  - 사용자 매뉴얼 구성하는데 사용될 수 있음


정적인 부분 표현

1. 클래스 다이어그램 (Class Diagram)

 1) 설명

  객체지향 시스템의 가장 근간이 되는 다이어그램으로 시스템의 정적인 구조를 나타내는 다이어그램

 2) 다이어그램 표시 요소

  - 클래스 : 자료 타입 그 자체를 나타냄
  - 속성 : 객체의 상태 또는 성질
  - 오퍼레이션 : 클래스와 그 인스턴스에 의하여 수행될 함수를 나타냄
  - 연관관계 : 클래스 인스턴스 사이의 관계를 나타냄

 부가설명)
  - 추상 클래스 : 인스턴스가 없는 클래스
  - 추상 오퍼레이션 : 구현이 없는 오퍼레이션

 3) 가시성 표현

• '+' : public : 패키지 외부에서도 접근 가능
• '#' : protected : 하위 클래스로부터의 접근이 가능
• '-' : private : 클래스 내부에서만 접근이 가능
• '~' : package : 속한 동일 패키지 내에서만 가능

 부가설명)

    

 유도 속성 ( '/' : derived)

  - 다른 속성에 의해 결정될 수 있는 속성 

  - 가시성과 속성의 이름 사이에 표시

 4) 관계 표현
  - '*' : 연관관계 끝에 다중도를 표시
  - Aggregation : 전체와 부분의 관계를 나타냄 (is part of)
  - Composition : 합성관계는 Aggregation보다 강한 관계로 집합이 소멸되면 부분도 소멸됨(is composed of)
  - Propagation : 전체 개념의 오퍼레이션이 부분 개념의 오퍼레이션에 의하여 구현되는 현상

 부가설명)
  - 인터페이스 : 객체집합이 가지는 행위의 일부를 가시화 한 것으로 클래스와 유사하나 인스턴스 변수와 구현 메소드가 없음

2. 객체 다이어그램 (Object Diagram)

 1) 설명

 인스턴스들과 링크 파악, 객체들 사이의 관계 표현하는 다이어그램

• Data/Object 구조를 설명하고 Snapshot 구체화
• 분석과 설계단계에서 정의됨

참고)

 클래스 다이어그램과 차이점 : 객체들의 이름 밑에 밑줄이 그어지며 연관된 모든 인스턴스들이 표현됨

3. 패키지 다이어그램 (Package Diagram)

 1) 설명

 관련된 클래스를 패키지로 묶어 의존도를 낮추기 위해 사용

 2) 패키지

  - 공통적인 특성을 가진 클래스들의 모임
  - 재사용의 단위가 됨

 3) 관계

  - 점선 화살표는 의존관계를 나타냄
  - 컴파일 타임에 바인딩

4. 컴포넌트 다이어그램 (Component Diagram)

 1) 설명

 구현에 대한 물리적인 컴포넌트 간의 구성과 의존 관계를 표현

5. 배치 다이어그램 (Deployment Diagram)

 1) 설명

 시스템의 소프트웨어와 하드웨어 컴포넌트 사이의 관계 표현, 물리적 단계와 응용 프로그램과의 네트워크 연결을 모델링

• 컴포넌트 분포의 구체화
• 성능상의 병목현상 파악

동적인 부분 표현

1. 순차 다이어그램 (Sequence Diagram)

  1) 설명
 
  객체 간의 메시지 전달을 시간적 흐름에서 표현하는 다이어그램

  - 개체가 다이어그램에 수평으로 정렬됨
  - 인터랙션을 구동하는 액터를 왼쪽에 표시
  - 수직축은 시간의 흐름을 나타냄
  - 객체마다 라이프 라인이라 불리는 수직 점선을 붙임
  - 객체가 소멸된 후에는 라이프 라인이 중지되며 'x'로 표시
  - 객체가 구동 중임을 표시하려면 라이프 라인에 액티베이션 박스를 그림
  - 메시지는 송신자와 수신자의 액티베이션 박스 사이에 화살표로 표시
  - 메시지 이름과 매개변수를 나타내는 레이블을 붙임

참고)
 객체에 대한 반복 수행은 메시지 이름 앞에 '*'를 붙여 표시

2. 협동(협력) 다이어그램 (Collaboration Diagram)

 1) 설명

 객체와 객체가 주고받는 메시지를 중심으로 표현하는 다이어그램

  - 협동 다이어그램은 객체가 노드인 네트워크임
  - 객체들 사이에 커뮤니케이션 링크가 추가 됨
  - 메시지가 링크에 추가
  - 화살표에 메시지 이름을 붙임
  - 메시지가 호출되는 순서는 메시지 앞에 숫자를 적어 표시

 2) 커뮤니케이션 링크

  - 객체에서 다른 객체로 메시지를 보내는 것은 항상 커뮤니케이션 링크로 표시

 3) 메시지 교환이 발생하는 경우

 - 두 객체의 클래스가 연관관계에 의하여 결합한 경우
 - 메시지를 받는 객체가 보내는 객체의 로컬 변수로 저장된 경우
 - 메시지를 받은 객체에 대한 레퍼런스가 보내진 이전 메시지의 매개변수가 되는 경우
 - 받는 객체가 전역변수 인 경우
 - 객체가 네트워크를 통하여 커뮤니케이션 되는 경우

참고)

 순차, 협동 다이어그램 선택방법

• 순차 다이어그램
• 메시지의 순서를 드러내 보여주고 싶을때
• 사용사례의 시간 순서를 드러내 보이고 싶을때
• 사용사례로부터 인터랙션 모델을 구축할 차 다이어그램
• 메시지에 자세한 사항을 나타내고 싶을때
• 협동 다이어그램에서는 자세한 것을 나타낼 공간이 없음
• 협동 다이어그램
• 클래스 다이어그램의 투영
• 클래스 다이어그램을 검증할때 이용

3. 상태 다이어그램 (Statechart Diagram)

 1) 설명

  - 외부 자극에 대한 시스템의 동적 상태 변화를 나타냄.
  - 외부 이벤트에 대하여 민감하게 상태를 변화시키는 객체를 모델링
  - 시스템 전체, 일부, 개별 객체에 대한 동작을 나타냄
  - 노드는 상태를 나태내며 아크는 트랜지션을 나타내는 방향성 있는 그래프

 2) 상태

  - 주어진 시점에 시스템은 어떤 상태에 있음
  - 이벤트가 발생하여 상태를 변화시키기 전까지는 그 상태에 머물러 있음
  - 상태는 둥근 사각형 안에 상태 이름을 표시하여 나타냄

참고)

 특수상태

  - 시작 상태는 검은 원으로 표시
  - 종료 상태는 원이 둘려진 검은 점으로 표시

 3) 트랜지션

  - 이벤트에 대한 상태변화를 나타냄
  - 트랜지션 위에는 상태변화를 일으키는 이벤트를 표시

 4) 액티비티

  - 시스템이 어떤 상태에 있을때 발생하는 것

• 일정 시간이 소비됨
• 어떤 상태에서 빠져 나오는 트랜지션이 이루어짐

 5) 액션

  - 시간의 경과 없이 바로 일어날 수 있는 것(감지할 수 없는 적은 시간을 소비)

• 특정 트랜지션이 이루어질 때
• 특정 상태로 진입할 때
• 특정 상태에서 빠져나올 때

4. 액티비티 다이어그램 (Activity Diagram)

 1) 설명

 업무의 흐름을 모델링하거나 객체의 생명주기를 표현하는 다이어그램

  - 상태 다이어그램과 유사하나 대부분의 트랜지션이 내부 이벤트에 의해 이루어진다는 것이 다름
  - 객체나 컴포넌트가 수행하는 작업의 흐름을 이해하는데 사용
  - 다른 사용사례 사이의 관계나 상호작용을 가시화하는데 사용

 2) 병행처리 표현

  - fork는 단일 입구 트랜지션과 다수의 출구 트랜지션을 가짐

• 실행경로가 두개의 병행 스레드로 분할됨

  - Rendezvous는 다수의 입구 트랜지션과 다수의 출구 트랜지션을 가짐

• 모든 입구 트랜지션이 트리거되면 시스템의 모든 출구 트랜지션이 이루어짐 

  - Join은 다수의 입구 트랜지션과 단일 출구 트랜지션을 가짐

• 모든 입구 트랜지션이 이루어진 후 출그 트랜지션 발생
• 입구 트랜지션은 분리된 스레드에 의하여 트리거됨
• 먼저 이루어진 입구 트랜지션은 다른 입구 트랜지션이 이루어질 때까지 기다림

 3) 스웜레인

  액티비티 다이어그램은 대체러 여러 클래스와 관련되며 같은 스웜레인 안에 있는 액티비티들은 동일한 클래스와 관련된 것


참고)

UML Spec : http://www.omg.org/spec/UML/



소프트웨어 모델링이 필요한가?

모델링은 건축이나 토목처럼 실제 만들다가 잘못된 것이 발생했을때 고치기 어렵거나 비용이 많이 드는 분야에서 사전에 모델링하여 문제를 최대한 파악하기위해 사용되었다.
소프트웨어 개발에서 모델링은 건축이나 토목처럼 그리 효율적이지 못하다.
그러나 하드웨어와 소프트웨어가 함께 구성되고 복수의 소프트웨어가 연동되거나 복잡한 구조를 갖는 소프트웨어 개발에는 효과적일 것이다.


실제 구현하면서 문제를 바로잡는 비용 ? 모델로 설계하여 예측/검사 후 구현하는 비용?

개발자의 경험이나 협업의 정도에 따라 UML을 효과적으로 적용하여야 한다.


효과적인 모델링 적용을 위해 필요한것은?

UML은 프로젝트를 위한 협업, 의사소통의 수단일뿐 툴이나 형식에 의존하면 안됨.
핵심적인 부분은 상세화하고 그 외는 전체 시스템을 파악할 수 있는 형태로 작성.
설계를 위한 다이어그램은 코드 작성하다 꼭 필요한 경우에만 작성.


기타 활용

개발을 위한 사전 설계 외에 교육 및 유지, 관리에도 효과적.