오늘의 이야기

대표이미지

Java에서 ScheduledExecutorService로 비동기 지연 처리하기

Java에서 작업을 일정 시간 후 실행하거나 주기적으로 반복하고 싶을 때 ScheduledExecutorService는 매우 유용한 도구입니다. 단순한 Thread.sleep()보다 유연하고, 비동기적으로 동작하며, 반복 작업에도 적합합니다.

🛠️ 언제 사용하면 좋을까?

• 주기적인 작업 실행 (예: 10초마다 서버 상태 체크)


• 지연된 작업 실행 (예: 버튼 클릭 후 2초 뒤 알림 표시)


• 타이머 기능 대체 (예: 게임에서 카운트다운)


• 백그라운드 유지 작업 (예: 캐시 자동 갱신)


• 멀티스레드 환경에서 안정적인 스케줄링

✨ 기본 예제 코드

import java.util.concurrent.*;

public class SchedulerExample {
    public static void main(String[] args) {
        ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);

        Runnable task = () -> System.out.println("2초 후 실행됨!");

        scheduler.schedule(task, 2, TimeUnit.SECONDS);

        System.out.println("메인 스레드는 계속 실행 중");
    }
}
  

🔍 주요 메서드

• schedule(Runnable, delay, TimeUnit): 지정된 시간 후 작업 실행


• scheduleAtFixedRate(Runnable, initialDelay, period, TimeUnit): 고정 간격으로 반복 실행


• scheduleWithFixedDelay(Runnable, initialDelay, delay, TimeUnit): 작업 종료 후 일정 지연을 두고 반복 실행

💡 Tip: 작업이 끝난 후에는 반드시 scheduler.shutdown()을 호출하여 스레드 풀을 종료하세요. 그렇지 않으면 리소스 누수가 발생할 수 있습니다.

📌 마무리

ScheduledExecutorService는 단순한 지연뿐 아니라 반복 작업, 백그라운드 처리 등 다양한 상황에서 활용할 수 있는 강력한 도구입니다. 특히 서버나 멀티스레드 환경에서 안정성과 유연성을 동시에 확보할 수 있어요.

오늘의 이야기

 

Java로 RESTful API 구현하기: Retrofit2, OkHttp3, Gson 활용

restful

 

1. Retrofit2를 활용한 API 호출 예제 및 중요 사항

Retrofit2는 Square에서 개발한 HTTP 클라이언트 라이브러리로, RESTful API 호출을 매우 간단하게 만들어줍니다.

예제 코드

public interface ApiService {
    @GET("/users/{id}")
    Call<User> getUser(@Path("id") int userId);
}

Retrofit retrofit = new Retrofit.Builder()
    .baseUrl("https://api.example.com/")
    .addConverterFactory(GsonConverterFactory.create())
    .build();

ApiService service = retrofit.create(ApiService.class);
Call<User> call = service.getUser(1);
call.enqueue(new Callback<User>() {
    @Override
    public void onResponse(Call<User> call, Response<User> response) {
        if (response.isSuccessful()) {
            System.out.println(response.body());
        }
    }

    @Override
    public void onFailure(Call<User> call, Throwable t) {
        t.printStackTrace();
    }
});
    

중요 사항

• Base URL은 반드시 /로 끝나야 합니다.


• GsonConverterFactory를 통해 JSON을 자동으로 객체로 변환합니다.


• 비동기 호출 시 enqueue()를 사용하여 UI 스레드를 차단하지 않습니다.

2. OkHttp3 단독 사용 예제 및 중요 사항

OkHttp3는 낮은 수준의 HTTP 클라이언트로, 더 많은 제어가 가능하며 직접 JSON을 생성하고 전송할 수 있습니다.

예제 코드

import okhttp3.*;

public class JsonPostExample {
    public static void main(String[] args) {
        OkHttpClient client = new OkHttpClient();

        // JSON 문자열 생성
        String jsonString = "{ \"name\": \"Kang\", \"age\": 30 }";

        // RequestBody 생성
        RequestBody body = RequestBody.create(
            jsonString,
            MediaType.parse("application/json; charset=utf-8")
        );

        // 요청 생성
        Request request = new Request.Builder()
            .url("https://your-api-endpoint.com/api/data")
            .post(body)
            .addHeader("Content-Type", "application/json")
            .build();

        // 요청 실행
        try (Response response = client.newCall(request).execute()) {
            System.out.println("응답 코드: " + response.code());
            System.out.println("응답 본문: " + response.body().string());
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

중요 사항

• JSON 문자열은 직접 생성하거나 Gson을 통해 직렬화할 수 있습니다.


• RequestBody에 MediaType을 명시해야 서버가 올바르게 인식합니다.


• 동기 방식으로 execute()를 사용하면 예외 처리를 반드시 해야 합니다.

3. Gson을 이용한 JSON 문자열 생성 및 전송 방법

Gson은 Java 객체를 JSON으로 직렬화하거나 JSON을 객체로 역직렬화하는 데 사용됩니다.

예제 코드

User user = new User("Kang", 30);
Gson gson = new Gson();
String jsonString = gson.toJson(user);

RequestBody body = RequestBody.create(
    jsonString,
    MediaType.parse("application/json; charset=utf-8")
);

Request request = new Request.Builder()
    .url("https://your-api-endpoint.com/api/data")
    .post(body)
    .build();
    
// 요청 실행
try (Response response = client.newCall(request).execute()) {
    System.out.println("응답 코드: " + response.code());
    System.out.println("응답 본문: " + response.body().string());
} catch (Exception e) {
    e.printStackTrace();
}

이렇게 생성된 jsonString은 OkHttp3를 통해 서버에 전송할 수 있습니다.

4. Retrofit2 vs OkHttp3 단독 사용 비교

항목	Retrofit2	OkHttp3
사용 편의성	높음 (인터페이스 기반)	중간 (직접 구성 필요)
유연성	중간 (추상화됨)	높음 (세부 제어 가능)
JSON 처리	자동 (Gson 연동)	수동 또는 Gson 병행
학습 곡선	낮음	높음

5. Retrofit2와 OkHttp3 단독 구현 비교 예제 및 설명

Retrofit2 예제

Retrofit retrofit = new Retrofit.Builder()
    .baseUrl("https://api.example.com/")
    .addConverterFactory(GsonConverterFactory.create())
    .build();

ApiService service = retrofit.create(ApiService.class);
Call<User> call = service.getUser(1);
call.enqueue(...);
    

OkHttp3 예제

OkHttpClient client = new OkHttpClient();
String jsonString = "{ \"name\": \"Kang\", \"age\": 30 }";

RequestBody body = RequestBody.create(
    jsonString,
    MediaType.parse("application/json; charset=utf-8")
);

Request request = new Request.Builder()
    .url("https://your-api-endpoint.com/api/data")
    .post(body)
    .build();

try (Response response = client.newCall(request).execute()) {
    System.out.println("응답 코드: " + response.code());
    System.out.println("응답 본문: " + response.body().string());
}
    

설명

Retrofit2는 선언적 방식으로 API를 정의하고 호출할 수 있어 유지보수가 쉽습니다. 반면 OkHttp3는 더 많은 제어가 가능하지만 코드가 길어지고 복잡해질 수 있습니다. 상황에 따라 적절한 선택이 중요합니다.

---

 

오늘의 이야기

2장. 개발 환경 세팅과 기본 구조

이 장의 목표는 “30일 플랜을 실행 가능한 프로젝트”로 바꾸는 일입니다. 설치만 끝내는 세팅이 아니라, 바로 화면을 띄우고 기능을 쌓아올릴 수 있는 구조를 만듭니다. 핵심은 안정성(빌드가 흔들리지 않기), 단순성(모듈/의존성 최소), 확장성(기능을 추가해도 복잡해지지 않기)입니다.

왜 구조부터 잡아야 할까요?

• 워치는 화면이 작고 상호작용이 짧습니다. 그래서 “기능 1~2개를 빠르게 완성”하는 흐름이 중요합니다. 이를 돕는 구조는 곧 개발 속도입니다.


• 초기에 정리된 모듈/의존성/상태 관리 패턴은 디버깅 시간을 절반으로 줄입니다.


• 출시 시점의 서명/정책/자산 준비까지 거슬러 올라가면, 세팅이 깔끔할수록 마지막 주가 편해집니다.

1. 필수 환경 점검

• IDE: 최신 안정 버전의 Android Studio


• SDK/에뮬: Wear OS 3 이상 에뮬레이터 1개, 실제 워치가 있다면 페어링


• 프로젝트 템플릿: Wear OS Compose 템플릿을 권장(기본 네비게이션/테마 포함)


• 패키지 네이밍: 초기에 고정(스토어/서명과 직결). 바꾸면 후반 작업이 증가합니다.

1. 프로젝트 뼈대 만들기(초기 2시간)

• 앱 이름/아이콘/패키지명 확정


• 최소 구성만 유지: app(워치 앱) + core 모듈 1~2개 정도
  
  
  
  • core:design — 테마, 색상, 타이포, 공통 컴포저블(예: PrimaryButton, AppScaffold)
  
  
  • core:model(선택) — 데이터 모델/간단한 유틸(시간 포맷 등)
  
  
  
  


• 이유: 피처 단위 모듈화는 후반으로 미루고, 먼저 “작동하는 MVP”까지 직선으로 갑니다.

1. 의존성 최소 셋업

• Wear Compose: foundation, material(혹은 Wear Material), navigation-wear


• ViewModel/코루틴: lifecycle, runtime, kotlin coroutines


• Horologist(선택적): composables(공통 UI), tiles(타일), complications 데이터 헬퍼


• 테스트: junit/robolectric(옵션), UI 테스트는 MVP 이후 추가


• 팁: 버전은 카탈로그/버전 관리 파일로 한 곳에서 관리. 흔한 충돌을 예방합니다.

1. 테마와 컴포넌트 합의(초기 30분 투자)

• MaterialTheme 시스템을 초기에 고정하세요.
  
  
  
  • 다크 전용 대비, 큰 폰트(손목 가독성 최우선), 포커스 링/터치 타깃 48dp 이상
  
  
  
  


• 버튼/칩/타이틀의 스타일 가이드를 한 번에 정리
  
  
  
  • 예: PrimaryChip, SecondaryChip, GhostChip 3종만 사용
  
  
  
  


• 자주 생기는 문제
  
  
  
  • 색 조합 과다 → 배터리/가독성에 불리
  
  
  • 컴포넌트 API 변경으로 인한 오류 → 최신 가이드를 기준으로 Defaults 기반 색상 API 사용
  
  
  
  

1. 화면 구조와 네비게이션

• 기본 흐름: 홈 → 행동(예: 타이머 시작) → 설정


• 버튼은 “한 손가락, 한 목적” 원칙을 따릅니다.


• 네비게이션 전략
  
  
  
  • 단순 스택(뒤로가기로 충분) 우선
  
  
  • 반복 진입이 잦은 기능은 타일/컴플리케이션으로 바로가기 제공
  
  
  
  


• 상태 복원: 워치는 인터럽트가 잦습니다. ViewModel + savedState를 기본으로 두세요.

1. 상태 관리 패턴(간단·명확·복원 가능)

• 단일 소스의 진실: ViewModel에 UIState를 두고, 화면은 상태만 관찰


• 이벤트 드리븐: 이벤트(시작/정지/리셋) → 리듀서(상태 변경) → UI 반영


• 예시 흐름
  
  
  
  • UI: 시작 버튼 탭 → ViewModel.onStart()
  
  
  • VM: 타이머 시작, 상태를 Running으로 → UI가 Running 레이아웃로 자동 전환
  
  
  
  


• 장점: 타이밍 이슈/회전/백그라운드 전환에도 예측 가능

1. 타일/컴플리케이션 최소 예비 설계

• 타일: 가장 자주 쓰는 액션 1개만 노출(예: 시작/정지 토글)


• 컴플리케이션: “읽자마자 끝나는 정보”만(예: 남은 시간, 오늘 횟수)


• 주의: 타일/컴플리케이션은 배터리와 밀접. 갱신 주기/데이터 소스는 “필요할 때만” 업데이트

1. 백그라운드와 배터리

• 기본 원칙
  
  
  
  • 폴링 대신 이벤트/알림 기반
  
  
  • 무거운 연산은 지연·배치(사용자 상호작용 직후엔 최대한 가볍게)
  
  
  • 네트워크는 압축/캐시/간격 확대
  
  
  
  


• 모니터링
  
  
  
  • 첫 주엔 배터리 드레인 체감 테스트(하루 사용 후 % 기록)
  
  
  • 프레임 드랍, 할당 스파이크는 즉시 기록하고 원인 메모(후반 최적화에 재활용)
  
  
  
  

1. 빌드/서명/플레이 준비(초기 발판만)

• appId/버전 코드 정책을 초기에 문서화
  
  
  
  • 예: 마이너(주 단위), 패치(버그), 코드 자동 증가
  
  
  
  


• 서명 키는 안전한 저장소에 백업(유실 시 업데이트 불가)


• 릴리즈 빌드 프로필을 미리 만들어 “릴리즈 빌드가 항상 돈다”는 신뢰 확보

1. 자주 막히는 포인트와 해결 루틴

• 의존성 충돌: 한 번에 여러 라이브러리를 올리지 말고, 1개씩 추가 후 빌드


• 구식 API/빌더 혼용: 최신 컴포저블/Defaults API로 마이그레이션(경고는 즉시 해소)


• 타입 불일치/오버로드 혼동: 함수 시그니처를 주석으로 고정, 공용 팩토리 함수로 단일화


• 디버그 메시지: 재현 경로/기기 상태를 함께 메모(다음 버그 때 검색 효율↑)

퀵 체크리스트(오늘 완료 목표)

• Wear Compose 템플릿으로 새 프로젝트 생성


• core:design 모듈 분리, Primary/Secondary 컴포넌트 3종 정의


• ViewModel + UIState 틀 완성(시작/정지/리셋 이벤트만 우선)


• 홈–행동–설정 3화면 뼈대 연결


• 타일 1개, 컴플리케이션 1개 ‘자리’만 먼저 잡기(나중에 로직 연결)


• 릴리즈 빌드 구성과 버전 정책 초안 문서화

작게 테스트하는 방법

• 에뮬에서 폰 연결 없이 5분 테스트: 시작–정지–재개만 확인


• 대비/터치: 어두운 공간에서 팔을 살짝 움직이며 가독성 체크


• 배터리: “기능 없이” 앱을 켜두고 30분 소모율 기록(기준선 만들기)

실전 팁

• 시작–정지–재개 같은 핵심 액션은 “타일 → 알림 → 앱 본문” 3가지 진입로를 모두 지원하면 재방문율이 오릅니다.


• 공통 여백/폰트 크기는 초기에 강제(디자인 시스템). 화면별 임의 조정은 나중에 빚이 됩니다.


• 컴포넌트 개수는 적을수록 유지보수가 쉽습니다. 대표 버튼/칩만 만들어 돌려 쓰세요.

요약 포인트

• 단순한 모듈 구조 + 일관된 테마 + 예측 가능한 상태 관리가 개발 속도를 만듭니다.


• 타일/컴플리케이션은 “한 가지 가치”에 집중하고, 배터리는 기본값으로 지킵니다.


• 릴리즈 빌드는 지금부터 항상 성공해야 합니다. 출시 주에 환경과 싸우지 마세요.

 

앱 이미지

 

오늘의 이야기

#스치니1000프로젝트 #재미 #행운기원 #Compose #Firebase

🎯 야 너 토요일마다 로또 확인하냐?
나도 맨날 “혹시나~” 하면서 봤거든 ㅋㅋ

근데 이제는 그냥 안 해
AI한테 맡겼어 🤖✨

그것도 구글 Gemini로다가!

그래서 앱 하나 만들었지
👉 “로또 예상번호 by Gemini” 🎱

AI가 분석해서 번호 딱! 뽑아줌
그냥 보고 참고만 하면 됨

재미로 해도 좋고…
혹시 모르는 거잖아? 😏


https://play.google.com/store/apps/details?id=com.billcorea.gptlotto1127

오늘의 이야기

7장. 데이터 기반 개선과 마케팅 운영

 

이 장의 목표는 “출시 이후 2주 안에 의미 있는 개선과 첫 매출 신호”를 만드는 것입니다. 핵심은 적게 측정하고 빠르게 실행하며, 사용자 피드백을 제품·스토어·마케팅에 곧바로 반영하는 루프를 만드는 일입니다.

목표와 핵심 지표(KPI) 정의

• 최우선 지표
  
  
  
  • 활성화율: 설치 → 첫 핵심 행동(예: 시작) 전환율 60%+
  
  
  • D1/D7 유지율: D1 35%+/D7 15%+를 1차 목표
  
  
  • 첫 행동까지 시간: 첫 실행 → 첫 핵심 행동 30초 이내
  
  
  
  


• 품질 지표
  
  
  
  • Crash-free 세션 99%+, ANR 0.3% 이하
  
  
  • 별점 4.3+와 리뷰 10건(출시 후 2주)
  
  
  
  


• 수익 지표(유료/업그레이드 시)
  
  
  
  • 프로 전환율 2~5% 범위 탐색
  
  
  • 환불률 3% 이하 유지
  
  
  
  

필수 이벤트 7개(가볍고 배터리 친화)

• app_open(앱 실행)


• onboarding_complete(첫 실행 흐름 완료)


• action_start(핵심 행동 시작)


• action_mark(중간 행동, 예: 랩)


• action_stop(핵심 행동 종료)


• tile_tap(타일 탭)


• notif_action(알림 액션 탭) 팁: 화면 조회 이벤트는 최소화하고, “행동 중심” 이벤트만 남겨 배터리·프라이버시 부담을 줄이세요.

퍼널 설계와 병목 발견

• 퍼널 단계: 설치 → 첫 실행 → 권한 처리 → 홈 노출 → 핵심 행동 시작 → 완료 → 재방문


• 자주 막히는 지점
  
  
  
  • 권한 단계 이탈: 권한 요청을 “필요 순간”으로 늦추고 대체 경로를 제시
  
  
  • 홈 과밀: 첫 화면에서 버튼 1개 외 요소를 줄여 탭 유도
  
  
  • 재방문 부진: 타일/알림 진입로 노출이 부족하거나 상태 불일치
  
  
  
  


• 빠른 처방
  
  
  
  • 홈 히어로 버튼 라벨을 동사형으로 단순화(“시작하기”)
  
  
  • 타일 기본 추가 안내(첫 성공 후 1회만 토스트/배너)
  
  
  • 완료 직후 “다시 시작”을 같은 위치·같은 스타일로 고정
  
  
  
  

리뷰·피드백 루프(24시간 내 응답 체계)

• 요청 타이밍: 두 번째 성공 경험 직후 1회만 노출(과용 금지)


• 응답 원칙
  
  
  
  • 별점 1~2: 사과+해결 행동(문의 폼/버그 픽스 ETA)
  
  
  • 별점 3: 개선 약속+가볍게 재시도 유도
  
  
  • 별점 4~5: 감사+타일/컴플리케이션 팁 1가지 제공
  
  
  
  


• 경로 추가
  
  
  
  • 스토어 이메일 + 30초 피드백 폼(단답 3문항) 링크를 설명 하단에 배치
  
  
  
  

경량 A/B 실험(2주, 저비용·고효과)

• 실험 대상
  
  
  
  • 홈 핵심 버튼 라벨: “시작” vs “바로 시작”
  
  
  • 완료 화면 메시지: “성공! 다시 시작” vs “좋아요! 새 랩 시작”
  
  
  • 스토어 짧은 설명: 결과 중심 문구 A/B
  
  
  
  


• 주의
  
  
  
  • 동시에 1~2개만 진행, 목표 지표를 1개로 고정(예: 활성화율)
  
  
  • 유의미 표본이 부족하면 “명백히 떨어지는 안”을 빠르게 제외하는 방식으로 운용
  
  
  
  

초경량 대시보드(하루 10분 점검)

• 일일: 신규 설치, 활성화율, 크래시 수, 리뷰 수/평점


• 주간: D1/D7, 재방문 비율, 프로 전환율/환불률


• 품질: 알림/타일 액션 대비 실제 상태 싱크 실패율(목표 <1%)

알림·재참여 전략(절제가 성과)

• 트리거
  
  
  
  • 미완료 세션 재개(앱 종료 30분 후 1회)
  
  
  • 주목표 미달(일일 목표 미달 시 다음날 오전 1회)
  
  
  
  


• 톤과 빈도
  
  
  
  • 하루 1회 이하, 사용자가 끌 수 있는 옵션 제공
  
  
  • 상태 전달은 짧게, 행동은 명확하게(예: “랩 다시 시작”)
  
  
  
  


• 효과 측정
  
  
  
  • 알림 노출 대비 액션 전환률, 차단률 추적
  
  
  
  

스토어 최적화(ASO) 체크

• 이름: 주 행동+플랫폼 명시(예: “랩타임 – Wear”)


• 짧은 설명: 결과 중심 1문장, 80자 내


• 스크린샷: 홈–주 행동–완료–타일–컴플리케이션 순, 텍스트는 4~6단어


• 업데이트 로그: “체감 개선”을 맨 앞에(예: 배터리 -2%p, 첫 실행 -0.5초)


• 응답 속도: 리뷰 답변 24시간 내, 상위 3개 질문은 상세 설명에 반영

가격·전환 최적화(수익 관점)

• 초기가격: 전자책 독자 전용 코드/번들 혜택으로 ‘지금’ 구매 유도


• 벽 설계: 무료로 핵심 가치를 맛보게 하고, 반복 사용 시 편의 기능을 유료로 개방


• 전환 메시지: “하루 90분 단축”처럼 시간·배터리·정확도 등 수치형 가치 제시


• 환불 방어: 체험 기간 또는 최초 결제 후 48시간 ‘무조건 환불’ 명시로 신뢰 확보

콘텐츠·커뮤니티 운영(가벼운 마케팅 자동화)

• 주 1회 개발 로그(블로그/노션): 무엇을 줄였고 무엇이 빨라졌는지 “전·후” 중심


• 짧은 영상 1개: 타일/알림으로 1탭 실행 데모(15초)


• 커뮤니티 공유: 안드로이드/웨어 포럼에 “체크리스트” 형태로 발췌 공유


• 협업 포인트: 러닝/생산성 커뮤니티와 크로스 프로모션(코드 제공)

첫 2주 운영 스프린트(예시)

• D+1: 크래시/권한 이슈 핫픽스


• D+3: 홈 라벨 A/B 시작, 리뷰 응답 템플릿 적용


• D+5: 스토어 짧은 설명 B안 테스트, 스크린샷 1장 교체


• D+7: 알림 트리거 1개만 활성화(절제), 차단률 관찰


• D+10: 배터리 최적화 패치(애니메이션/주기 타이머 점검)


• D+14: 실험 결과 정리 → 승자안 고정, 다음 사이클 설계

문제 → 시도 → 변화 → 교훈 기록법

• 문제: “설치 대비 첫 행동 48%”


• 시도: “홈 라벨 변경 + 권한 지연 요청”


• 변화: “활성화율 48% → 63%, 권한 이탈 -30%”


• 교훈: “동사형 라벨·지연 권한이 초기 전환에 직결”

요약 포인트

• 행동 중심으로 최소 이벤트만 측정하고, 2주 주기로 실험–고정 루프를 돌리세요.


• 리뷰 응답과 스토어 자산 수정을 가장 빠르게 실행하면 전환이 바로 좋아집니다.


• 알림·가격은 절제와 명확한 가치 제시가 핵심입니다.

오늘의 수행 미션

• 이벤트 7개만 연동하고, 일일/주간 대시보드를 만들기


• 홈 라벨 A/B 한 가지, 스토어 짧은 설명 A/B 한 가지 시작


• 리뷰 응답 템플릿 작성 후 24시간 내 응답 체계 운영


• 알림 트리거 1개만 활성화하고 차단률/전환률 기록

 

앱 이미지

 

오늘의 이야기

#스하리1000명프로젝트,
한국에서 길을 잃었나요? 한국어를 못하더라도 이 앱을 사용하면 쉽게 돌아다닐 수 있습니다.
귀하의 언어로 말하면 귀하의 언어로 번역, 검색 및 결과가 표시됩니다.
여행자에게 좋습니다! 영어, 일본어, 중국어, 베트남어 등 10개 이상의 언어를 지원합니다.
지금 사용해 보세요!
https://play.google.com/store/apps/details?id=com.billcoreatech.opdgang1127

오늘의 이야기

#스하리1000명프로젝트

오늘 내가 만든앱 하나 알려주고 싶어, 이 앱은 알림수집기 라고 이름을 붙였는 데,
내 폰에 표시 되는 알림을 읽어서 내가 지정한 단어가 들어 있고, 지출기록을 남겨야 하는 알림이
있으면 수집하고, 카카오톡으로 친구에게 전달해 주는 기능을 구현해 줄꺼야. 📲

이번 패치에서는 하루 한번 지정한 시간에 나에게 알림(노티) 하도록 기능을 추가 했어. 🙏
한번 써보고 불편한 거 있으면 말해줘.

앱 바로가기
👉 https://play.google.com/store/apps/details?id=com.nari.notify2kakao

오늘의 이야기

설정화면

 

이 앱은  배드민턴 동호회 같은 운동 동아리를 위해 작성 되어 관리 되어 집니다. 

1. 처음 시작

동아리 모임원들을 하나의 데이터로 관리 하기 위해서는  관리자이메일 주소를 기반으로 합니다. 

* 꼭 사용 가능한 주소가 아니라도 상관 없습니다.   

 

관리자자 이메일주소에 동일한 값으로 채우는 것만으로도 사용이 가능 합니다. 

 

 

2. 별칭/이름 : 사용자의 별명으로 관리 되며 회원을 구분하기 위해서 사용 됩니다. 

 

 

3. bpm 설정값은 : 이 앱을 사용 사용하는 사용자가 위치앱을 사용할 수 있다면 , 워치 앱에서 bpm 을 감지하고 지정된 bpm (심박수)을 초과 하는 경우 위치 앱으로 알림을 주도록 하기 위해서 사용 됩니다. 

 

4. 경기장 위치 설정 

위치 설정 방법은 지도 클릭 하면, 전체 화면으로 지도가 나타나고 해당 지도에서 위치를 2~3초 가량 클릭해 저장 하는 방법이 있거나, 

 

돋보기 버튼으로 주소(도로명주소)를 입력해 해당 위치를 지도에 표시 되게 하여 지정 하는 방법이 있습니다. 

 

* nearyby (근접기기) 인식 기능은 개발 중 입니다.

 

 

 

 

 

 

 

*** 관리자는 1명만 지정할 수 있습니다. 관리자의 역활은 데이터 관리의 주최가 되는 것 말고는 다른 기능은 모든 사용자가 동일하게 사용 됩니다. 

 

첫화면

 

 

 

2. 첫 화면 에서는 

 

** 오늘의 일정 : 경기일정이 잡혀 있는 경우 해당탭에 표시 됩니다.  경기장 장소 는 이름으로만 표시 되며, 관리자가 등록한 위치에 대한 이름으로 표시 됩니다. 

* 나의 정보에서 수정하더라도 관리자가 아닌 경우는 적용 되지 않습니다. 

 

** 내 경기 : 오늘 날자에 경기 일정이 있는 경우 해당 일정이 표시 됩니다. 

 

** 리그 전적 : 경기종료가 저장 되면, 나의 경기전적이 표시 됩니다. 

 

** 내 채팅 이력 

가장 최근에 했떤 자유대화방의 내용 일부가 조회 됩니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

참가자명단 화면

 

 

3. 참가자 명단 화면

 

이 앱은 위치정보를 통해 자동으로 경기 참여 여부가 저장 되도록 되어 있습니다. 

 

** 참여 하기 :  위치정보와 상관 없이 경기 참여자 명단에 등록 하기 위해서 사용 됩니다. 

 

** 퇴장 하기 : 위치정보와 상관 없이 경기 참여자 명단에서 퇴장 하기 위해서 사용 됩니다. 

 

위치정보를 기반으로 자동 참여가 설정 될 수 있습니다. 

 

위치정보는 관리자가 지정한 위치 반경 100m 이내 입니다. 

 

나의정보에서 표시 되니 참고 하시기 바랍니다. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

경기설정

 

4. 경기 설정

 

경기설정에서는 단식, 복식을 선택하고

 

시작까지 남은 시간 선택 :  경기일정 확정시 첫 경기는 시작까지의 간격으로 자동 설정 됩니다. 

 

경기시간 : 경기 단위별  경기 소요시간을 설정 하면, 그 다음 경기 시작 시간 설정시 자동 설정 됩니다. 

 

휴식 : 경기 단위 사이에 휴식 시간을 설정 됩니다.

 

** 일정 만들기 : 참여자 명단에 나와 있는 회원명단을 기준으로 단식, 복식 경기 일정을 자동으로 생성 합니다. 

 

** 경기 일정 확정 : 임시 설정된 경기 일정을 확정해 기록 합니다. 

 

확정된 일정은 다음 탭에서 확인할 수 있습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

경기일정

 

 

5. 경기 일정

 

설정된 경기 일정이 표시 됩니다. 

 

** 알림 보내기 : 선택된 경기에 참여자에게 경기시작 알림을 전달 합니다. 

 

** 경기 시작 : 경기가 시작 되었음을 기록 하게 됩니다. (버튼은 경기 종료 로 변경 됩니다.)

 

** 경기시작 수정 : 수정 버튼을 클릭 하면 경기 시작 시간을 변경 합니다. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

경기 종료 시작 클릭시

 

 

5-1 경기 종료

 

** 경기 종료 : 경기 종료 되면, 경기 종료를 클릭 하여  해당 경기가 종료 되었음을 저장 합니다. 

(해당 버튼은 승리팀 지정하기 버튼으로 전환 됩니다.)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

승리팀 선택하기

 

5-2 승리팀 지정하기

 

승리팀을 선택하고 확인 하면 해당 경기는 승리팀이 정리 되어 화면에서 사라집니다. 

또한 경기 전적은 첫화면에서 표시 됩니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

자유대화방

 

6 자유 대화방

 

자유대화방은 자유롭게 대화를 할 수 있습니다. 

모든 대화 내용은 암호화 대서 저장 됩니다. 

 

** 카메라을 통해 바로 촬영해 전송할 수 있고, 

** 갤러리의 사진을 선택해서 전송할 수 있습니다. 

** 전송된 이미지는 firebase storefile 에 저장 됩니다.  (저장된 이미지는 다른 방법으로는 조회 되지 않으며, 채팅방 에서 만 조회 되며 다른 방법으로는 조회 되지 않습니다.)

** 오래된(30일 경과된) 이미지는 삭제될 수 도 있습니다. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

7. watch 앱 화면

watch 앱 화면

이 앱은 watch 와 연동 합니다.  이 phone 앱의 사용자 설정에서 bpm 의 설정을 할 수 있습니다. 해당 정보는 watch 앱으로 전달 되며, watch 앱에서 취득 되는 bpm 의 숫자가 설정치를 초과 하는 경우 watch 앱으로 알림이 전달 됩니다. 

 

watch 앱에서는 하트 이미지를 클릭 할 때 마다, 파란색 버튼이 되는 경우 phone 앱에서 요청이 되지 않도록 자체적으로 bpm 측정을 시작 하며, 하트 이미지가 빨간색이 되면 측정이 중지 됩니다. 

 

watch 에서는 타일로 설정할 수 있습니다. 타일이 설정 되면, watch 에서 타일에 표시 되어 더 빠르게 앱에 접근할 수 있습니다.