728x90

헤더 요청 방식

헤더 요청 방식 형태의 예 

interface SearchService {
    @Headers("Authorization: KakaoAK ${REST_API_KEY}")
    @GET("image")
    suspend fun searchImage(@Query("query") query: String): ImageListResponse
   
    @Headers("Authorization: KakaoAK ${REST_API_KEY}")
    @GET("vclip")
    suspend fun searchVideo(@Query("query") query: String): VideoListResponse
}

 

이런 형태의 요청을 OkHttpClient를 생성할 때 addInterceptor에 추가해주면 된다. 

class HeaderInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain
            .request()
            .newBuilder()
            .addHeader("Authorization", "KakaoAK ${REST_API_KEY}")
            .build()
        return chain.proceed(request)
    }
}

 

RetrofitManager 오브젝트 

object RetrofitManager {
    private val okhttpClient by lazy {
        OkHttpClient
            .Builder()
            .readTimeout(5, TimeUnit.SECONDS)
            .writeTimeout(5, TimeUnit.SECONDS)
            .connectTimeout(5, TimeUnit.SECONDS)
            .addInterceptor(HeaderInterceptor())  //header 삽입// 
            .build()
    }
    private val gson by lazy {
        GsonBuilder()
            .setLenient()
            .setDateFormat("yyyy-MM-dd'T':HH:mm:ss.SSSXXX")
            .create()
    }
    private val retrofit by lazy {
        Retrofit.Builder()
            .baseUrl(BASE_URL)
            .client(okhttpClient)
            .addConverterFactory(GsonConverterFactory.create(gson))
            .build()
    }
    val searchService: SearchService by lazy { retrofit.create(SearchService::class.java) }

    class HeaderInterceptor : Interceptor {
        override fun intercept(chain: Interceptor.Chain): Response {
            val request = chain
                .request()
                .newBuilder()
                .addHeader("Authorization", "KakaoAK ${REST_API_KEY}")
                .build()
            return chain.proceed(request)
        }
    }
}

 


쿼리 요청 방식 

쿼리 요청 방식 형태의 예 

interface FetchRemoteDatasource {
    @GET("pblprfr")
    suspend fun fetchShowList(
        @Query("service") service:String = KOPIS_API_KEY
        @Query("stdate") stdate: String,
        @Query("eddate") eddate: String,
        @Query("cpage") cpage: String = Constants.CURRENT_PAGE,
        @Query("rows") rows: String = Constants.PAGE_INDEX,
        @Query("openrun") openrun: String? = null,
        @Query("newsql") newsql: String? = "Y",
        @Query("shcate") shcate: String? = null,
        @Query("kidstate") kidstate: String? = null,
        @Query("prfstate") prfstate: String? = null,
    ): DbsResponse

    @GET("boxoffice")
    suspend fun fetchTopRank(
        @Query("service") service:String = KOPIS_API_KEY
        @Query("ststype") ststype: String,
        @Query("date") date: String = Converter.nowDateOneDayAgo()
        @Query("catecode") catecode: String? = null,
        @Query("area") area: String? = null,
        @Query("newsql") newsql: String? = "Y",
    ): BoxOfsResponse

}

 

쿼리 요청방식은 헤더를 추가하는 방식과 약간 다름 

addQureyParameter로 쿼리 파라미터를 추가해줌 

//Class 형태 
class ApiKeyInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val originalRequest = chain.request()
        val originalHttpUrl = originalRequest.url
        val url =
            originalHttpUrl.newBuilder().addQueryParameter("service", KOPIS_API_KEY).build()
        val request = originalRequest.newBuilder().url(url).build()
        return chain.proceed(request)
    }
}

//변수 형태
private val apiKeyInterceptor = Interceptor { chain ->
    val originalRequest = chain.request()
    val originalHttpUrl = originalRequest.url
    val url = originalHttpUrl.newBuilder().addQueryParameter("service", KOPIS_API_KEY).build()
    val request = originalRequest.newBuilder().url(url).build()
    chain.proceed(request)
}

 

마찬가지로, OkHttpClient를 생성할 때 addInterceptor로 추가

object RetrofitClient {
    // API Key 삽입을 위한 인터셉터
    //class 형태 
    class ApiKeyInterceptor : Interceptor {
        override fun intercept(chain: Interceptor.Chain): Response {
            val originalRequest = chain.request()
            val originalHttpUrl = originalRequest.url
            val url =
                originalHttpUrl.newBuilder().addQueryParameter("service", KOPIS_API_KEY).build()
            val request = originalRequest.newBuilder().url(url).build()
            return chain.proceed(request)
        }
    }
	//변수 형태
    private val apiKeyInterceptor = Interceptor { chain ->
        val originalRequest = chain.request()
        val originalHttpUrl = originalRequest.url
        val url = originalHttpUrl.newBuilder().addQueryParameter("service", KOPIS_API_KEY).build()
        val request = originalRequest.newBuilder().url(url).build()
        chain.proceed(request)
    }

    // OkHttpClient 설정
    private val okHttpClient = OkHttpClient.Builder()
        .addInterceptor(apiKeyInterceptor) // 또는 ApiKeyInterceptor() 
        .readTimeout(15, TimeUnit.SECONDS)
        .writeTimeout(15, TimeUnit.SECONDS)
        .connectTimeout(15, TimeUnit.SECONDS)
        .build()

    // Retrofit 설정
    private val retrofit: Retrofit by lazy {
        Retrofit.Builder()
            .baseUrl(BASE_URL)
            .client(okHttpClient)
            .addConverterFactory(SimpleXmlConverterFactory.create())
            .build()
    }

    val fetch: FetchRemoteDatasource by lazy { retrofit.create(FetchRemoteDatasource::class.java) }
    val search: SearchRemoteDatasource by lazy { retrofit.create(SearchRemoteDatasource::class.java) }
}

 

 

두 코드 모두 동일한 기능을 수행하지만, 클래스 형태가 가독성과 재사용성 측면에서 조금 더 나을 수 있음

  • 가독성 : 클래스 형태는 코드의 구조가 명확하고 가독성이 높다.
  • 재사용성 : 클래스 형태는 다른 곳에서 재사용하기 용이하다.
  • 간결성: 변수 형태는 람다 표현식을 사용하여 간결하게 Interceptor를 구현할 수 있다.



 

728x90

RESTful API

  • RESTful API는 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스이다. 
  • 안전하고 신뢰할 수 있으며 효율적인 소프트웨어 통신 표준을 따르므로 이러한 정보 교환을 지원한다. 

REST

  • Representational State Transfer(REST)는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처이다. 
  • REST 아키텍처 스타일을 따르는 API를 REST API라고 한다. 
  • REST 아키텍처를 구현하는 웹 서비스를 RESTful 웹 서비스라고 한다.
    • RESTful API라는 용어는 일반적으로 RESTful 웹 API를 나타낸다. 하지만, REST API와 RESTful API라는 용어는 같은 의미로 사용할 수 있다.
  • REST 기반 아키텍처를 사용하여 대규모의 고성능 통신을 안정적으로 지원할 수 있다. 
  • 쉽게 구현하고 수정할 수 있어 모든 API 시스템을 파악하고 여러 플랫폼에서 사용한다.

API

  • 애플리케이션 프로그래밍 인터페이스(API)는 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의
  • 개발자는 다른 애플리케이션이 프로그래밍 방식으로 애플리케이션과 통신할 수 있도록 API를 표시하거나 생성
    • ex) 근무 시간 기록 애플리케이션은 직원의 전체 이름과 날짜 범위를 요청하는 API를 표시 → 이 정보가 수신되면 내부적으로 직원의 근무 시간 기록을 처리하고 해당 날짜 범위에서 근무한 시간을 반환
  • API는 클라이언트와 리소스 사이의 게이트웨이라고 생각할 수 있다.

클라이언트

  • 클라이언트는 서버로부터 서비스를 요청하는 컴퓨터 또는 애플리케이션  
    • 웹 브라우저, 모바일 앱, 데스크톱 프로그램 등
  • 클라이언트는 API를 사용하는 사람이거나 소프트웨어 시스템일 수 있다. 
    • 웹 브라우저는 웹 서버로부터 웹 페이지를 요청하는 클라이언트
    • 모바일 앱은 API 서버로부터 데이터를 요청하는 클라이언트
    • 데스크톱 프로그램은 파일 서버로부터 파일을 요청하는 클라이언트

리소스

  • 서버가 제공하는 서비스 또는 데이터
    • 다양한 애플리케이션이 클라이언트에게 제공하는 정보이다.
  • 리소스는 이미지, 동영상, 텍스트, 숫자 또는 모든 유형의 데이터일 수 있다. 
  • 클라이언트에 리소스를 제공하는 시스템을 서버라고도 함
  • 조직은 API를 사용하여 리소스를 공유하고 보안, 제어 및 인증을 유지하면서 웹 서비스를 제공한다.

RESTful API는 어떻게 작동하는지

  • RESTful API의 기본 기능은 인터넷 브라우징과 동일
  • 클라이언트는 리소스가 필요할 때 API를 사용하여 서버에 접속
  1. 클라이언트가 서버에 요청을 전송
    • 클라이언트가 API 문서에 따라 서버가 이해하는 방식으로 요청 형식을 지정
  2. 서버가 클라이언트를 인증하고 해당 요청을 수행할 수 있는 권한이 클라이언트에 있는지 확인
  3. 서버가 요청을 수신하고 내부적으로 처리
  4. 서버가 클라이언트에 응답을 반환
    • 응답에는 요청이 성공했는지 여부를 클라이언트에 알려주는 정보가 포함
    •  응답에는 클라이언트가 요청한 모든 정보도 포함

RESTful API 클라이언트 요청에는 무엇이 포함되어 있는 것

고유 리소스 식별자

  • 서버는 고유한 리소스 식별자로 각 리소스를 식별
  • REST 서비스의 경우 서버는 일반적으로 URL(Uniform Resource Locator)을 사용하여 리소스 식별을 수행
  •  URL은 리소스에 대한 경로를 지정. URL은 웹페이지를 방문하기 위해 브라우저에 입력하는 웹 사이트 주소와 유사하다.
  • URL은 요청 엔드포인트라고도 하며 클라이언트가 요구하는 사항을 서버에 명확하게 지정한다.

메서드

HTTP 메서드는 클라이언트가 서버에 요청할 때 사용하는 명령어이다.

 

4가지 일반적인 HTTP 메서드 :


GET : 리소스를 조회 / 서버는 리소스의 표현을 응답으로 반환 (예: 웹 페이지를 요청)

  • 클라이언트는 GET을 사용하여 서버의 지정된 URL에 있는 리소스에 액세스 한다.
  • GET 요청을 캐싱하고 RESTful API 요청에 파라미터를 넣어 전송하여 전송 전에 데이터를 필터링하도록 서버에 지시할 수 있다.

POST : 새로운 리소스를 생성 / 클라이언트는 요청 본문에 새 리소스의 데이터를 포함한다. (예: 회원 가입)

  • 클라이언트는 POST를 사용하여 서버에 데이터를 전송한다.
    • 요청과 함께 데이터 표현이 포함
  • 동일한 POST 요청을 여러 번 전송하면 동일한 리소스를 여러 번 생성하는 부작용이 있다.


PUT : 기존 리소스를 수정 / 클라이언트는 요청 본문에 수정된 리소스의 데이터를 포함 (예: 프로필 정보 변경)

  • 클라이언트는 PUT을 사용하여 서버의 기존 리소스를 업데이트
  • POST와 달리, RESTful 웹 서비스에서 동일한 PUT 요청을 여러 번 전송해도 결과는 동일


DELETE : 리소스를 삭제 / 서버는 요청된 리소스를 삭제한다. (예: 게시물 삭제)

  • 클라이언트는 DELETE 요청을 사용하여 리소스를 제거한다.
  • DELETE 요청은 서버 상태를 변경할 수 있다.
    • 사용자에게 적절한 인증이 없으면 요청은 실패한다.

HTTP 헤더

  • 요청 헤더는 클라이언트와 서버 간에 교환되는 메타데이터이다.
  • 서버 간의 통신을 제어하고 정보를 전달하는 데 사용
  • 요청 헤더는 요청 및 응답의 형식을 나타내고 요청 상태 등에 대한 정보를 제공한다.
    • 요청하는 리소스의 식별자 (예: URL)
    • 요청하는 리소스의 형식 (예: HTML, JSON)
    • 클라이언트가 지원하는 언어
    • 클라이언트 인증 정보
    • 쿠키

데이터

REST API 요청에는 POST, PUT 및 기타 HTTP 메서드가 성공적으로 작동하기 위한 데이터가 포함될 수 있다.

파라미터

RESTful API 요청에는 수행해야 할 작업에 대한 자세한 정보를 서버에 제공하는 파라미터가 포함될 수 있다.

 

파라미터 유형

URL 세부정보를 지정하는 경로 파라미터.
리소스에 대한 추가 정보를 요청하는 쿼리 파라미터.
클라이언트를 빠르게 인증하는 쿠키 파라미터.


RESTful API 인증

RESTful 서비스는 응답을 보내기 전에 먼저 요청을 인증해야 한다. 인증은 신원을 확인하는 프로세스다.

RESTful API에는 4가지의 일반적인 인증 방법이 있다.

 

API 키

  • API 키는 REST API 인증을 위한 또 다른 옵션
  • 서버는 고유하게 생성된 값을 최초 클라이언트에 할당
  • 클라이언트는 리소스에 액세스 하려고 할 때마다 고유한 API 키를 사용하여 본인을 검증
  • API 키의 경우 클라이언트가 이 키를 전송해야 해서 네트워크 도난에 취약하기 때문에 덜 안전

OAuth

  • OAuth는 모든 시스템에 대해 매우 안전한 로그인 액세스를 보장하기 위해 암호와 토큰을 결합한다.
  • 서버는 먼저 암호를 요청한 다음 권한 부여 프로세스를 완료하기 위해 추가 토큰을 요청
  • 특정 범위와 수명으로 언제든지 토큰을 확인할 수 있다.

HTTP 인증

HTTP는 REST API를 구현할 때 직접 사용할 수 있는 일부 인증 체계를 정의한다. 

  • 기본 인증

기본 인증에서 클라이언트는 요청 헤더에 사용자 이름과 암호를 넣어 전송한다. 안전한 전송을 위해 이 페어를 64자의 세트로 변환하는 인코딩 기술인 base64로 인코딩한다.

  • 전달자 인증

전달자(bearer) 인증이라는 용어는 토큰 전달자에 대한 액세스 제어를 제공하는 프로세스를 나타낸다. 일반적으로 전달자 토큰은 서버가 로그인 요청에 대한 응답으로 생성하는 암호화된 문자열이다. 클라이언트는 리소스에 액세스 하기 위해 요청 헤더에 토큰을 넣어 전송한다.

 

 

 

참고

https://aws.amazon.com/ko/what-is/restful-api/

 

RESTful API란 무엇인가요? - RESTful API 설명 - AWS

Amazon API Gateway는 어떤 규모에서든 개발자가 API를 손쉽게 생성, 게시, 유지 관리, 모니터링 및 보안 유지할 수 있도록 하는 완전관리형 서비스입니다. API Gateway를 사용하면 실시간 양방향 통신 애

aws.amazon.com

 

728x90

주요 차이점 :

  • 모듈성 : Fragment는 보다 모듈화 되고 재사용 가능하며 , 여러 Activity에서 나타나는 UI 구성 요소에 이상적이다.
  • 생명 주기 : Activity는 여러 Fragment를 포함하고 관리할 수 있으며 독립적인 존재지만 , Fragment는 일반적으로 자신이 속한 Activity에 종속되어 있다.
  • UI 디자인의 유연성 : Activity는 전체 화면을 차지하고, Fragment는 전체 화면이 아닌 일부 화면으로
    구성할 수 있기 때문에 Fragment가 상대적으로 유연한 UI디자인이 가능하다.
    • 태블릿과 같은 대형 화면 레이아웃에서 여러 프래그먼트를 한 화면에 동시에 표시할 수 있다.

 

Activity는 앱의 다양한 섹션 또는 "화면" 을 제시하는 주요 방법이며 , Fragment는 정교한 사용자 인터페이스를 만드는 데 있어 동적이고 재사용 가능한 방법을 제공한다.

 

참고

https://velog.io/@asdsad8664/Activity-%EC%99%80-Fragment%EC%9D%98-%EC%B0%A8%EC%9D%B4

 

Activity 와 Fragment의 차이

Android Activity 와 Fragment의 차이점정의 : 안드로이드에서 액티비티는 사용자 인터페이스를 가진 단일 화면으로 작동합니다. 앱의 내용이 표시되는 프레임 또는 창과 같습니다. 각 액티비티는 독립

velog.io

 

728x90

Context 란 

Application/Activity 현재 정보, 흐름을 담고 있는 객체이며, 새로 생성된 객체에게 해당 실행 맥락을 제공한다.

 

  • Application 환경에 관한 전체 정보를 받을 수 있는 추상 클래스Activity, Brodcast Receiver, Service를 시작할 때도 사용되고 리소스에 접근할 때도 Context가 사용됨
  • Application과 관련된 정보에 접근 또는 Application과 연관된 시스템 레벨의 함수를 호출하고자 할 때 Context 필요 
  • 안드로이드는 Application 관련 정보를 ActivityManagerService에서 관리
    • Application과 관련된 정보에 접근하려고 할 때 식별자가 필요한데, 그 역할을 하는 것도 Context

 

Context의 구분(종류)

 

Application Context

  • Application의 맥락을 담고 있는 Context
  • 싱글톤 객체임
  • Activity에서 Context로 제공을 요청
  • 해당 Application과 생명 주기가 같고, Application 전역에서 유효
    • Application이 시작될 때 생성되고, 종료될 때 소멸 

 

applicationContext

 

Application Context = getApplicationContext() = getApplication()

  • Application의 생명 주기 내내 진행되는, 전역적인 작업 등의 Context로 적합
    • ActivityViewModel 클래스를 상속받는 viewModel을 사용하는 경우, ViewModel의 수명 주기가 Activity의 생명 주기보다 길기 때문에 사용할 수 있다
    • Activity에서 라이브러리를 초기화해야 할 경우 사용할 수 있다
    • Activity보다 생명 주기가 길기 때문에 Application Context를 사용한 작업이 진행된 후 메모리에서 Garbage Collection이 진행되지 않는다
  • Dialog 등의 UI를 표시하는 작업은 비효율적이거나, 아예 불가능하다
    • Dialog는 Activity의 수명 주기 내에서 충분히 처리할 수 있는 작업
    • Toast는 표시 가능

 

Activity Context

  • 실행중인 Activity의 맥락을 담고 있는 Context
  • 해당 Activity와 생명 주기가 같고, Activity 내에서만 유효
    • Activity가 시작될 때 생성되고, 종료될 때 소멸 

this = baseContext 

Activity Context = this = getBaseContext()

  • this 또는 baseContext는 현재 Activity 자신을 가리킨다. 
  • Activity의 생명 주기 내에서 수행하는 작업에 제공되는 Context로 적합하다. 
    • Intent, Toast 등에서 사용하기 적합
  • Fragment에서의

 

getContext()와 requireContext()

  • 가장 큰 차이는 nullable 여부
  • requireContext : NonNull
  • getContext : Nullable
  • 반환 : Activity Context

단지 반환값의 차이로, context를 불러올 수 없는 경우 null을 반환하는지, 아니면 throw를 통해 exception을 발생시키는지에 대한 차이이다. (동일한 코드지만 exception을 일으키느냐, null을 반환하느냐)

 

Null이 아님을 보장해준다고 생각하기 쉬운 requireContext()를 쓰더라도 터지지 않는 것은 아님

예외처리 구문을 이용하든, if(context == null)을 이용하든 context는 특정 상황에서 null이 될 수 있음을 기억하고 (스레드나 코루틴을 통한 비동기적인 코드를 작성하는 측면) 적절한 처리가 필요하다. 

 

 

※ Context가 들어가는 자리에 적절하지 않은 Context를 사용한다면 메모리 누수가 발생할 수 있다.

ex) Application Context를 참조하여 싱글톤 객체를 생성해야 할 때 Activity Context를 참조하여 생성하게 된다면, Garbage Collector가 Activity Context를 수거하지 못하여 메모리 누수가 발생 

 

Activity의 생명 주기 내에서 처리할 수 있는 작업은 (Intent, Toast, Dialog 등) this, baseContext 와 같은 Activity Context를 사용하여 작업을 처리하고, ViewModel 등의 Application과 생명 주기를 공유하거나 단일 Activity의 생명 주기보다 긴 작업을 하는 경우에는 Application Context를 사용해야 함 

 

 

 

 

참고

https://velog.io/@kajpjs0508/Android-Context%EC%99%80-Context%EC%9D%98-%EA%B5%AC%EB%B6%84-baseContext-applicationContext-this

 

[Android] Context, 적시 사용법(baseContext, applicationContext, this)

안드로이드 Context의 적시 사용법

velog.io

 

728x90

ANR이란 Application Not Responding의 약자로, '애플리케이션이 응답하지 않는다'는 뜻이다. 

 

ANR 발생 요인 

  • 애플리케이션이 UI 스레드에 어떠한 I/O 명령(빈번한 네트워크 액세스)으로 인해 막힐 때
  • 너무 많은 시간을 정교한 메모리 구조를 구축하는데 들일 때
  • Input 이벤트(키를 누르거나 화면을 터치하는 등)에 5초안에 반응을 하지 않을 때
  • BroadcatReceiver 가 10초내로 실행을 끝내지 않을 때 (UI가 없는 브로드캐스트 리시버, 서비스도 실행 주체가 메인스레드이므로 긴 시간을 소모하는 작업인 경우 ANR을 발생시킨다.)

 

ANR 발생 방지 

  • ANR의 발생을 예방하려면 소요 시간이 긴 작업을 최소화해야 한다. 
  • UI업데이트를 제외한 나머지 작업은 메인 스레드에서 작업하지 않는다.
    • 연산, 네트워크 통신, DB와 관련된 작업 등은 굳이 사용자에게 시각적으로 보여주지 않고 해당 작업의 결과만 알려주면 되기 때문 
    • 작업이 수행되고 있음을 사용자가 알 수 있도록 프로그래스바 등으로 표현해 주는 것이 좋음  

특정 기능을 수행하는 버튼을 눌렀을 때 기능이 수행되고 있음에도 시각적으로 알 수가 없다면, 사용자가 기능을 반복해서 실행시킬 수 있어서 결과적으로 작업 과부하로 인해 ANR이 발생하거나, 사용자가 문제가 있다고 생각할 수 있고 앱 자체를 꺼버릴 수 있음 

 

결론

메인 UI 스레드가 오래 기다리지 않게 한다.
복잡한 작업이 있다면 백그라운드에서 진행한다.

 

 

참고

https://itmining.tistory.com/3

 

[안드로이드] ANR의 의미와 예방

이 글은 PC 버전 TISTORY에 최적화 되어있습니다. 서론 안드로이드 앱을 구현하여 돌리다보면, 또는 플레이스토어에 올라온 앱임에도 불구하고, 앱의 중지를 알리는 메시지를 심심치 않게 봤을 것

itmining.tistory.com

 

728x90

Parcelable과 Serializable은 객체를 직렬화하여 전달하기 위한 방법이다.

 

직렬화 : 객체들의 데이터를 연속적인 데이터(스트림)로 변형하여 전송 가능한 형태로 만드는 것
역직렬화 : 직렬화된 데이터를 다시 객체의 형태로 만드는 것

 

객체 데이터를 통신하기 쉬운 포맷(Byte, CSV, Json..) 형태로 만들어주는 작업을 직렬화라고 볼 수 있고,
역으로, 포멧(Byte,CSV,Json..) 형태에서 객체로 변환하는 과정을 역직렬화라고 할 수 있겠다.

 

(이해에 도움이 될 수도 있음)

Parcel 이란 한국어로 꾸러미 라는 뜻이다. 객체를 싸는 클래스가 바로 Parcel 클래스 

Parcel 이 필요한 이유

안드로이드에서 프로세스 간 통신을 위해 Bundle 을 사용하는데, Key 와 Value 쌍으로 이루어져 있는 형태이다. 

이러한 Bundle 에서 원시타입(Primitive Type) Int, String, boolean.... 같은 간단한 데이터는 그대로 Value 값으로 넣을 수 있지만, Kotlin의 data class 같은 것들은 내부에 많은 데이터가 들어 있기 때문에 Map에 Value 값으로 입력하는 것이 어렵다. 

이런 문제가 있어서 Bundle Value 값으로 입력될 수 있는 것이 Parcel 

 

 

Parcelable와 차이 

Parcelable

  • Parcelable은 안드로이드에서 제공하는 인터페이스로, 객체를 전달하기 위해 사용
  • Parcelable 인터페이스를 구현한 객체는 안드로이드 OS에서 Intent나 Bundle에 담아 전달할 수 있음
  • Parcelable을 사용하면 객체를 직렬화하여 안드로이드 OS에서 처리할 수 있는 바이트 배열로 변환하여 전달

Serializable

  • Serializable은 Java에서 제공하는 인터페이스로, 객체를 직렬화하여 전달하기 위해 사용
  • Serializable을 사용하면 객체를 바이트 스트림으로 변환하여 전달할 수 있음
  • Serializable 인터페이스를 구현한 객체는 Java에서 제공하는 ObjectOutputStream을 사용하여 전달할 수 있음

1. 속도 

  • Parcelable이 Serializable보다 빠름
  • Paecelable은 안드로이드 OS에서 직접 처리하기 때문에 직렬화와 역직렬화 시간이 적고, Serializable은 Java의 Reflection을 사용하기 때문에 상대적으로 느림
  • Serializable은 ObjectOutputStream과 ObjectInputStream을 사용하기 때문에 객체를 직렬화하는 시간이 더 길어 짐

2. 크기 

  • Parcelable은 Java의 Serializable보다 객체를 직렬화할 때 생성되는 데이터 크기가 작음
    • 객체의 멤버 변수들을 Parcel에 쓰기 때문에 필요한 데이터만 쓰게 됨 
  • Serializable은 객체의 모든 데이터를 직렬화하기 때문에 불필요한 데이터까지 모두 쓰게 되어서 상대적으로 데이터 크기가 큼

3. 안정성

  • Parcelable은 Serailizable 보다 안정성이 높음
    • Parcelable은 직렬화와 역직렬화에 대한 오류 검사를 수행하기 때문

4. 그 외

  • Parcelable은 안드로이드 OS에서만 사용할 수 있음
    • Parcelable을 사용하여 전달한 객체는 안드로이드 애플리케이션에서만 사용할 수 있음
    • 객체 크기가 작고 안드로이드 OS에서만 사용하는 경우 Parcelable을, 객체 크기가 크거나 다른 플랫폼과도 호환해야 하는 경우 Serializable을 사용하는 것이 좋음 

 

 

 

728x90

APK 

  • Android Applickation Package의 약자 
  • apk라고 하면 안드로이드 앱의 확장자이다. 
  • 안드로이드 OS에서 앱을 설치하는 용도로 apk 파일을 주로 사용 
  • APK 확장 파일을 다운로드하여 기기에 저장하면 구글 플레이 스토어에서 다운로드하지 않아도 앱을 실행할 수 있음  
  • apk 파일을 직접 다운로드 하는 경우에는 보안이 취약하다. 

구글 플레이에서 사용자가 다운로드 하는 압축된 APK는 100MB 이하여야 하는데, 고화질의 그래픽, 미디어 파일 같은 대용량 저작물을 저장할 공간이 많이 필요할 경우, 100MB를 초과하게 됨 결국 파일의 크기가 커지는데 이런 문제를 보완한 것이 AAB이다. 

 

결국 apk의 용량문제를 해결하기 위해 개발됨 

 

AAB

  • Android App Bundle의 약자 
  • 앱의 압축 크기가 100MB를 넘어도 확장파일이 필요없다. 
  • 최대 150MB까지 가능하고, APK 생성 및 구글 플레이 서명이 연기된다는 장점을 갖춤

APK와 비교했을 때 가장 좋은 점은 앱 실행에 필요없는 모든 리소스를 다운로드하는 APK와는 달리 앱 실행에 필요한 코드와 리소스만 담긴 최적화 APK를 다운로드할 수 있다는 점이다. 

 

AAB 단점 

보안문제 

 

모든 안드로이드 앱에는 개발자의 서명 파일이 들어간다. 서명 파일은 개발자가 APK 파일 내에 직접 첨부 하기 때문에 앱의 불법 배포와 같은 부분을 방지할 수 있었지만 AAB 파일은 구글 플레이에서 최적화 APK를 생성한 후 서명을 구글플레이가 대신하기 때문에 대리 서명이 될 수밖에 없다.

만약 최적화에 이상이 생긴다면 그 결과에 대한 불만은 개발자의 몫으로 돌아오게 된다는 점에서 우려가 있다.

 

시장 독점 

 

AAB 확장자를 사용하게 되면 필수로 구글 플레이 스토어만을 통해 앱 배포가 가능해진다.

  • 타 스토어를 통해 배포하려면 apk 확장자, aab 확장자 둘 다 제작해야 하는 경우가 생길 수 있음 

 

 

728x90

뷰페이저 무한 스크롤

 

기존의 자동 페이징 기능만 있던 뷰 페이저를 계속 스크롤할 수 있게 변경했다. 

구글링을 해서 찾아본 결과 지원하는 메서드는 따로 없는 것 같고, 눈 속임을 하는 듯하다. 

 

설명 예시1
설명 예시2

 

 

무한 스크롤 검색 예제

검색으로 자료를 찾아 봤을 때 예제들이 거의 이런 방식이다. 

override fun getItemCount(): Int = Int.MAX_VALUE

Int가 표현할 수 있는 Max인 억 자리 숫자를 return 해주고, position을 list의 크기로 나눈 나머지 값을 사용하면 계속 스크롤되는 것처럼 보이는 편법을 사용하는 듯하다. 

 

코드적용 

 

UpcomingShowAdapter 

더보기
import android.content.Context
import android.view.LayoutInflater
import android.view.ViewGroup
import androidx.recyclerview.widget.DiffUtil
import androidx.recyclerview.widget.ListAdapter
import androidx.recyclerview.widget.RecyclerView
import com.bumptech.glide.Glide
import com.nbc.curtaincall.databinding.ItemUpcomingShowBinding
import com.nbc.curtaincall.fetch.model.DbResponse


class UpcomingShowAdapter(private val listener: PosterClickListener? = null) :
    ListAdapter<DbResponse, UpcomingShowAdapter.UpcomingShowViewHolder>(object :
        DiffUtil.ItemCallback<DbResponse>() {
        override fun areItemsTheSame(oldItem: DbResponse, newItem: DbResponse): Boolean {
            return oldItem.mt20id == newItem.mt20id
        }

        override fun areContentsTheSame(oldItem: DbResponse, newItem: DbResponse): Boolean {
            return oldItem == newItem
        }
    }) {
    inner class UpcomingShowViewHolder(private val binding: ItemUpcomingShowBinding) :
        RecyclerView.ViewHolder(binding.root) {
        fun bind(item: DbResponse) {
            with(binding) {
                Glide.with(itemView).load(item.poster).into(ivHomeUpcomingShowPoster)
                tvPerformanceName.text = item.prfnm
                tvPeriod.text = "${item.prfpdfrom} ~ ${item.prfpdto}"
                tvFacilityName.text = item.fcltynm
                ivHomeUpcomingShowPoster.setOnClickListener {
                    item.mt20id?.let { id -> listener?.posterClicked(id) }
                }
            }
        }
    }
    //Int.MAX_VALUE 가 아닌 받아오는 list의 사이즈 의 제곱을 리턴 해줌
    override fun getItemCount(): Int = currentList.size * currentList.size
    
    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): UpcomingShowViewHolder {
        val inflater =
            parent.context.getSystemService(Context.LAYOUT_INFLATER_SERVICE) as LayoutInflater
        val binding = ItemUpcomingShowBinding.inflate(inflater, parent, false)
        return UpcomingShowViewHolder(binding)
    }

    override fun onBindViewHolder(holder: UpcomingShowViewHolder, position: Int) {
        holder.bind(currentList[position % currentList.size])
    }
}

 

HomeFragment

더보기
import android.os.Bundle
import android.view.LayoutInflater
import android.view.View
import android.view.ViewGroup
import androidx.core.view.isVisible
import androidx.fragment.app.DialogFragment
import androidx.fragment.app.Fragment
import androidx.fragment.app.activityViewModels
import androidx.fragment.app.viewModels
import androidx.lifecycle.lifecycleScope
import androidx.recyclerview.widget.LinearLayoutManager
import androidx.viewpager2.widget.ViewPager2.OnPageChangeCallback
import com.nbc.curtaincall.R
import com.nbc.curtaincall.databinding.FragmentHomeBinding
import com.nbc.curtaincall.fetch.network.retrofit.RetrofitClient.fetch
import com.nbc.curtaincall.fetch.repository.impl.FetchRepositoryImpl
import com.nbc.curtaincall.presentation.home.HorizontalMarginItemDecoration
import com.nbc.curtaincall.ui.home.adapter.GenreAdapter
import com.nbc.curtaincall.ui.home.adapter.KidShowAdapter
import com.nbc.curtaincall.ui.home.adapter.PosterClickListener
import com.nbc.curtaincall.ui.home.adapter.TopRankAdapter
import com.nbc.curtaincall.ui.home.adapter.UpcomingShowAdapter
import com.nbc.curtaincall.ui.main.MainViewModel
import com.nbc.curtaincall.ui.main.MainViewModelFactory
import com.nbc.curtaincall.ui.ticket.TicketDialogFragment
import kotlinx.coroutines.Job
import kotlinx.coroutines.delay
import kotlinx.coroutines.launch

class HomeFragment : Fragment(), PosterClickListener {
    private var _binding: FragmentHomeBinding? = null
    private val binding get() = _binding!!
    private val viewModel: HomeViewModel by viewModels {
        HomeViewModelFactory(
            fetchRemoteRepository = FetchRepositoryImpl(fetch),
        )
    }
    private val sharedViewModel: MainViewModel by activityViewModels<MainViewModel> {
        MainViewModelFactory(
            fetchRemoteRepository = FetchRepositoryImpl(
                fetch
            )
        )
    }
    private val upComingShowAdapter: UpcomingShowAdapter by lazy { UpcomingShowAdapter(this) }
    private val topRankAdapter: TopRankAdapter by lazy { TopRankAdapter(this) }
    private val genreAdapter: GenreAdapter by lazy { GenreAdapter(this) }
    private val kidShowAdapter: KidShowAdapter by lazy { KidShowAdapter(this) }
    private var isPaging = false
    private var pagingJob: Job? = null
    private val onPageChangeCallback: OnPageChangeCallback = object : OnPageChangeCallback() {
        //페이지가 선택될 때 마다 호출
        override fun onPageSelected(position: Int) {
            super.onPageSelected(position)
            //인디케이터를 표시하기 위한 코드 EX) (1/10)
            binding.tvPageIndicator.text =
                "${(position % upComingShowAdapter.currentList.size) + 1} / ${upComingShowAdapter.currentList.size}"
        }
    }

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        _binding = FragmentHomeBinding.inflate(inflater, container, false)
        initViews()
        setUpObserve()
        return binding.root
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        with(viewModel) {
            //공연 예정작
            fetchUpcoming()
            //TOP 10 공연
            fetchTopRank()
            //장르 스피너 선택
            binding.spinnerHomeGenre.setOnSpinnerItemSelectedListener<String> { _, _, newIndex, _ ->
                fetchGenre(newIndex)
            }
            //어린이 관람 가능 공연 목록
            fetchKidShow()
        }
    }

    //화면 초기 설정
    private fun initViews() {
        //어뎁터 초기화
        upComingShowAdapter
        topRankAdapter
        kidShowAdapter
        initRecyclerView()

        //viewpager 연결
        with(binding.viewPager) {
            adapter = upComingShowAdapter
            //ViewPager PageTransformer 세팅
            offscreenPageLimit = 1
            setPageTransformer(SliderTransformer(requireContext()))
            val itemDecoration = HorizontalMarginItemDecoration(
                requireContext(),
                R.dimen.viewpager_current_item_horizontal_margin
            )
            addItemDecoration(itemDecoration)

            //PageChangeCallback
            registerOnPageChangeCallback(onPageChangeCallback)

        }
        //장르 연극 초기화
        viewModel.fetchGenre(0)
    }

    //옵저브 세팅
    private fun setUpObserve() {
        with(viewModel) {
            showList.observe(viewLifecycleOwner) {
                upComingShowAdapter.submitList(it)
                //포지션을 중간위치에 맞추기 위한 코드 / 추가된 리스트의 크기가 짝수/홀수 일때 처리 (인디케이터) 
                binding.viewPager.currentItem =
                    if (upComingShowAdapter.itemCount % 2 == 0) (upComingShowAdapter.itemCount / 2)
                    else (upComingShowAdapter.itemCount / 2) - (upComingShowAdapter.currentList.size / 2)
                //페이징 초기화
                if (!isPaging) startPaging()
            }
            topRank.observe(viewLifecycleOwner) {
                topRankAdapter.submitList(it?.take(10))
            }
            genre.observe(viewLifecycleOwner) {
                genreAdapter.submitList(it)
            }
            kidShow.observe(viewLifecycleOwner) {
                kidShowAdapter.submitList(it)
            }
            //로딩 화면 처리
            isLoadingGenre.observe(viewLifecycleOwner) {
                binding.skeletonGenreLoading.isVisible = !it
            }
            isLoadingRecommend.observe(viewLifecycleOwner) {
                binding.skeletonTopRankLoading.isVisible = !it
            }
            isLoadingKid.observe(viewLifecycleOwner) {
                binding.skeletonKidLoading.isVisible = !it
            }

        }
    }

    //리사이클러뷰 초기화
    private fun initRecyclerView() {
        with(binding) {
            //HOT 추천 리사이클러뷰
            rvHomeTopRank.apply {
                adapter = topRankAdapter
                layoutManager = LinearLayoutManager(context, LinearLayoutManager.HORIZONTAL, false)
            }
            //장르별 리사이클러뷰
            rvHomeGenre.apply {
                adapter = genreAdapter
                layoutManager =
                    LinearLayoutManager(context, LinearLayoutManager.HORIZONTAL, false)
            }
            //어린이 공연 리사이클러뷰
            rvHomeKidShow.apply {
                adapter = kidShowAdapter
                layoutManager = LinearLayoutManager(context, LinearLayoutManager.HORIZONTAL, false)
            }
        }
    }

    //3초 후 자동 페이징
    private fun nextPage() {
        runCatching {
            with(binding) {
            	//스크롤이 끝까지 닿았을 경우 
                if (viewPager.currentItem == upComingShowAdapter.itemCount - 1) {
                    lifecycleScope.launch {
                        delay(3000)
                    }
                    viewPager.currentItem =
                        (upComingShowAdapter.itemCount / 2) - (upComingShowAdapter.currentList.size / 2)
                } else {
                    viewPager.currentItem++
                }
            }
        }
    }

    //페이징 스타트 함수
    private fun startPaging() {
        isPaging = true
        pagingJob = lifecycleScope.launch {
            while (true) {
                delay(3000)
                nextPage()
            }
        }
    }

    override fun onDestroyView() {
        super.onDestroyView()
        _binding = null
        isPaging = false
        pagingJob?.cancel()
    }

    //포스터 클릭 시 티켓
    override fun posterClicked(id: String) {
        val ticketDialog = TicketDialogFragment()
        sharedViewModel.sharedShowId(id) //해당 공연의 id를 MainViewModel로 보내줌
        ticketDialog.setStyle(
            DialogFragment.STYLE_NORMAL,
            R.style.RoundCornerBottomSheetDialogTheme
        )
        ticketDialog.show(childFragmentManager, ticketDialog.tag)
    }
}

 

메모리 누수가 생겨서 

 

 

참고 

https://medium.com/@ashishpandey.professional/android-infinite-scrolling-viewpager2-195e3786ec3f

 

Android Infinite scrolling ViewPager2

Achieve the smooth bi-directional infinite scrolling ViewPager 2

medium.com

 

728x90

Service 

안드로이드 4대 컴포넌트 중 하나이며, 사용자와 상호작용하지 않고 백그라운드에서 오래 실행되는 작업을 수행할 수 있는 애플리케이션 구성 요소이다.

 

  • 사용자 인터페이스를 제공하지 않는다. 
  • Service가 시작되면 사용자가 다른 애플리케이션으로 전환한 후에도 한동안 서비스가 계속 실행될 수 있다.
  • 구성요소는 Service에 바인딩되어 서비스와 상호작용하고 프로세스 간 통신 (IPC)을 실행할 수도 있다.
    •  Service는 백그라운드에서 네트워크 트랜잭션을 처리하고, 음악을 재생하거나, 파일 I/O를 실행하거나, 콘텐츠 제공업체와 상호작용할 수 있습니다.
  • 포그라운드 서비스
    • 사용자가 입력한 명령이 실행되어 결과가 출력될 때까지 기다려야 하는 방식으로 처리되는 서비스
    • 유저가 현재 뭘 하고 있다는 걸 인지하고 있는 서비스
    • 메모리 부족 시 안드로이드 시스템에 의한 강제종료 대상에서 제외됨
    • 포그라운드 서비스가 실행되는 도중엔 무조건 상태바에 알림이 제공돼야 함
    • 앱과 사용자가 상호작용하지 않아도 계속 실행됨
    • 포그라운드 프로세스 : 화면에서 앱이 어떤 작업을 하는지 눈으로 볼 수 있는 프로세스(유튜브 시청, 웹 서핑)
  • 백그라운드 서비스
    • 사용자에게 안 보이는 작업을 수행
    • 인스타에서 게시물 공유 버튼을 눌러 인스타에 사진을 업로드하는 동안 카톡하거나 인스타를 꺼도 게시물 업로드는 종료되지 않는다. 이 때 백그라운드 서비스가 사용됨
  • 바인드 서비스
    • 클라이언트-서버 구조처럼 컴포넌트가 서비스에 연결되면 서비스가 서버 역할을 함
    • 컴포넌트가 서비스에게 요청하면 서비스는 그것에 맞는 결과값을 리턴 함 
    • 클라이언트가 연결을 해제하고 서비스와 연결된 클라이언트가 없을 때 바인드 서비스가 종료

Service의 생명 주기

  • onCreate() : 서비스가 처음 생성되었을 경우 onStartCommand() 혹은 onBind()가 호출되기전에 호출된다. 서비스가 이미 실행중일 경우 이 메소드는 호출 x
  • onStartCommand() : 시스템에서 액티비티와 같이 다른 컴포넌트에서 startService()를 호출하게 되면 이 메소드가 실행되고 서비스가 시작된다. 이 메소드를 구현한 후 서비스를 중단하기 위해 stopSelf()나 stopService() 메소드를 호출해야 한다. 바인딩만 할 경우 해당 메소드 구현할 필요 없음

 

onStartCommand()의 return 값

 

START_NOT_STICKY: 시스템이 서비스를 onStartCommand()를 반환 후에 중단시키면 서비스를 재생성 하면 안됨. 서비스가 불필요하게 여러개 생성되는 것을 막을수 있는 방법

START_STICKY: 시스템이 onStartCommand() 반환 후에 서비스를 중단하면 서비스를 자동으로 다시 생성하고 마지막 인텐트는 전달하지 않음.

START_REDELIVER_INTENT: 시스템이 onStartCommand()를 반환 후에 서비스를 중단하는 경우, 서비스를 다시 생성하고 이 서비스에 전달된 마지막 인텐트로 onStartCommand()를 호출하면 모든 보류 인텐트가 차례로 전달

(즉시 재개되어야 하는 작업을 수행할 때(예: 파일 다운로드)에 적합

  • onBind(): 안드로이드의 구성요소가 서비스에 바인딩하고자 하는 경우, 이 메소드가 호출

시스템에서 액티비티와 같이 다른 컴포넌트에서 bindService()를 호출하게 되면 이 메소드가 실행되고 서비스에 바인딩 된다.

이 메소드의 구현체에서는 IBinder를 리턴하여 클라이언트와 서비스가 통신할 수 있는 인터페이스를 제공해야 한다.

항상 이 메소드를 구현해야 하며, 바인딩을 원하지 않으면 null을 반환하는 식으로라도 구현해야 한다.

 

Manifest에 서비스를 activity와 유사하게 등록을 해주어야 한다.

 

 

참고자료 

https://developer.android.com/guide/components/services?hl=ko 

 

서비스 개요  |  Background work  |  Android Developers

이 페이지는 Cloud Translation API를 통해 번역되었습니다. 서비스 개요 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. Service는 백그라운드에서 장기 실행 작업

developer.android.com

https://onlyfor-me-blog.tistory.com/380

 

[Android] 서비스란?

서비스는 안드로이드 4대 컴포넌트 중 하나로, 백그라운드에서 어떤 작업을 수행해야 할 때 사용을 고려할 수 있는 컴포넌트다. 그러나 백그라운드에서 수행되는 작업이라고 다 서비스를 사용

onlyfor-me-blog.tistory.com

 

728x90

함수형 프로그래밍은 프로그래밍 패러다임중 하나로, 순수 함수와 불변성을 강조하며, 프로그램의 상태 변경을 최소화하는 것을 목표로 합니다. 함수형 프로그래밍은 수학적 함수의 개념에 기반을 두고 있으며, 이를 통해 코드의 간결성, 모듈성 및 예측 가능성을 높일 수 있습니다.

 

프로그래밍 패러다임

  • 명령형 프로그래밍: 무엇(What)을 할 것인지 나타내기보다 어떻게(How) 할 건지를 설명하는 방식
    • 절차지향 프로그래밍: 수행되어야 할 순차적인 처리 과정을 포함하는 방식 (C, C++)
    • 객체지향 프로그래밍: 객체들의 집합으로 프로그램의 상호작용을 표현 (C++, Java, C#)
  • 선언형 프로그래밍: 어떻게 할건지(How)를 나타내기보다 무엇(What)을 할 건지를 설명하는 방식
    • 함수형 프로그래밍: 순수 함수를 조합하고 소프트웨어를 만드는 방식 (클로저, 하스켈, 리스프)

 

함수형 프로그래밍을 배워야 하는 이유

 

잠시 당신이 나무꾼이라고 가정해보자. 당신은 숲에서 가장 좋은 도끼를 가지고 있고, 그래서 가장 일 잘하는 나무꾼이다. 그런데 어느 날 누가 나타나서 나무를 자르는 새로운 패러다임인 전기톱을 알리고 다닌다. 이 사람이 무척 설득력이 있어서 당신은 사용하는 방법도 모르면서 전기톱을 사게 된다. 당신은 여태껏 했던 방식대로 시동을 걸지도 않고 전기톱으로 나무를 마구 두들겨댄다. 곧 당신은 이 새로운 전기톱은 일시적인 유행일 뿐이라고 단정하고 다시 도끼를 쓰기 시작한다. 그때 누군가 나타나서 전기톱의 시동 거는 법을 가르쳐 준다.
— 닐포드 , “함수형 사고”

 

함수형 프로그래밍은 프로그래밍 언어나 방식을 배우는것이 아니라 함수로 프로그래밍하는 사고를 배우는 것이다.

새로운 계산방법을 배우는 것 처럼 사고의 전환을 필요로 하며 다양한 사고방식으로 프로그래밍을 바라보면 유연한 문제해결이 가능하다.

명령형이나 객체지향 코드보다 간결하고 예측하기 쉬우며, 테스트하기가 더 쉬워진다.

 

유명한 책인 클린 코드(Clean Code)의 저자 Robert C.Martin은 함수형 프로그래밍을 대입문이 없는 프로그래밍이라고 정의하였다.

 

함수형 프로그래밍(Functional Programming)의 특징

함수형 프로그래밍(Functional Programming)은 계산을 수학적 함수의 평가로 취급하고 상태와 가변 데이터를 멀리하는 프로그래밍 패러다임입니다. 부수 효과(Side Effect)를 제거할 경우 프로그램의 동작을 이해하고 예측하기 쉬워지기 때문에 부수 효과가 없는 순수 함수(Pure Function)들로만 작성됩니다.

 

- 부수 효과(Side Effect)란?

  • 콘솔에 출력하거나 사용자의 입력을 읽는 것
  • 변수를 수정하거나, 객체의 필드를 저장하는 것
  • 예외를 던지거나 오류를 발생시키며 실행을 중단하는 것
  • 파일에 읽고 쓰는 작업

 

순수 함수(Pure Function)

그리고 이러한 부수 효과(Side Effect)들을 제거한 함수들을 순수 함수(Pure Function)이라고 부르며, 함수형 프로그래밍에서 사용하는 함수는 이러한 순수 함수들이다.

  • Memory or I/O의 관점에서 Side Effect가 없는 함수
  • 함수의 실행이 외부에 영향을 끼치지 않는 함수

 

순수 함수(Pure Function)의 장점

순수 함수(Pure Function)을 이용하면 얻을 수 있는 효과는 다음과 같다.

  • 함수 자체가 독립적이며 Side-Effect가 없기 때문에 Thread에 안전성을 보장받을 수 있다.
  • Thread에 안정성을 보장받아 병렬 처리를 동기화 없이 진행할 수 있다.

 

1급 객체(First-Class Object)

그리고 1급 객체란 다음과 같은 것들이 가능한 객체를 의미한다.

  • 변수나 데이터 구조 안에 담을 수 있다.
  • 파라미터로 전달 할 수 있다.
  • 반환값으로 사용할 수 있다.
  • 할당에 사용된 이름과 무관하게 고유한 구별이 가능하다.

함수형 프로그래밍에서 함수는 1급 객체로 취급받기 때문에 위의 예제에서 본 것 처럼 함수를 파라미터로 넘기는 등의 작업이 가능한 것이다. 또한 우리가 일반적으로 알고 개발했던 함수들은 함수형 프로그래밍에서 정의하는 순수 함수들과는 다르다는 것을 인지해야 한다.

 

불변성(Immutable)

  • 함수 외부에서 데이터를 수정하지 않음
  • 함수의 계산을 수행하는 동안 변수에 할당된 값들이 절대로 변하지 않음

 

참조 투명성(Referential Transparency)

  • 동일한 인자에 대해 항상 동일한 결과를 반환해야 한다.
  • 참조 투명성을 통해 기존의 값은 변경되지 않고 유지된다.(Immutable Data)

 

고차 함수(High order function)

  • 함수를 다루는 함수
  • 함수의 인자로 함수 전달 가능
  • 함수의 리턴 값으로 함수 사용 가능

익명 함수(Anonymous function)

  • 이름이 없는 함수
  • 람다식으로 표현되는 함수 구현

게으른 평가(Lazy evaluation)

  • 코드 실행 즉시 값을 평가하는 것이 아닌 필요한 시점에 평가

 

명령형 프로그래밍과 함수형 프로그래밍에서 사용하는 함수는 부수효과의 유/무에 따라 차이가 있다. 그에 따라 함수가 참조에 투명한지 안한지 나뉘어 지는데, 참조에 투명하다는 것은 말 그대로 함수를 실행하여도 어떠한 상태의 변화 없이 항상 동일한 결과를 반환하여 항상 동일하게(투명하게) 실행 결과를 참조(예측)할 수 있다는 것을 의미한다.

 

즉, 어떤 함수 f에 어떠한 인자 x를 넣고 f를 실행하게 되면, f는 입력된 인자에만 의존하므로 항상 f(x)라는 동일한 결과를 얻는다는 것을 의미한다. 부작용을 제거하여 프로그램의 동작을 이해하고 예측을 용이하게 하는 것은 함수형 프로그래밍으로 개발하려는 핵심 동기 중 하나이다. 그리고 이러한 부분인 병렬 처리 환경에서 개발할 때 Race Condition에 대한 비용을 줄여준다. 왜냐하면 함수형 프로그래밍에서는 값의 대입이 없이 항상 동일한 실행에 대해 동일한 결과를 반환하기 때문이다.

 

함수형 프로그래밍의 장단점


장점

  1. 깔끔하고 유지보수가 용이함
  2. 함수 단위의 코드 재사용이 수월하다 
    • (코드 재사용성이 높음)
  3. 불변성을 지향하기 때문에 프로그램의 동작을 예측하기 쉬워진다 
    • 함수는 입력과 그에 대한 출력만을 책임지기 때문에 테스트가 쉽고 가독성이 좋
    • 사용하는 모든 데이터가 변경 불가능(immutable)하고 함수는 부수 효과를 가지고 있지 않기 때문에 동시성과 관련된 문제를 원천적으로 차단
  4. 고차 함수로 인해 함수들 간의 결합, 조합이 간결해지며, 익명 함수를 사용할 수 있음


단점

  1. 학습 곡선: 함수형 프로그래밍은 명령형 프로그래밍과 상당히 다른 개념과 접근 방식을 사용
    • 새로운 개념들, 예를 들어 순수 함수, 불변성, 고차 함수 등을 학습하는 데 시간이 걸릴 수 있음
  2. 추사상화 수준: 함수형 프로그래밍은 높은 수준의 추상화를 제공함 이로 인해 코드가 간결하고 모듈화되긴 하지만, 때로는 이해하기 어렵고 복잡해질 수도 있음  
    • 함수형 프로그래밍에 익숙하지 않은 개발자들에게는 코드 해석이 어려울 수 있음
  3. 성능: 함수형 프로그래밍에서는 불변성과 순수 함수를 사용하여 상태 변경을 최소화합니다. 그러나 이로 인해 메모리 사용량이 증가하거나, 가비지 컬렉션 비용이 높아질 수 있습니다. 또한, 재귀를 사용한 경우 스택 오버플로우가 발생할 수도 있음
    • 함수형 프로그래밍에서는 반복이 for문이 아닌 재귀를 통해 이루어지는데 (deep copy), 재귀적 코드 스타일은 무한 루프에 빠질 수 있다
  4. 최적화 제한: 몇몇 최적화 기법들이 함수형 프로그래밍에서는 적용하기 어려울 수 있음
    • 예를 들어, 상태 변경이 없다는 가정으로 최적화를 수행하는 것은 일부 경우에 제한적일 수 있음
  5. 표현력: 일부 애플리케이션에서는 명령형 프로그래밍이 더 직관적이고 표현력이 높을 수 있음
    • 특히 상태 변경이 빈번하게 발생하는 경우, 함수형 프로그래밍으로 표현하기 어려운 경우가 있을 수 있음
  6. 순수함수를 사용하는 것은 쉬울 수 있지만 조합하는 것은 쉽지 않다
    •  
    • 순수함수를 구현하기 위해서는 코드의 가독성이 좋지 않을 수 있다

 

 

참고자료 

https://jongminfire.dev/%ED%95%A8%EC%88%98%ED%98%95-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D%EC%9D%B4%EB%9E%80

 

함수형 프로그래밍이란?

jongminfire.dev

https://mangkyu.tistory.com/111

 

[프로그래밍] 함수형 프로그래밍(Functional Programming) 이란?

1. 함수형 프로그래밍(Functional Programming)에 대한 이해 [ 프로그래밍 패러다임(Programming Paradigm) ] 프로그래밍 패러다임(Programming Paradigm)은 프로그래머에게 프로그래밍의 관점을 갖게 하고 코드를

mangkyu.tistory.com

https://thecho7.tistory.com/entry/%EB%A9%B4%EC%A0%91-%EA%BF%80%ED%8C%81-%ED%95%A8%EC%88%98%ED%98%95-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8DFunctional-Programming%EC%9D%B4%EB%9E%80

 

[면접 꿀팁] 함수형 프로그래밍(Functional Programming)이란?

함수형 프로그래밍(Functional Programming)은 백엔드/프론트엔드를 막론하고 자주 질문 받으며 실제로 현업에서도 자주 다루는 개념입니다. 함수형 프로그래밍에 대해 설명해보도록 하겠습니다. 함

thecho7.tistory.com

 

+ Recent posts