← Docs hub

SoC TaskManager Implementation Worklog

이 장은 현재 기준 DeviceAgent TaskManager에 들어간 실제 작업내역을 업체가 따라 할 수 있는 단위로 정리한다.

소스 레벨 구현 위치와 method 단위 설명은 Source-Level Implementation Guide를 기준으로 본다. 이 장은 “무슨 파일을 왜 만들었고, 업체가 그 파일에서 무엇을 채워야 하는지”에 집중한다.

추가/정리된 핵심 파일

파일별 상세 작업내역

MainApi 연결 작업

핵심 변화:

기존:
MainApi.executeMethod(...)
-> executeMethodInternal(...)

변경:
MainApi.executeMethod(...)
-> TaskManager.handleControlMethod(...)
-> handled이면 return
-> TaskManager.executeLegacy(...)
-> executeMethodInternal(...)

이 연결의 의미:

• 기존 domain command를 제거하지 않는다.
• TaskManager API만 먼저 잡아 처리한다.
• 일반 legacy method는 기존 경로로 계속 수행한다.
• TaskManager 내부에서 실제 command 실행이 필요할 때도 TaskCommandFactory를 통해 기존 executeMethodInternal(...) 호출을 재사용한다.

TaskManager Core 작업

TaskManager.java에 들어간 core 책임:

Policy/Validation 작업

TaskPolicyRegistry는 method별 실행 성격을 정리한다.

TaskBundleValidator는 strict validation이 켜졌을 때 필수 key를 검사한다. 예를 들어 setMoveTo는 위치 후보 key가 필요하고, setAirCleanerOperation은 action/mode/speed/operation 중 하나가 필요하다.

Executor 작업

현재 executor bootstrap은 skeleton 형태다.

Event/Reason 작업

notifyTaskEvent(...)는 event payload를 구성한 뒤 두 경로로 보낸다.

1. TaskEventListener.onTaskEvent(...)
2. AppCmd.INSTANCE.sendModuleCallback_main(eventData)

event payload는 아래 성격을 포함해야 한다.

Planning Context 작업

DevicePlanningContextProvider가 제공하는 snapshot은 Cloud planner뿐 아니라 MQTT server policy, App UI, 내부 예약 정책에서도 사용할 수 있다.

현재 채워진 bundle:

main_state
battery
map
location
cleaning
movement
task_manager
capabilities

업체가 반드시 보강해야 할 부분:

• map.rooms 실제 room 목록
• location.current_room_id/name
• movement.blocked와 path blocked 상태
• capabilities를 제품/펌웨어/설정 기반으로 동적으로 산출
• queue busy 상태와 running task summary의 실기기 trace

Control API 작업내역

Executor Bootstrap 작업내역

테스트 작업내역

app/src/test/java/com/sk/airbot/deviceagent/task/TaskManagerTest.java
app/src/test/java/com/sk/airbot/deviceagent/task/TaskManagerIntegrationTest.java
app/src/androidTest/java/com/sk/airbot/deviceagent/task/TaskManagerInstrumentedTest.java

추가되어야 할 테스트