ELLO의 개발일지

깃으로 협업하기 - 실습편

Minny27 — Fri, 9 Jun 2023 12:00:07 +0900

준비물: Xcode, Terminal

Git Clone은 생략하겠습니다.

※ 우리팀 룰:

develop 브랜치에 작업을 최신화한다(쌓는다)
배포(스토어에 버전 업데이트)할 때 main에 쌓아서 배포한다.

(편의상 develop을 dev라고 하겠습니다.)

항상 현재 브랜치를 dev로 최신화(pull, merge)를 하고 작업을 시작합니다.(다른 개발자의 작업이 dev에 merge됐을 수 있음)

터미널에서 작업 할 때, 항상 .git 파일이 포함되어 있는 경로로 이동해서 깃 명령어를 수행합니다.

전체 과정은 다음과 같습니다.

# develop으로 head 옮기기
git checkout develop

# devlop에서 will이라는 브랜치 생성
git checkout -b will

# 완료된 작업 임시저장
git stash

# develop으로 head 옮기기
git checkout develop

# develop 최신화
git pull

# will로 head 옮기기
git checkout will

# will을 develop으로 최신화하기(merge)
git merge develop

# 임시저장한 작업 불러오기
git stash apply stash@\{0\}

# 충돌 수정 후, add commit push

(각각의 명령어는 추후에 순서대로 설명하겠습니다.)

1. 브랜치 생성하기

항상 브랜치를 생성할 때는 현재 head가 어느 브랜치에 위치하고 있는지 확인합니다.

# 깃 생성
git branch will

# 깃 체크아웃
git checkout will

# 깃 생성 후 체크아웃
git checkout -b will

dev에서 will이라는 브랜치를 생성 후 체크아웃

이러면 dev의 코드기반으로 분기가 나눠집니다.

현재 dev 브랜치의 코드가 다음과 같다고 가정하겠습니다.

class ViewController: UIViewController {

    let textLabel: UILabel = {
        let label = UILabel()
        label.text = "Hello World!"
        label.translatesAutoresizingMaskIntoConstraints = false
        return label
    }()

    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .white

        setupUI()
    }

    private func setupUI() {
        view.addSubview(textLabel)

        NSLayoutConstraint.activate([
            textLabel.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            textLabel.centerYAnchor.constraint(equalTo: view.centerYAnchor)
        ])
    }
}

그런데 다른 개발자가 textLabel에 텍스트를 “plus person gogo”로 변경하고 텍스트 색깔을 blue로 변경했고, 이를 develop에 머지했다고 가정하겠습니다.

그리고 나(will)은 textLabel의 텍스트를 “Will Nice!”로 수정했다고 가정하겠습니다.

현재 dev 브랜치

class ViewController: UIViewController {

    let textLabel: UILabel = {
        let label = UILabel()
        **label.text = "plus person gogo"**
        **label.textColor = .blue**
        label.translatesAutoresizingMaskIntoConstraints = false
        return label
    }()

        { ... }
}

현재 will 브랜치

class ViewController: UIViewController {

    let textLabel: UILabel = {
        let label = UILabel()
        **label.text = "Will Nice!"**
        label.translatesAutoresizingMaskIntoConstraints = false
        return label
    }()

        { ... }
}

2. 모든 작업이 완료되면, 자신의 작업을 임시저장(stash)합니다.

git stash

git stash list 를 입력하면 다음과 같은 리스트가 생깁니다.

3. `dev` 브랜치 최신화

git checkout develop
git pull

하지만 다음과 같이 git pull을 수행했을 때, 에러가 발생할 수 있음

기본적으로 우리가 merge하는 방식으로 merge를 하고 싶을 때는

git config pull.rebase false 로 pull받으면 됩니다.

4. `will` 브랜치를 `dev` 브랜치로 최신화(merge)

git checkout will
git merge develop

만약 stash하는 것을 까먹었다면 충돌 수정 후, add commit push

5. 임시 저장한 작업 불러오기

git stash apply stash@\{0\}

git stash list 로 먼저 검색 후, 해당 인덱스를 넣어 주면 됨.

6. 충돌 수정

임시 저장한 작업을 불러오면, 프로젝트에서 다음과 같은 에러가 발생함

여기서 Updated upstream으로 감싸져 있는 코드는 최신화된 dev의 코드이고

Stashed changes로 감싸져 있는 코드는 임시 저장한 작업(will)을 불러온 코드입니다.

이 때, 자신이 수정한 코드로 바로 수정을 할 수도 있지만, 만약 정해진 게 없다면 팀원들과 상의 후, 수정 사항을 add commit push하면 됩니다.

제가(will) 수정한 파일을 적용해서 push하겠습니다.

7. 수정 사항 반영

만약 push를 했는데 다음과 같은 에러가 발생할 수 있습니다.

이 경우는 원격 저장소에 해당 브랜치가 없다는 의미이므로 위의 내용에서 사용하라는 명령어를 그대로 입력합니다.

git push --set-upstream origin develop

수정 작업을 push 하고 Github에 가보면 다음과 같이 나타납니다.

여기서 Compare & pull request를 클릭하면 PR을 남길 수 있습니다.

기록 및 정리에 대한 생각's

Minny27 — Mon, 27 Mar 2023 09:49:59 +0900

음.. 모르거나 궁금한 것들을 노션에 개인적으로 정리했었는데 이제는 블로그에 그때 그때 정리해보는 트라이를 해보려고 합니다..

그 이유는 블로그 관리해야지.. 해야지.. 하다가 방치되서...

더 쉬운 말, 더 잘 정리되어 있는 페이지이면 당연히 좋겠지만 '누군가의 시선을 생각하기보다 나의 생각 및 고민을 좀 더 직관적으로 표현하는 것이 중요한 건 아닐까?' 라는 생각이 들었습니다.

그래서 알게 되거나 안 되는 것에 대해서 그냥 적어보려고 합니다.

끝이 어디가 될지 모르겠지만 또 가봐야겠습니다. 화이팅!!

[iOS / RxSwift] Subject

Minny27 — Tue, 13 Sep 2022 00:23:40 +0900

Subject

A Subject is a sort of bridge or proxy that is available in some implementations of ReactiveX that acts both as an observer and as an Observable. Because it is an observer, it can subscribe to one or more Observables, and because it is an Observable, it can pass through the items it observes by reemitting them, and it can also emit new items.

Subject는 observer와 Observable 모두로 작동하는 일부 ReactiveX 구현에서 사용할 수 있는 일종의 브리지 또는 프록시입니다. 옵저버이기 때문에 하나 이상의 옵저버블을 구독할 수 있고 옵저버블이기 때문에 관찰한 항목을 다시 방출하여 통과할 수 있으며 새 아이템을 방출할 수도 있습니다.

Because a Subject subscribes to an Observable, it will trigger that Observable to begin emitting items (if that Observable is “cold” — that is, if it waits for a subscription before it begins to emit items). This can have the effect of making the resulting Subject a “hot” Observable variant of the original “cold” Observable.

Subject가 Observable을 구독하기 때문에 Observable이 항목 방출을 시작하도록 트리거합니다(그 Observable이 "cold"인 경우, 즉 항목을 방출하기 시작하기 전에 구독을 기다리는 경우). 이것은 결과 Subject를 원래 "cold" Observable의 "hot" Observable 변형으로 만드는 효과를 가질 수 있습니다.

Varieties of Subject(Subject의 종류)

There are four varieties of Subject that are designed for particular use cases. Not all of these are available in all implementations, and some implementations use other naming conventions (for example, in RxScala, what is called a “PublishSubject” here is known simply as a “Subject”):

특정 사용 사례를 위해 설계된 4가지 종류의 Subject가 있습니다. 이 모든 것이 모든 구현에서 사용할 수 있는 것은 아니며 일부 구현에서는 다른 명명 규칙을 사용합니다(예: RxScala에서는 여기에서 "PublishSubject"라고 하는 것을 단순히 "Subject"라고 함).

AsyncSubject

An AsyncSubject emits the last value (and only the last value) emitted by the source Observable, and only after that source Observable completes. (If the source Observable does not emit any values, the AsyncSubject also completes without emitting any values.)

AsyncSubject는 source Observable이 내보낸 마지막 값(그리고 마지막 값만)을 내보냅니다. (소스 Observable이 값을 내보내지 않으면 AsyncSubject도 값을 내보내지 않고 완료됩니다.)

It will also emit this same final value to any subsequent observers. However, if the source Observable terminates with an error, the AsyncSubject will not emit any items, but will simply pass along the error notification from the source Observable.

또한 후속 관찰자에게 동일한 최종 값을 내보냅니다. 그러나 소스 Observable이 오류로 종료되면 AsyncSubject는 항목을 내보내지 않고 단순히 소스 Observable의 오류 알림을 전달합니다.

BehaviorSubject

When an observer subscribes to a BehaviorSubject, it begins by emitting the item most recently emitted by the source Observable (or a seed/default value if none has yet been emitted) and then continues to emit any other items emitted later by the source Observable(s).

observer가 BehaviorSubject를 구독할 때, 소스 Observable에서 가장 최근에 내보낸 항목(또는 아직 내보내지 않은 경우 시드/기본값)을 내보내는 것으로 시작한 다음 소스 Observable에서 나중에 내보낸 다른 항목을 계속 내보냅니다.

However, if the source Observable terminates with an error, the BehaviorSubject will not emit any items to subsequent observers, but will simply pass along the error notification from the source Observable.

그러나 소스 Observable이 오류로 종료되면 BehaviorSubject는 후속 관찰자에게 항목을 내보내지 않고 단순히 소스 Observable의 오류 알림을 전달합니다.

PublishSubject

PublishSubject emits to an observer only those items that are emitted by the source Observable(s) subsequent to the time of the subscription.

PublishSubject는 구독 시간 이후에 소스 Observable(들)에 의해 방출된 항목만 관찰자에게 방출합니다.

Note that a PublishSubject may begin emitting items immediately upon creation (unless you have taken steps to prevent this), and so there is a risk that one or more items may be lost between the time the Subject is created and the observer subscribes to it. If you need to guarantee delivery of all items from the source Observable, you’ll need either to form that Observable with Create so that you can manually reintroduce “cold” Observable behavior (checking to see that all observers have subscribed before beginning to emit items), or switch to using a ReplaySubject instead.

PublishSubject는 생성 즉시 항목을 방출하기 시작할 수 있으며(이를 방지하기 위한 조치를 취하지 않는 한) Subject가 생성되고 관찰자가 구독하는 시간 사이에 하나 이상의 항목이 손실될 위험이 있습니다. 소스 Observable에서 모든 항목의 전달을 보장해야 하는 경우 "콜드" Observable 동작을 수동으로 다시 도입할 수 있도록 Create을 사용하여 해당 Observable을 구성해야 합니다(항목 방출을 시작하기 전에 모든 관찰자가 구독했는지 확인) 또는 대신 ReplaySubject를 사용하도록 전환합니다.

If the source Observable terminates with an error, the PublishSubject will not emit any items to subsequent observers, but will simply pass along the error notification from the source Observable.

소스 Observable이 오류로 종료되면 PublishSubject는 후속 관찰자에게 항목을 내보내지 않고 단순히 소스 Observable의 오류 알림을 전달합니다.

ReplaySubject

ReplaySubject emits to any observer all of the items that were emitted by the source Observable(s), regardless of when the observer subscribes.

ReplaySubject는 관찰자가 구독하는 시기에 관계없이 소스 Observable에서 방출한 모든 항목을 관찰자에게 방출합니다.

There are also versions of ReplaySubject that will throw away old items once the replay buffer threatens to grow beyond a certain size, or when a specified timespan has passed since the items were originally emitted.

재생 버퍼가 특정 크기 이상으로 커질 위험이 있거나 항목이 원래 방출된 이후 지정된 시간이 경과하면 오래된 항목을 버리는 ReplaySubject 버전도 있습니다.

If you use a ReplaySubject as an observer, take care not to call its onNext method (or its other on methods) from multiple threads, as this could lead to coincident (non-sequential) calls, which violates the Observable contract and creates an ambiguity in the resulting Subject as to which item or notification should be replayed first.

ReplaySubject를 관찰자로 사용하는 경우 여러 스레드에서 onNext 메서드(또는 다른 메서드)를 호출하지 않도록 주의하십시오. 이 경우 동시 호출(순차적이지 않음)이 발생할 수 있으며, 이는 Observable 계약을 위반하고 결과 Subject에 어떤 아이템 또는 알림을 먼저 재생해야 하는지에 대한 모호성을 발생시킬 수 있습니다.

※ 참고 출처

ReactiveX 공식 문서

ReactiveX - Subject

If you have a Subject and you want to pass it along to some other agent without exposing its Subscriber interface, you can mask it by calling its asObservable method, which will return the Subject as a pure Observable. See Also

reactivex.io

[iOS / RxSwift] Single

Minny27 — Mon, 12 Sep 2022 01:44:38 +0900

Single

RxJava (and its derivatives like RxGroovy & RxScala) has developed an Observable variant called “Single.”

RxJava(및 RxGroovy 및 RxScala와 같은 파생 제품)는 "Single"이라는 Observable 변형을 개발했습니다.

A Single is something like an Observable, but instead of emitting a series of values — anywhere from none at all to an infinite number — it always either emits one value or an error notification.

Single은 Observable과 비슷하지만 일련의 값을 내보내는 대신(전혀 없는 것부터 무한한 수까지) 항상 하나의 값이나 오류 알림을 내보냅니다.

For this reason, instead of subscribing to a Single with the three methods you use to respond to notifications from an Observable (onNext, onError, and onCompleted), you only use two methods to subscribe:

이러한 이유로 Observable의 알림에 응답하는 데 사용하는 세 가지 방법(onNext, onError 및 onCompleted)으로 Single을 구독하는 대신 구독에 두 가지 방법만 사용합니다.

onSuccess

a Single passes this method the sole item that the Single emits

성공

Single은 이 메서드를 Single이 방출하는 유일한 항목으로 전달합니다.

onError

a Single passes this method the Throwable that caused the Single to be unable to emit an item

오류 발생

Single이 이 메서드를 전달하여 Single이 항목을 방출할 수 없게 만든 Throwable이 됩니다.

A Single will call only one of these methods, and will only call it once. Upon calling either method, the Single terminates and the subscription to it ends.

Single은 이러한 메서드 중 하나만 호출하고 한 번만 호출합니다. 두 메서드 중 하나를 호출하면 Single이 종료되고 이에 대한 구독이 종료됩니다.

Composition via Single Operators

Like Observables, Singles can be manipulated by means of a variety of operators. Some operators also allow for an interface between the Observable world and the Single world so that you can mix the two varieties:

Observable과 마찬가지로 Singles는 다양한 연산자를 통해 조작할 수 있습니다. 일부 연산자는 Observable 세계와 단일 세계 사이의 인터페이스를 허용하여 두 종류를 혼합할 수도 있습니다.

operator	returns	description
compose	Single	사용자 지정 연산자를 만들 수 있습니다.
concat and concatWith	Observable	여러 Singles에 의해 방출된 항목을 Observable 방출로 연결
create	Single	구독자 메서드를 명시적으로 호출하여 처음부터 Single 만듦
delay	Single	단일 항목의 방출을 미룸
doOnError	Single	onError를 호출할 때 지정한 메서드도 호출하는 Single을 반환
doOnSuccess	Single	onSuccess를 호출할 때 지정한 메서드도 호출하는 Single을 반환
error	Single	구독자에게 즉시 오류를 알리는 Single을 반환
flatMap	Single	Single이 내보낸 항목에 적용된 함수의 결과인 Single을 반환
flatMapObservable	Observable	Single에서 내보낸 항목에 적용된 함수의 결과인 Observable을 반환
from	Single	Future를 Single로 변환
just	Single	지정된 항목을 내보내는 Single을 반환
map	Single	소스 Single에서 내보낸 항목에 적용된 함수의 결과를 내보내는 Single을 반환
merge	Single	두 번째 Single을 방출하는 Single을 두 번째 Single에서 방출하는 항목을 방출하는 Single로 변환
merge and mergeWith	Observable	여러 싱글에 의해 방출된 항목을 관찰 가능한 방출로 병합
observeOn	Single	Single이 특정 스케줄러에서 구독자 메서드를 호출하도록 지시
onErrorReturn	Single	오류 알림을 보내는 Single을 지정된 항목을 내보내는 Single로 변환
subscribeOn	Single	Single이 특정 스케줄러에서 작동하도록 지시
timeout	Single	소스 Single이 지정된 시간 동안 값을 내보내지 않으면 오류를 알리는 Single을 반환
toSingle	Single	단일 항목을 방출하는 Observable을 해당 항목을 방출하는 Single로 변환
toObservable	Observable	Single을 Observable로 변환하여 Single에 의해 방출된 항목을 방출한 다음 완료
zip and zipWith	Single	두 개 이상의 다른 Single에서 방출된 항목에 적용된 함수의 결과인 항목을 방출하는 Single을 반환

※ 참고 출처

ReactiveX 공식 문서

ReactiveX - Single

reactivex.io

[iOS / RxSwift] Operators

Minny27 — Fri, 2 Sep 2022 23:24:15 +0900

Introduction

Each language-specific implementation of ReactiveX implements a set of operators. Although there is much overlap between implementations, there are also some operators that are only implemented in certain implementations. Also, each implementation tends to name its operators to resemble those of similar methods that are already familiar from other contexts in that language.

ReactiveX의 각 언어별 구현은 일련의 연산자를 구현합니다. 구현 간에 겹치는 부분이 많지만 특정 구현에서만 구현되는 일부 연산자도 있습니다. 또한 각 구현은 해당 언어의 다른 컨텍스트에서 이미 친숙한 유사한 메서드의 연산자와 유사하도록 연산자 이름을 지정하는 경향이 있습니다.

Chaining Operators

Most operators operate on an Observable and return an Observable. This allows you to apply these operators one after the other, in a chain. Each operator in the chain modifies the Observable that results from the operation of the previous operator.

대부분의 연산자는 Observable에서 작동하고 Observable을 반환합니다. 이렇게 하면 이러한 연산자를 체인에서 차례로 적용할 수 있습니다. 체인의 각 연산자는 이전 연산자의 작업 결과인 Observable을 수정합니다.

There are other patterns, like the Builder Pattern, in which a variety of methods of a particular class operate on an item of that same class by modifying that object through the operation of the method. These patterns also allow you to chain the methods in a similar way. But while in the Builder Pattern, the order in which the methods appear in the chain does not usually matter, with the Observable operators order matters.

특정 클래스의 다양한 메서드가 메서드의 작업을 통해 해당 개체를 수정하여 동일한 클래스의 항목에 대해 작동하는 Builder Pattern과 같은 다른 패턴이 있습니다. 이러한 패턴을 사용하면 유사한 방식으로 메서드를 연결할 수도 있습니다. 그러나 빌더 패턴에서 메서드가 체인에 나타나는 순서는 일반적으로 중요하지 않으며 Observable 연산자의 순서가 중요합니다.

A chain of Observable operators do not operate independently on the original Observable that originates the chain, but they operate in turn, each one operating on the Observable generated by the operator immediately previous in the chain.

Observable 연산자 체인은 체인을 생성한 원래 Observable에서 독립적으로 작동하지 않지만 차례로 작동하며 각각은 체인의 바로 이전에 연산자가 생성한 Observable에서 작동합니다.

Operators By Category

Creating Observables(Observable 생성)

새로운 Observable을 만드는 연산자들

Create — 직접적인 코드 구현을 통해 옵저버 메서드를 호출하여 Observable을 생성
Defer — 옵저버가 구독하기 전까지는 Observable 생성을 지연하고 구독이 시작되면 옵저버 별로 새로운 Observable을 생성
Empty/Never/Throw — 아주 정확하고 제한된 행동을 하는 Observable을 생성
From — 다른 객체나 자료 구조를 Observable로 변환
Interval — 특정 시간별로 연속된 정수형을 배출하는 Observable을 생성
Just — 객체 하나 또는 객체집합을 Observable로 변환. 변환된 Observable은 원본 객체들을 발행
Range — 연속된 범위(Range)의 정수를 발행하는 Observable을 생성
Repeat — 특정 항목이나 연속된 항목들을 반복적으로 배출하는 Observable을 생성
Start — 함수의 실행 결과를 배출하는 Observable을 생성
Timer — 지정된 시간이 지나고 난 후 항목을 하나 배출하는 Observable을 생성

Transforming Observables(Observable 변환)

Observable이 배출한 항목들을 변환하는 연산자들

Buffer — Observable로부터 정기적으로 항목들을 수집하고 묶음으로 만든 후에 묶음 안에 있는 항목들을 한번에 하나씩 배출하지 않고 수집된 묶음 단위로 배출
FlatMap — 하나의 Observable이 발행하는 항목들을 여러개의 Observable로 변환하고, 항목들의 배출을 차례차례 줄 세워 하나의 Observable로 전달
GroupBy — 원본 Observable이 배출하는 항목들을 키(Key) 별로 묶은 후 Observable에 담는다. 이렇게 키 별로 만들어진 Observable들은 자기가 담고 있는 묶음의 항목들을 배출한다
Map — Observable이 배출한 항목에 함수를 적용한다
Scan — Observable이 배출한 항목에 연속적으로 함수를 적용하고 실행한 후 성공적으로 실행된 함수의 리턴 값을 발행한다
Window — 정기적으로 Observable의 항목들을 더 작은 단위의 Observable 윈도우로 나눈 후에, 한번에 하나씩 항목들을 발행하는 대신 작게 나눠진 윈도우 단위로 항목들을 배출한다

Filtering Observables(Observable 필터링)

소스 Observable에서 선택적으로 항목을 배출하는 연산자들

Debounce — Observable의 시간 흐름이 지속되는 상태에서 다른 항목들은 배출하지 않고 특정 시간마다 그 시점에 존재하는 항목 하나를 Observable로부터 배출한다
Distinct — Observable이 배출하는 항목들 중 중복을 제거한 항목들을 배출한다
ElementAt — Obserable에서 n번째 항목만 배출한다
Filter — 테스트 조건을 만족하는 항목들만 배출한다
First — 맨 첫 번째 항목 또는 조건을 만족하는 첫 번째 항목만 배출한다
IgnoreElements — 항목들을 배출하지는 않고 종료 알림은 보낸다
Last — Observable의 마지막 항목만 배출한다
Sample — 특정 시간 간격으로 최근에 Observable이 배출한 항목들을 배출한다
Skip — Observable이 배출한 처음 n개의 항목들을 숨긴다
SkipLast — Observable이 배출한 마지막 n개의 항목들을 숨긴다
Take — Observable이 배츨한 처음n개의 항목들만 배출한다
TakeLast — Observable이 배출한 마지막 n개의 항목들만 배출한다

Combining Observables(Observables 결합)

여러 개의 소스 Observable들을 하나의 Observable로 만드는 연산자들

And/Then/When — 두 개 이상의 Observable들이 배출한 항목들을 'Pattern'과 'Plan' 중계자를 이용해서 결합한다
CombineLatest — 두 개의 Observable 중 하나가 항목을 배출할 때 배출된 마지막 항목과 다른 한 Observable이 배출한 항목을 결합한 후 함수를 적용하여 실행 후 실행된 결과를 배출한다
Join — A Observable과 B Observable이 배출한 항목들을 결합하는데, 이때 B Observable은 배출한 항목이 타임 윈도우를 가지고 있고 이 타임 윈도우가 열린 동안 A Observable은 항목의 배출을 계속한다. Join 연산자는 B Observable의 항목을 배출하고 배출된 항목은 타임 윈도우를 시작시킨다. 타임 윈도우가 열려 있는 동안 A Observable은 자신의 항목들을 계속 배출하여 이 두 항목들을 결합한다
Merge — 복수 개의 Observable들이 배출하는 항목들을 머지시켜 하나의 Observable로 만든다
StartWith — 소스 Observable이 항목을 배출하기 전에 다른 항목들을 앞에 추가한 후 배출한다
Switch — Observable들을 배출하는 Observable을 싱글 Observable로 변환하다. 변환된 싱글 Observable은 변환 전 소스 Observable들이 배출한 항목들을 배출한다
Zip — 명시한 함수를 통해 여러 Observable들이 배출한 항목들을 결합하고 함수의 실행 결과를 배출한다

오류 처리 연산자

Observable이 던진 오류를 복구할 수 있도록 도와주는 연산자들

Catch — 오류를 무시하고 배출되는 항목들을 계속 진행시켜 'onError'로부터 전달된 오류를 복구한다
Retry — 만약 소스 Observable이 'onError' 알림을 보낼 경우, 오류 없이 실행이 완료되기를 기대하며 재구독을 시도한다

Observable 유틸리티 연산자

Obserable과 함께 동작하는 유용한 도우미 연산자들

Delay — Observable의 배출을 특정 시간동안 미룬다
Do — Observable의 생명주기 동안 발생하는 여러 이벤트에서 실행될 액션을 등록한다
Materialize/Dematerialize — 배출된 항목이 어떤 알림을 통해 옵저버에게 전달 됐는지를 표현하며, 그 반대 과정을 수행할 수 있다
ObserveOn — 옵저버가 어느 스케줄러 상에서 Observable을 관찰할지 명시한다
Serialize — Observable이 직렬화된 호출을 생성하고 제대로 동작하도록 강제한다
Subscribe — Observable이 배출하는 항목과 알림을 기반으로 동작한다
SubscribeOn — Observable을 구독할 때 사용할 스케줄러를 명시한다
TimeInterval — 항목들을 배출하는 Observable을, 항목을 배출하는데 걸린 시간이 얼마인지를 가리키는 Observable로 변환한다
Timeout — 소스 Obvservable을 그대로 전달하지만, 대신 특정 시간 동안 배출된 항목이 없으면 오류 알림을 보낸다
Timestamp — Observable이 배출한 항목에 타임 스탬프를 추가한다
Using — 소스 Observable과 동일한 생명주기를 갖는 Observable을 생성하는데, 이 Observable은 생명주기가 완료되면 리소스를 종료하고 반환한다

조건과 불린 연산자(Boolean)

하나 이상의 Observable 또는 Observable이 배출한 항목을 평가하는 연산자들

All — Observable이 배출한 전체 항목들이 어떤 조건을 만족시키는지 판단한다
Amb — 두 개 이상의 소스 Observable이 주어 질때, 그 중 첫 번째로 항목을 배출한 Observable이 배출하는 항목들을 전달한다
Contains — Observable이 특정 항목을 배출하는지 아닌지를 판단한다
DefaultIfEmpty — 소스 Observable이 배출하는 항목을 전달한다. 만약 배출되는 항목이 없으면 기본 항목을 배출한다
SequenceEqual — 두 개의 Observable이 항목을 같은 순서로 배출하는지 판단한다
SkipUntil — 두 번째 Observable이 항목을 배출하기 전까지 배출된 항목들을 버린다
SkipWhile — 특정 조건이 false를 리턴하기 전까지 Observable이 배출한 항목들을 버린다
TakeUntil — 두 번째 Observable이 항목을 발행하기 시작했거나 두 번째 Observable이 종료되면 그 때부터 발행되는 항목들은 버린다
TakeWhile — 특정 조건이 false를 리턴하기 시작하면 그 이후에 배출되는 항목들을 버린다

수학과 집계 연산자

Observable이 배출하는 항목 전체를 대상으로 동작하는 연산자들

Average — Observable이 발행한 항목의 평균 값을 발행한다
Concat — 두 개 이상의 Observable들이 항목을 발행할 때 Observable 순서대로 배출하는 항목들을 하나의 Observable 배출로 연이어 배출한다
Count — 소스 Observable이 발행한 항목의 개수를 배출한다
Max — Observable이 발행한 항목 중 값이 가장 큰 항목을 배출한다
Min — Observable이 발행한 항목 중 값이 가장 작은 항목을 배출한다
Reduce — Observable이 배출한 항목에 함수를 순서대로 적용하고 함수를 연산한 후 최종 결과를 발행한다
Sum — Observable이 배출한 항목의 합계를 배출한다

역압(Backpressure) 연산자

backpressure operators — 옵저버가 소비하는 것보다 더 빠르게 항목들을 생산하는 Observable을 복제하는 전략

연결 가능한 Observable 연산자

좀 더 정확히 제어되는 구독 역학을 가진 전문 Observable들

Connect — 구독자가 항목 배출을 시작할 수 있도록 연결 가능한 Observable에게 명령을 내린다
Publish — 일반 Observable을 연결 가능한 Observable로 변환한다
RefCount — 일반 Observable처럼 동작하는 연결 가능한 Observable을 만든다
Replay — 비록 옵저버가 Observable이 항목 배출을 시작한 후에 구독을 했다 하더라도 배출된 모든 항목들을 볼 수 있도록 한다

Observable 변환 연산자

To — Observable을 다른 객체나 자료 구조로 변환한다

새로운 Observable을 생성하는 연산자.

※ 참고 출처

ReactiveX 공식 문서

ReactiveX - Operators

Introduction Each language-specific implementation of ReactiveX implements a set of operators. Although there is much overlap between implementations, there are also some operators that are only implemented in certain implementations. Also, each implementa

reactivex.io

[iOS / RxSwift] Observable

Minny27 — Thu, 1 Sep 2022 01:53:10 +0900

Observable

In ReactiveX an observer subscribes to an Observable. Then that observer reacts to whatever item or sequence of items the Observable emits. This pattern facilitates concurrent operations because it does not need to block while waiting for the Observable to emit objects, but instead it creates a sentry in the form of an observer that stands ready to react appropriately at whatever future time the Observable does so.

ReactiveX에서 observer는 Observable을 구독합니다. 그런 다음 해당 observer는 Observable이 방출하는 아이템 또는 아이템 시퀀스에 반응합니다. 이 패턴은 Observable이 객체를 방출하기를 기다리는 동안 블락할 필요가 없기 때문에 동시 작업을 용이하게 하지만, 관찰자가 미래에 어떤 식으로든 적절하게 반응할 준비가 된 관찰자의 형태로 보초를 만듭니다.

This page explains what the reactive pattern is and what Observables and observers are (and how observers subscribe to Observables). Other pages show how you use the variety of Observable operators to link Observables together and change their behaviors.

이 페이지는 반응 패턴이 무엇인지, Observable과 Observer가 무엇인지(그리고 Observer가 Observable을 구독하는 방법)을 설명합니다. 다른 페이지에서는 다양한 Observable operator를 사용하여 Observable을 함께 연결하고 동작을 변경하는 방법을 보여줍니다.

This documentation accompanies its explanations with “marble diagrams.” Here is how marble diagrams represent Observables and transformations of Observables:

이 문서에는 "마블 다이어그램"과 함께 설명이 함께 제공됩니다. 다음은 마블 다이어그램이 Observable과 Observable의 변환을 나타내는 방법입니다.

Background

In many software programming tasks, you more or less expect that the instructions you write will execute and complete incrementally, one-at-a-time, in order as you have written them. But in ReactiveX, many instructions may execute in parallel and their results are later captured, in arbitrary order, by “observers.” Rather than calling a method, you define a mechanism for retrieving and transforming the data, in the form of an “Observable,” and then subscribe an observer to it, at which point the previously-defined mechanism fires into action with the observer standing sentry to capture and respond to its emissions whenever they are ready.

많은 소프트웨어 프로그래밍 작업에서 작성하는 명령이 작성한 순서대로 한 번에 하나씩 점진적으로 실행되고 완료될 것으로 예상합니다. 그러나 ReactiveX에서는 많은 명령어가 병렬(Parallel)로 실행될 수 있으며 그 결과는 나중에 "observers"에 의해 임의의 순서로 캡처됩니다. 메소드를 호출하는 대신 "Observable"의 형태로 데이터를 검색하고 변환하는 메커니즘을 정의한 다음 observer을 구독합니다. 이 지점에서 이전에 정의된 메커니즘은 observer가 서 있는 보초와 함께 동작하여 준비가 될 때마다 emission을 포착하고 대응합니다.

An advantage of this approach is that when you have a bunch of tasks that are not dependent on each other, you can start them all at the same time rather than waiting for each one to finish before starting the next one — that way, your entire bundle of tasks only takes as long to complete as the longest task in the bundle.

이 접근 방식의 장점은 서로 의존하지 않는 여러 작업이 있을 때 다음 작업을 시작하기 전에 각 작업이 완료되기를 기다리는 대신 동시에 모든 작업을 시작할 수 있다는 것입니다. 작업 번들은 번들에서 가장 긴 작업만큼 완료하는 데 시간이 걸립니다.

There are many terms used to describe this model of asynchronous programming and design. This document will use the following terms: An observer subscribes to an Observable. An Observable emits items or sends notifications to its observers by calling the observers’ methods.

이 비동기 프로그래밍 및 설계 모델을 설명하는 데 사용되는 용어가 많이 있습니다. 이 문서에서는 다음과 같은 용어를 사용합니다. observer는 Observable을 구독합니다. Observable은 항목을 내보내거나 observer의 메서드를 호출하여 observer에게 알림을 보냅니다.

In other documents and other contexts, what we are calling an “observer” is sometimes called a “subscriber,” “watcher,” or “reactor.” This model in general is often referred to as the “reactor pattern”.

다른 문서 및 기타 맥락에서 우리가 "observer"라고 부르는 것을 "구독자", "감시자" 또는 "반응기"라고 하는 경우가 있습니다. 일반적으로 이 모델을 "reactor pattern"이라고 합니다.

Establishing Observers

This page uses Groovy like pseudocode for its examples, but there are ReactiveX implementations in many languages.

이 페이지는 예제를 위해 Groovy와 유사한 의사 코드를 사용하지만 많은 언어로 ReactiveX 구현이 있습니다.

In an ordinary method call — that is, not the sort of asynchronous, parallel calls typical in ReactiveX — the flow is something like this:

Call a method.
Store the return value from that method in a variable.
Use that variable and its new value to do something useful.

ReactiveX에서 일반적으로 사용되는 일종의 비동기식 병렬 호출이 아닌 일반 메서드 호출에서 흐름은 다음과 같습니다.

메서드를 호출
해당 메서드의 반환 값을 변수에 저장
해당 변수와 새 값을 사용하여 유용한 작업을 수행

Or, something like this:

또는 다음과 같습니다.

// make the call, assign its return value to `returnVal`
returnVal = someMethod(itsParameters);
// do something useful with returnVal

In the asynchronous model the flow goes more like this:

Define a method that does something useful with the return value from the asynchronous call; this method is part of the observer.
Define the asynchronous call itself as an Observable.
Attach the observer to that Observable by subscribing it (this also initiates the actions of the Observable).
Go on with your business; whenever the call returns, the observer’s method will begin to operate on its return value or values — the items emitted by the Observable.
Which looks something like this:

비동기식 모델에서 흐름은 다음과 같이 진행됩니다.

비동기 호출의 반환 값으로 유용한 작업을 수행하는 메서드를 정의합니다. 이 방법은 관찰자의 일부입니다.
비동기 호출 자체를 Observable로 정의합니다.
Observable을 구독하여 관찰자를 해당 Observable에 연결합니다(이는 Observable의 작업도 시작함).
작업을 계속하십시오. 호출이 반환될 때마다 관찰자의 메서드는 반환 값(Observable에서 내보낸 항목)에 대해 작동하기 시작합니다.
다음과 같이 보입니다.

// defines, but does not invoke, the Subscriber's onNext handler
// (in this example, the observer is very simple and has only an onNext handler)
def myOnNext = { it -> do something useful with it };
// defines, but does not invoke, the Observable
def myObservable = someObservable(itsParameters);
// subscribes the Subscriber to the Observable, and invokes the Observable
myObservable.subscribe(myOnNext);
// go on about my business

onNext, onCompleted, and onError

The Subscribe method is how you connect an observer to an Observable. Your observer implements some subset of the following methods:

구독 방법은 관찰자를 관찰자에 연결하는 방법입니다. 관찰자는 다음 메서드의 일부 하위 집합을 구현합니다.

onNext

An Observable calls this method whenever the Observable emits an item. This method takes as a parameter the item emitted by the Observable.

Observable은 Observable이 항목을 방출할 때마다 이 메서드를 호출합니다. 이 메소드는 Observable이 내보낸 항목을 매개변수로 사용합니다.

onError

An Observable calls this method to indicate that it has failed to generate the expected data or has encountered some other error. It will not make further calls to onNext or onCompleted. The onError method takes as its parameter an indication of what caused the error.

Observable은 이 메서드를 호출하여 예상 데이터 생성에 실패했거나 다른 오류가 발생했음을 나타냅니다. onNext 또는 onCompleted를 더 이상 호출하지 않습니다. onError 메서드는 매개변수로 오류를 일으킨 원인을 나타냅니다.

onCompleted

An Observable calls this method after it has called onNext for the final time, if it has not encountered any errors.

Observable은 오류가 발생하지 않은 경우 마지막으로 onNext를 호출한 후 이 메서드를 호출합니다.

By the terms of the Observable contract, it may call onNext zero or more times, and then may follow those calls with a call to either onCompleted or onError but not both, which will be its last call. By convention, in this document, calls to onNext are usually called “emissions” of items, whereas calls to onCompleted or onError are called “notifications.”

Observable 조건에 따라 onNext를 0번 이상 호출한 다음 해당 호출에 따라 onCompleted 또는 onError 중 하나를 호출할 수 있지만 둘 다 호출할 수는 없습니다. 이 호출은 마지막 호출이 됩니다. 관례에 따라 이 문서에서 onNext에 대한 호출은 일반적으로 항목의 "방출"이라고 하는 반면 onCompleted 또는 onError에 대한 호출은 "알림"이라고 합니다.

A more complete subscribe call example looks like this:

보다 완전한 구독 호출 예는 다음과 같습니다.

def myOnNext     = { item -> /* do something useful with item */ };
def myError      = { throwable -> /* react sensibly to a failed call */ };
def myComplete   = { /* clean up after the final response */ };
def myObservable = someMethod(itsParameters);
myObservable.subscribe(myOnNext, myError, myComplete);
// go on about my business

Unsubscribing

In some ReactiveX implementations, there is a specialized observer interface, Subscriber, that implements an unsubscribe method. You can call this method to indicate that the Subscriber is no longer interested in any of the Observables it is currently subscribed to. Those Observables can then (if they have no other interested observers) choose to stop generating new items to emit.

일부 ReactiveX 구현에는 구독 취소 메서드를 구현하는 특수 observer 인터페이스인 Subscriber가 있습니다. 구독자가 현재 구독 중인 Observable에 더 이상 관심이 없음을 나타내기 위해 이 메서드를 호출할 수 있습니다. 그런 다음 해당 Observable은 (관심 있는 다른 observer가 없는 경우) 방출할 새 아이템 생성을 중지하도록 선택할 수 있습니다.

The results of this unsubscription will cascade back through the chain of operators that applies to the Observable that the observer subscribed to, and this will cause each link in the chain to stop emitting items. This is not guaranteed to happen immediately, however, and it is possible for an Observable to generate and attempt to emit items for a while even after no observers remain to observe these emissions.

이 구독 취소의 결과는 관찰자가 구독한 Observable에 적용되는 연산자 체인을 통해 다시 캐스케이드백되며 이로 인해 체인의 각 링크에서 항목 방출이 중지됩니다. 그러나 이것은 즉시 발생한다고 보장되지 않으며 이러한 방출을 관찰할 observer가 남아 있지 않은 후에도 잠시 동안 Observable이 항목을 생성하고 방출을 시도할 수 있습니다.

Some Notes on Naming Conventions(네이밍 규칙 참고 사항)

Each language-specific implementation of ReactiveX has its own naming quirks. There is no canonical naming standard, though there are many commonalities between implementations.

ReactiveX의 각 언어별 구현에는 고유한 이름 지정 문제가 있습니다. 구현 간에 많은 공통점이 있지만 정식 명명 표준은 없습니다.

Furthermore, some of these names have different implications in other contexts, or seem awkward in the idiom of a particular implementing language.

또한 이러한 이름 중 일부는 다른 컨텍스트에서 다른 의미를 갖거나 특정 구현 언어의 관용구에서 어색해 보입니다.

For example there is the onEvent naming pattern (e.g. onNext, onCompleted, onError). In some contexts such names would indicate methods by means of which event handlers are registered. In ReactiveX, however, they name the event handlers themselves.

예를 들어 onEvent 이름 지정 패턴이 있습니다(예: onNext, onCompleted, onError). 일부 컨텍스트에서 이러한 이름은 이벤트 핸들러가 등록되는 방법을 나타내는 메서드를 나타냅니다. 그러나 ReactiveX에서는 이벤트 핸들러 자체의 이름을 지정합니다.

“Hot” and “Cold” Observables

When does an Observable begin emitting its sequence of items? It depends on the Observable. A “hot” Observable may begin emitting items as soon as it is created, and so any observer who later subscribes to that Observable may start observing the sequence somewhere in the middle. A “cold” Observable, on the other hand, waits until an observer subscribes to it before it begins to emit items, and so such an observer is guaranteed to see the whole sequence from the beginning.

Observable은 언제 항목 시퀀스를 방출하기 시작합니까? Observable에 따라 다릅니다. "hot" Observable은 생성되자마자 항목을 방출하기 시작할 수 있으므로 나중에 해당 Observable을 구독하는 모든 관찰자는 중간 어딘가에서 시퀀스를 관찰하기 시작할 수 있습니다. 반면에 "cold" Observable은 항목을 방출하기 시작하기 전에 관찰자가 구독할 때까지 기다리므로 그러한 관찰자는 처음부터 전체 시퀀스를 볼 수 있습니다.

In some implementations of ReactiveX, there is also something called a “Connectable” Observable. Such an Observable does not begin emitting items until its Connect method is called, whether or not any observers have subscribed to it.

ReactiveX의 일부 구현에는 "Connectable" Observable이라는 것도 있습니다. 그러한 Observable은 observer가 구독했는지 여부에 관계없이 Connect 메서드가 호출될 때까지 항목을 방출하기 시작하지 않습니다.

Composition via Observable Operators(관찰 가능한 연산자를 통한 구성)

Observables and observers are only the start of ReactiveX. By themselves they’d be nothing more than a slight extension of the standard observer pattern, better suited to handling a sequence of events rather than a single callback.

Observable과 Observer는 ReactiveX의 시작일 뿐입니다. 그 자체로는 표준 관찰자 패턴의 약간의 확장일 뿐이며 단일 콜백보다 일련의 이벤트를 처리하는 데 더 적합합니다.

The real power comes with the “reactive extensions” (hence “ReactiveX”) — operators that allow you to transform, combine, manipulate, and work with the sequences of items emitted by Observables.

진정한 힘은 Observable에서 내보낸 아이템 시퀀스를 변환, 결합, 조작 및 작업할 수 있는 "reactive extensions"(따라서 "ReactiveX")과 함께 제공됩니다.

These Rx operators allow you to compose asynchronous sequences together in a declarative manner with all the efficiency benefits of callbacks but without the drawbacks of nesting callback handlers that are typically associated with asynchronous systems.

이러한 Rx 연산자를 사용하면 콜백의 모든 효율성 이점과 함께 선언적 방식으로 비동기 시퀀스를 함께 구성할 수 있지만 일반적으로 비동기 시스템과 관련된 중첩 콜백 핸들러의 단점이 없습니다.

※ 참고 출처

ReactiveX 공식 문서

ReactiveX - Observable

Observable In ReactiveX an observer subscribes to an Observable. Then that observer reacts to whatever item or sequence of items the Observable emits. This pattern facilitates concurrent operations because it does not need to block while waiting for the Ob

reactivex.io

[iOS / Swift] Memory Safety

Minny27 — Fri, 26 Aug 2022 00:19:13 +0900

Memory Safety(메모리 안전)

By default, Swift prevents unsafe behavior from happening in your code. For example, Swift ensures that variables are initialized before they’re used, memory isn’t accessed after it’s been deallocated, and array indices are checked for out-of-bounds errors.

기본적으로 Swift는 코드에서 안전하지 않은 동작이 발생하는 것을 방지합니다. 예를 들어, Swift는 변수가 사용되기 전에 초기화되고, 할당이 해제된 후 메모리에 액세스되지 않으며, 범위를 벗어난 에러에 대해 배열 인덱스가 검사되는지 확인합니다.

Swift also makes sure that multiple accesses to the same area of memory don’t conflict, by requiring code that modifies a location in memory to have exclusive access to that memory. Because Swift manages memory automatically, most of the time you don’t have to think about accessing memory at all. However, it’s important to understand where potential conflicts can occur, so you can avoid writing code that has conflicting access to memory. If your code does contain conflicts, you’ll get a compile-time or runtime error.

또한 Swift는 메모리의 위치를 수정하는 코드가 해당 메모리에 독점적으로 액세스할 수 있도록 요구함으로써 동일한 메모리 영역에 대한 다중 액세스가 충돌하지 않도록 합니다. Swift는 메모리를 자동으로 관리하기 때문에 대부분의 경우 메모리 액세스에 대해 전혀 생각할 필요가 없습니다. 그러나 잠재적인 충돌이 발생할 수 있는 위치를 이해하는 것이 중요하므로 메모리에 대한 액세스 충돌이 있는 코드 작성을 피할 수 있습니다. 코드에 충돌이 포함되어 있으면 컴파일 시간 또는 런타임 오류가 발생합니다.

Understanding Conflicting Access to Memory(메모리에 대한 충돌 액세스 이해)

Access to memory happens in your code when you do things like set the value of a variable or pass an argument to a function. For example, the following code contains both a read access and a write access:

변수 값을 설정하거나 함수에 인자를 전달하는 것과 같은 작업을 수행할 때, 코드에서 메모리에 대한 액세스가 발생합니다. 예를 들어 다음 코드에는 읽기 액세스와 쓰기 액세스가 모두 포함되어 있습니다.

// A write access to the memory where one is stored.
var one = 1

// A read access from the memory where one is stored.
print("We're number \(one)!")

A conflicting access to memory can occur when different parts of your code are trying to access the same location in memory at the same time. Multiple accesses to a location in memory at the same time can produce unpredictable or inconsistent behavior. In Swift, there are ways to modify a value that span several lines of code, making it possible to attempt to access a value in the middle of its own modification.

메모리에 대한 액세스 충돌은 코드의 다른 부분이 동시에 메모리의 동일한 위치에 액세스하려고 할 때 발생할 수 있습니다. 동시에 메모리의 한 위치에 여러 번 액세스하면 예측할 수 없거나 일관성이 없는 동작이 발생할 수 있습니다. Swift에는 여러 줄의 코드에 걸쳐 있는 값을 수정하는 방법이 있습니다. 이를 통해 자체 수정 중에 값에 액세스를 시도할 수 있습니다.

You can see a similar problem by thinking about how you update a budget that’s written on a piece of paper. Updating the budget is a two-step process: First you add the items’ names and prices, and then you change the total amount to reflect the items currently on the list. Before and after the update, you can read any information from the budget and get a correct answer, as shown in the figure below.

종이에 적힌 예산을 어떻게 업데이트할지 생각해 보면 비슷한 문제를 볼 수 있습니다. 예산 업데이트는 두 단계 프로세스입니다. 먼저 항목의 이름과 가격을 추가한 다음 현재 목록에 있는 항목을 반영하도록 총액을 변경합니다. 업데이트 전후에는 아래 그림과 같이 예산에서 모든 정보를 읽고 정답을 얻을 수 있습니다.

While you’re adding items to the budget, it’s in a temporary, invalid state because the total amount hasn’t been updated to reflect the newly added items. Reading the total amount during the process of adding an item gives you incorrect information.

예산에 항목을 추가하는 동안 총 금액이 새로 추가된 항목을 반영하도록 업데이트되지 않았기 때문에 예산은 일시적이고 잘못된 상태입니다. 항목을 추가하는 과정에서 총 금액을 읽으면 잘못된 정보를 제공합니다.

This example also demonstrates a challenge you may encounter when fixing conflicting access to memory: There are sometimes multiple ways to fix the conflict that produce different answers, and it’s not always obvious which answer is correct. In this example, depending on whether you wanted the original total amount or the updated total amount, either $5 or $320 could be the correct answer. Before you can fix the conflicting access, you have to determine what it was intended to do.

이 예는 또한 충돌하는 메모리 액세스를 수정할 때 직면할 수 있는 문제를 보여줍니다. 충돌을 수정하는 여러 가지 방법으로 다른 답변이 생성되는 경우가 있으며 어떤 답변이 올바른지 항상 명확하지 않습니다. 이 예에서 원래 총 금액을 원하는지 아니면 업데이트된 총 금액을 원하는지에 따라 $5 또는 $320가 정답이 될 수 있습니다. 충돌하는 액세스를 수정하기 전에 의도한 작업을 결정해야 합니다.

NOTE

If you’ve written concurrent or multithreaded code, conflicting access to memory might be a familiar problem. However, the conflicting access discussed here can happen on a single thread and doesn’t involve concurrent or multithreaded code.

동시 또는 다중 스레드 코드를 작성했다면 메모리에 대한 액세스 충돌이 익숙한 문제일 수 있습니다. 그러나 여기에서 설명하는 충돌 액세스는 단일 스레드에서 발생할 수 있으며 동시 또는 다중 스레드 코드를 포함하지 않습니다.

If you have conflicting access to memory from within a single thread, Swift guarantees that you’ll get an error at either compile time or runtime. For multithreaded code, use Thread Sanitizer to help detect conflicting access across threads.

단일 스레드 내에서 충돌하는 메모리 액세스가 있는 경우 Swift는 컴파일 시간이나 런타임에 오류가 발생하도록 보장합니다. 다중 스레드 코드의 경우 Thread Sanitizer를 사용하여 스레드 간에 충돌하는 액세스를 감지할 수 있습니다.

Characteristics of Memory Access(메모리 액세스의 특성)

There are three characteristics of memory access to consider in the context of conflicting access: whether the access is a read or a write, the duration of the access, and the location in memory being accessed. Specifically, a conflict occurs if you have two accesses that meet all of the following conditions:

At least one is a write access or a nonatomic access.
They access the same location in memory.
Their durations overlap.

액세스가 충돌하는 상황에서 고려해야 할 메모리 액세스의 세 가지 특성이 있습니다. 액세스가 읽기인지 쓰기인지, 액세스 기간 및 액세스되는 메모리의 위치입니다. 특히 다음 조건을 모두 충족하는 두 개의 액세스 권한이 있는 경우 충돌이 발생합니다.

적어도 하나는 쓰기 액세스 또는 비원자 액세스입니다.
메모리의 동일한 위치에 액세스합니다.
기간이 겹칩니다.

The difference between a read and write access is usually obvious: a write access changes the location in memory, but a read access doesn’t. The location in memory refers to what is being accessed—for example, a variable, constant, or property. The duration of a memory access is either instantaneous or long-term.

읽기 액세스와 쓰기 액세스의 차이점은 일반적으로 분명합니다. 쓰기 액세스는 메모리의 위치를 변경하지만 읽기 액세스는 변경하지 않습니다. 메모리의 위치는 액세스 중인 항목(예: 변수, 상수 또는 프로퍼티)을 나타냅니다. 메모리 액세스 기간은 순간적이거나 장기적입니다.

An operation is atomic if it uses only C atomic operations; otherwise it’s nonatomic. For a list of those functions, see the stdatomic(3) man page.

C 원자적 연산만 사용하는 경우 연산은 원자적입니다. 그렇지 않으면 비원자적입니다. 이러한 함수 목록은 stdatomic(3) 매뉴얼 페이지를 참조하십시오.

An access is instantaneous if it’s not possible for other code to run after that access starts but before it ends. By their nature, two instantaneous accesses can’t happen at the same time. Most memory access is instantaneous. For example, all the read and write accesses in the code listing below are instantaneous:

액세스가 시작된 후 종료되기 전에 다른 코드를 실행할 수 없는 경우 액세스는 즉각적입니다. 본질적으로 두 개의 즉각적인 액세스는 동시에 발생할 수 없습니다. 대부분의 메모리 액세스는 즉각적입니다. 예를 들어 아래 코드 목록의 모든 읽기 및 쓰기 액세스는 즉각적입니다.

func oneMore(than number: Int) -> Int {
    return number + 1
}

var myNumber = 1
myNumber = oneMore(than: myNumber)
print(myNumber)
// Prints "2"

However, there are several ways to access memory, called long-term accesses, that span the execution of other code. The difference between instantaneous access and long-term access is that it’s possible for other code to run after a long-term access starts but before it ends, which is called overlap. A long-term access can overlap with other long-term accesses and instantaneous accesses.

그러나 다른 코드 실행에 걸쳐 메모리에 액세스하는 여러 가지 방법이 있습니다. 이를 장기 액세스라고 합니다. 즉시 액세스와 장기 액세스의 차이점은 장기 액세스가 시작된 후 종료되기 전에 다른 코드가 실행될 수 있다는 점입니다. 이를 오버랩이라고 합니다. 장기 액세스는 다른 장기 액세스 및 순간 액세스와 중첩될 수 있습니다.

Overlapping accesses appear primarily in code that uses in-out parameters in functions and methods or mutating methods of a structure. The specific kinds of Swift code that use long-term accesses are discussed in the sections below.

중복 액세스는 주로 함수 및 메서드에서 in-out 매개변수를 사용하거나 구조체의 메서드를 변경(mutating)하는 코드에서 나타납니다. 장기 액세스를 사용하는 특정 종류의 Swift 코드는 아래 섹션에서 설명합니다.

Conflicting Access to In-Out Parameters(In-Out 매개변수에 대한 액세스 충돌)

A function has long-term write access to all of its in-out parameters. The write access for an in-out parameter starts after all of the non-in-out parameters have been evaluated and lasts for the entire duration of that function call. If there are multiple in-out parameters, the write accesses start in the same order as the parameters appear.

함수는 모든 in-out 매개변수에 대한 장기 쓰기 액세스 권한을 가집니다. in-out 매개변수에 대한 쓰기 액세스는 모든 non-in-out 매개변수가 평가된 후 시작되고 해당 함수 호출의 전체 기간 동안 지속됩니다. in-out 매개변수가 여러 개인 경우 쓰기 액세스는 매개변수가 나타나는 순서대로 시작됩니다.

One consequence of this long-term write access is that you can’t access the original variable that was passed as in-out, even if scoping rules and access control would otherwise permit it—any access to the original creates a conflict. For example:

이 장기 쓰기 액세스의 결과 중 하나는 범위 지정 규칙과 액세스 제어가 허용하더라도 in-out으로 전달된 원래 변수에 액세스할 수 없다는 것입니다. 원본에 대한 액세스는 충돌을 일으킵니다. 예를 들어:

var stepSize = 1

func increment(_ number: inout Int) {
    number += stepSize
}

increment(&stepSize)
// Error: conflicting accesses to stepSize

In the code above, stepSize is a global variable, and it’s normally accessible from within increment(_:). However, the read access to stepSize overlaps with the write access to number. As shown in the figure below, both number and stepSize refer to the same location in memory. The read and write accesses refer to the same memory and they overlap, producing a conflict.

위의 코드에서 stepSize는 전역 변수이며 일반적으로 increment(_:) 내에서 액세스할 수 있습니다. 그러나 stepSize에 대한 읽기 액세스는 number에 대한 쓰기 액세스와 겹칩니다. 아래 그림과 같이 number와 stepSize는 모두 메모리의 동일한 위치를 참조합니다. 읽기 및 쓰기 액세스는 동일한 메모리를 참조하며 중복되어 충돌이 발생합니다.

One way to solve this conflict is to make an explicit copy of stepSize:

이 충돌을 해결하는 한 가지 방법은 stepSize의 명시적 복사본을 만드는 것입니다.

// Make an explicit copy.
var copyOfStepSize = stepSize
increment(&copyOfStepSize)

// Update the original.
stepSize = copyOfStepSize
// stepSize is now 2

When you make a copy of stepSize before calling increment(_:), it’s clear that the value of copyOfStepSize is incremented by the current step size. The read access ends before the write access starts, so there isn’t a conflict.

increment(_:)를 호출하기 전에 stepSize의 복사본을 만들 때 copyOfStepSize의 값이 현재 단계 크기만큼 증가하는 것이 분명합니다. 읽기 접근은 쓰기 접근이 시작되기 전에 끝나므로 충돌이 없습니다.

Another consequence of long-term write access to in-out parameters is that passing a single variable as the argument for multiple in-out parameters of the same function produces a conflict. For example:

in-out 매개변수에 대한 장기 쓰기 액세스의 또 다른 결과는 동일한 함수의 여러 in-out 매개변수에 대한 인수로 단일 변수를 전달하면 충돌이 발생한다는 것입니다. 예를 들어:

func balance(_ x: inout Int, _ y: inout Int) {
    let sum = x + y
    x = sum / 2
    y = sum - x
}
var playerOneScore = 42
var playerTwoScore = 30
balance(&playerOneScore, &playerTwoScore)  // OK
balance(&playerOneScore, &playerOneScore)
// Error: conflicting accesses to playerOneScore

The balance(_:_:) function above modifies its two parameters to divide the total value evenly between them. Calling it with playerOneScore and playerTwoScore as arguments doesn’t produce a conflict—there are two write accesses that overlap in time, but they access different locations in memory. In contrast, passing playerOneScore as the value for both parameters produces a conflict because it tries to perform two write accesses to the same location in memory at the same time.

위의 balance(_:_:) 함수는 두 매개변수를 수정하여 전체 값을 균등하게 나눕니다. playerOneScore 및 playerTwoScore를 인수로 사용하여 호출하면 충돌이 발생하지 않습니다. 시간적으로 겹치는 두 개의 쓰기 액세스가 있지만 메모리의 다른 위치에 액세스합니다. 대조적으로 두 매개변수의 값으로 playerOneScore를 전달하면 메모리의 동일한 위치에 대해 동시에 두 개의 쓰기 액세스를 수행하려고 하기 때문에 충돌이 발생합니다.

NOTE

Because operators are functions, they can also have long-term accesses to their in-out parameters. For example, if balance(_:_:) was an operator function named <^>, writing playerOneScore <^> playerOneScore would result in the same conflict as balance(&playerOneScore, &playerOneScore).

연산자는 함수이기 때문에 in-out 매개변수에 장기간 액세스할 수도 있습니다. 예를 들어, balance(_:_:)가 <^>라는 연산자 함수인 경우 playerOneScore <^> playerOneScore를 작성하면 balance(&playerOneScore, &playerOneScore)와 동일한 충돌이 발생합니다.

Conflicting Access to self in Methods(메서드에서 self에 대한 충돌 액세스)

A mutating method on a structure has write access to self for the duration of the method call. For example, consider a game where each player has a health amount, which decreases when taking damage, and an energy amount, which decreases when using special abilities.

구조체의 mutating 메서드는 메서드 호출 기간 동안 자체에 대한 쓰기 액세스 권한을 가집니다. 예를 들어, 각 플레이어가 피해를 입을 때 감소하는 건강 양이 있고 특수 능력을 사용할 때 감소하는 에너지 양이 있는 게임을 고려하십시오.

struct Player {
    var name: String
    var health: Int
    var energy: Int

    static let maxHealth = 10
    mutating func restoreHealth() {
        health = Player.maxHealth
    }
}

In the restoreHealth() method above, a write access to self starts at the beginning of the method and lasts until the method returns. In this case, there’s no other code inside restoreHealth() that could have an overlapping access to the properties of a Player instance. The shareHealth(with:) method below takes another Player instance as an in-out parameter, creating the possibility of overlapping accesses.

위의 restoreHealth() 메서드에서 self에 대한 쓰기 액세스는 메서드의 시작 부분에서 시작하여 메서드가 반환될 때까지 지속됩니다. 이 경우 플레이어 인스턴스의 프로퍼티에 중복 액세스할 수 있는 restoreHealth() 내부에 다른 코드가 없습니다. 아래의 shareHealth(with:) 메서드는 다른 Player 인스턴스를 in-out 매개변수로 사용하여 액세스가 겹칠 가능성을 만듭니다.

extension Player {
    mutating func shareHealth(with teammate: inout Player) {
        balance(&teammate.health, &health)
    }
}

var oscar = Player(name: "Oscar", health: 10, energy: 10)
var maria = Player(name: "Maria", health: 5, energy: 10)
oscar.shareHealth(with: &maria)  // OK

In the example above, calling the shareHealth(with:) method for Oscar’s player to share health with Maria’s player doesn’t cause a conflict. There’s a write access to oscar during the method call because oscar is the value of self in a mutating method, and there’s a write access to maria for the same duration because maria was passed as an in-out parameter. As shown in the figure below, they access different locations in memory. Even though the two write accesses overlap in time, they don’t conflict.

위의 예에서 Oscar의 플레이어가 Maria의 플레이어와 건강을 공유하도록 shareHealth(with:) 메서드를 호출해도 충돌이 발생하지 않습니다. oscar는 mutating 메서드에서 self의 값이기 때문에 메서드 호출 중에 oscar에 대한 쓰기 액세스가 있고, Maria가 in-out 매개변수로 전달되었기 때문에 동일한 기간 동안 Maria에 대한 쓰기 액세스가 있습니다. 아래 그림과 같이 메모리의 다른 위치에 액세스합니다. 두 쓰기 액세스가 시간적으로 겹치더라도 충돌하지 않습니다.

However, if you pass oscar as the argument to shareHealth(with:), there’s a conflict:

그러나 shareHealth(with:)의 인수로 oscar를 전달하면 충돌이 발생합니다.

oscar.shareHealth(with: &oscar)
// Error: conflicting accesses to oscar

The mutating method needs write access to self for the duration of the method, and the in-out parameter needs write access to teammate for the same duration. Within the method, both self and teammate refer to the same location in memory—as shown in the figure below. The two write accesses refer to the same memory and they overlap, producing a conflict.

mutating 메소드는 메소드 기간 동안 self에 대한 쓰기 액세스가 필요하고 in-out 매개변수는 동일한 기간 동안 teammate에 대한 쓰기 액세스가 필요합니다. 메서드 내에서 자신과 팀원 모두 아래 그림과 같이 메모리의 동일한 위치를 참조합니다. 두 개의 쓰기 액세스는 동일한 메모리를 참조하고 겹치므로 충돌이 발생합니다.

Conflicting Access to Properties(프로퍼티에 대한 액세스 충돌)

Types like structures, tuples, and enumerations are made up of individual constituent values, such as the properties of a structure or the elements of a tuple. Because these are value types, mutating any piece of the value mutates the whole value, meaning read or write access to one of the properties requires read or write access to the whole value. For example, overlapping write accesses to the elements of a tuple produces a conflict:

구조체, 튜플 및 열거형와 같은 타입은 구조체의 프로퍼티이나 튜플의 요소와 같은 개별 구성 값으로 구성됩니다. 이들은 값 타입이기 때문에 값의 일부를 변경하면 전체 값이 변경됩니다. 즉, 프로퍼티 중 하나에 대한 읽기 또는 쓰기 액세스에는 전체 값에 대한 읽기 또는 쓰기 액세스가 필요합니다. 예를 들어, 튜플의 요소에 대한 중복 쓰기 액세스는 충돌을 생성합니다.

var playerInformation = (health: 10, energy: 20)
balance(&playerInformation.health, &playerInformation.energy)
// Error: conflicting access to properties of playerInformation

In the example above, calling balance(_:_:) on the elements of a tuple produces a conflict because there are overlapping write accesses to playerInformation. Both playerInformation.health and playerInformation.energy are passed as in-out parameters, which means balance(_:_:) needs write access to them for the duration of the function call. In both cases, a write access to the tuple element requires a write access to the entire tuple. This means there are two write accesses to playerInformation with durations that overlap, causing a conflict.

위의 예에서 튜플의 요소에 대해 balance(_:_:)를 호출하면 playerInformation에 대한 중복 쓰기 액세스가 있기 때문에 충돌이 발생합니다. playerInformation.health와 playerInformation.energy는 모두 in-out 매개변수로 전달됩니다. 즉, balance(_:_:)는 함수 호출 기간 동안 이에 대한 쓰기 액세스 권한이 필요합니다. 두 경우 모두 튜플 요소에 대한 쓰기 액세스에는 전체 튜플에 대한 쓰기 액세스 권한이 필요합니다. 이는 플레이어 정보에 대한 두 개의 쓰기 액세스가 중복되는 지속 시간으로 인해 충돌을 일으키고 있음을 의미합니다.

The code below shows that the same error appears for overlapping write accesses to the properties of a structure that’s stored in a global variable.

아래 코드는 전역 변수에 저장된 구조체의 프로퍼티에 대한 중복 쓰기 액세스에 대해 동일한 오류가 나타나는 것을 보여줍니다.

var holly = Player(name: "Holly", health: 10, energy: 10)
balance(&holly.health, &holly.energy)  // Error

In practice, most access to the properties of a structure can overlap safely. For example, if the variable holly in the example above is changed to a local variable instead of a global variable, the compiler can prove that overlapping access to stored properties of the structure is safe:

실제로 구조체 프로퍼티에 대한 대부분의 액세스는 안전하게 겹칠 수 있습니다. 예를 들어 위의 예에서 변수 holly가 전역 변수 대신 지역 변수로 변경되면 컴파일러는 구조체의 저장 프로퍼티에 대한 중복 액세스가 안전하다는 것을 증명할 수 있습니다.

func someFunction() {
    var oscar = Player(name: "Oscar", health: 10, energy: 10)
    balance(&oscar.health, &oscar.energy)  // OK
}

In the example above, Oscar’s health and energy are passed as the two in-out parameters to balance(_:_:). The compiler can prove that memory safety is preserved because the two stored properties don’t interact in any way.

위의 예에서 Oscar의 건강과 에너지는 balance(_:_:)에 대한 두 개의 in-out 매개변수로 전달됩니다. 컴파일러는 두 개의 저장 프로퍼티가 어떤 식으로든 상호 작용하지 않기 때문에 메모리 안전이 유지됨을 증명할 수 있습니다.

The restriction against overlapping access to properties of a structure isn’t always necessary to preserve memory safety.Memory safety is the desired guarantee, but exclusive access is a stricter requirement than memory safety-which means some code preserves memory safety, even though it violates exclusive access to memory. Swift allows this memory-safe code if the compiler can prove that the nonexclusive access to memory is still safe. Specifically, it can prove that overlapping access to properties of a structure is safe if the following conditions apply:

메모리 안전을 유지하기 위해 구조체 프로퍼티에 대한 중복 액세스에 대한 제한이 항상 필요한 것은 아닙니다. 메모리 안전은 원하는 보장이지만 배타적 액세스는 메모리 안전보다 더 엄격한 요구 사항입니다. 즉, 일부 코드는 메모리에 대한 배타적 액세스를 위반하더라도 메모리 안전을 유지합니다. 컴파일러가 메모리에 대한 비독점적 액세스가 여전히 안전하다는 것을 증명할 수 있는 경우 Swift는 이 메모리 안전 코드를 허용합니다. 특히 다음 조건이 적용되는 경우 구조채 프로퍼티에 대한 중복 액세스가 안전하다는 것을 증명할 수 있습니다.

You’re accessing only stored properties of an instance, not computed properties or class properties.

The structure is the value of a local variable, not a global variable.
The structure is either not captured by any closures, or it’s captured only by nonescaping closures.
If the compiler can’t prove the access is safe, it doesn’t allow the access.

연산 프로퍼티나 클래스 타입이 아닌 인스턴스의 저장된 프로퍼티에만 액세스하고 있습니다.

구조체는 전역 변수가 아니라 지역 변수의 값입니다.
구조체는 클로저에 의해 캡처되지 않거나 nonescaping 클로저에만 캡처됩니다.
컴파일러가 액세스가 안전한지 증명할 수 없으면 액세스를 허용하지 않습니다.

※ 참고 출처

애플 개발자 문서

Memory Safety — The Swift Programming Language (Swift 5.7)

Memory Safety By default, Swift prevents unsafe behavior from happening in your code. For example, Swift ensures that variables are initialized before they’re used, memory isn’t accessed after it’s been deallocated, and array indices are checked for

docs.swift.org

[iOS / UIKit] View Controller Life Cycle(뷰 컨트롤러 생명 주기)

Minny27 — Fri, 25 Mar 2022 13:55:03 +0900

오늘 설명할 내용은 view controller life cycle입니다.

iOS 앱 개발에 있어서 필수적으로 알아야 하는 개념입니다.

일반적으로 iOS 앱 화면에 view controller를 띄우는데

view controller에는 생명주기(life cycle)가 있고, 이를 고려해서 앱을 개발해야 합니다.

view controller의 생명주기를 도식화하면 다음과 같습니다.

생명주기와 관련된 메서드들에 대해서 알아보겠습니다.

1. init(coder:)

View Controller을 storyboard로 생성할 경우, view controller의 객체가 생성될 때 초기화 작업을 하는 메서드가 바로 init(coder:) 메서드입니다. init(coder:) 메서드는 view controller가 생명주기 동안 필요한 자원을 할당합니다.

2. init(nibName:bundle:)

Storyboard가 아닌 분리된, nib파일로 생성할 경우 init(nibName:bundle) 메서드로 view controller를 초기화할 수 있습니다.

3. loadView()

View Controller에 나타날 view를 만드는 메서드

View Controller를 코드로 생성할 때 사용하는 메서드입니다. view controller를 storyboard 혹은. nib 파일로 생성하는 경우, override하지 않는 것이 좋습니다.

outlet과 action이 이 메서드에서 생성되고 연결됩니다.

4. viewDidLoad()

모든 outlet(테이블 뷰, 버튼 등)이 메모리에 로드된 후 호출되는 메서드.

이 메서드는 view controller 생명주기 동안 한 번만 실행됩니다.

이 메서드에서 다음의 공통된 작업을 수행합니다.

네트워크 호출
User Interface(addSubview 같은 작업)
한 번 실행하는 작업

5. viewWillAppear(_:)

View가 뷰 계층에 추가될 것임을 뷰 컨트롤러에 알리는 메서드

이 메서드는 화면에 view controller가 나타난 이후에 호출되는 메서드입니다.

이 메서드는 다음과 같은 상황에서 사용할 수 있습니다.

비디오 또는 소리 재생
화면에 포함된 애니메이션 실행
화면에 포함된 데이터 업데이트
화면 전환 이후 다시 돌아와서 수행하는 작업

6. viewDidAppear(_:)

뷰가 뷰 계층에 추가되었음을 뷰 컨트롤러에 알리는 메서드

데이터를 포함하고 있는 view controller의 view가 완전히 화면에 나타나고 호출되는 메서드입니다.

7. viewWillDisappear(_:)

뷰가 뷰 계층에서 제거될 것임을 뷰 컨트롤러에 알리는 메서드

다음 view controller로 화면이 전환되기 전, original view controller가 화면에서 사라질 때 이 메서드가 호출됩니다.

8. viewDidDisappear(_:)

뷰가 뷰 계층에서 제거되었음을 뷰 컨트롤러에 알리는 메서드

View Controller가 화면에서 사라지고 나서 이 메서드가 호출됩니다. 화면에서 view controller가 사라진 이후에는 멈추어야 할 작업들 이 메서드를 override 하여 작성할 수 있습니다.

화면이 사라질 때 필요 없을 수 있는 작업은 다음과 같습니다.

notification을 듣는 행위 멈추기
다른 객체의 프로퍼티를 observing 멈추기
네트워크를 호출

9. deinit()

다른 객체와 마찬가지로 View Controller가 메모리에서 사라지기 전 이 메서드가 호출됩니다. ARC에 의해 할당 해제되지 않은 자원들을 해제하기 위해 override 할 수 있습니다. 또한 백그라운드에서 실행되는 메서드를 이 메서드 내에서 멈출 수 있습니다.

View Controller가 화면에서 사라지는 것이 메모리에서 해제되는 것은 아닙니다. 많은 container view controller들이 그들의 view controller들을 메모리에서 유지하고 있기 때문입니다.

예를 들어 Navigation Controller를 더욱 깊숙이 들어가 보면 이전에 보였던 모든 view controller들이 여전히 메모리에 남아있습니다. Navigation Controller는 View Hierarchy 내에서 Back을 하는 경우에만 사라진 View Controller를 할당 해제할 수 있습니다.

이러한 이유로 화면에서 사라진 view controller들이 정상적으로 작동하고 여전히 notification을 받을 수 있다는 것을 명심해야 합니다.

※ 참고 출처

baked-corn

애플 개발자 문서

medium

Join Us - 지원

Minny27 — Sat, 12 Mar 2022 13:39:59 +0900

이기고 싶다면 합류하라!

LCK 리그 일정, 선수 정보, 순위, 뉴스를 한 눈에!

# LCK 리그 금일 경기 일정과 선수 정보 제공

오늘 경기 일정을 확인할 수 있어요

팀을 선택하면 그 팀의 선수를 볼 수 있어요

선수를 선택하면 그 선수의 정보를 확인할 수 있어요

# LCK 리그 월별 일정 제공

월별로 경기 일정을 확인할 수 있어요

# LCK 리그 순위 제공

리그 순위를 확인해보세요

시즌을 선택하면 해당 시즌의 순위를 확인할 수 있어요

# LOL 뉴스 제공

롤관련 뉴스를 확인할 수 있어요

뉴스를 클릭하면 해당 기사를 볼 수 있어요

Join Us - 개인정보 처리 방침

Minny27 — Sat, 12 Mar 2022 01:13:55 +0900

< ELLO >('https://minny27.tistory.com/'이하 'ELLO')은(는) 「개인정보 보호법」 제30조에 따라 정보주체의 개인정보를 보호하고 이와 관련한 고충을 신속하고 원활하게 처리할 수 있도록 하기 위하여 다음과 같이 개인정보 처리방침을 수립·공개합니다.

○ 이 개인정보처리방침은 2022년 1월 1부터 적용됩니다.

제1조(개인정보의 처리 목적)

< ELLO >('https://minny27.tistory.com/'이하 'ELLO')은(는) 다음의 목적을 위하여 개인정보를 처리합니다. 처리하고 있는 개인정보는 다음의 목적 이외의 용도로는 이용되지 않으며 이용 목적이 변경되는 경우에는 「개인정보 보호법」 제18조에 따라 별도의 동의를 받는 등 필요한 조치를 이행할 예정입니다.

1. 홈페이지 회원가입 및 관리

각종 고지∙통지 목적으로 개인정보를 처리합니다.

제2조(개인정보의 처리 및 보유 기간)

① < ELLO >은(는) 법령에 따른 개인정보 보유·이용기간 또는 정보주체로부터 개인정보를 수집 시에 동의받은 개인정보 보유·이용기간 내에서 개인정보를 처리·보유합니다.

② 각각의 개인정보 처리 및 보유 기간은 다음과 같습니다.

1.<홈페이지 회원가입 및 관리>
<홈페이지 회원가입 및 관리>와 관련한 개인정보는 수집.이용에 관한 동의일로부터<1년>까지 위 이용목적을 위하여 보유.이용됩니다.
보유근거 : 고지·통지
관련법령 : 신용정보의 수집/처리 및 이용 등에 관한 기록 : 3년

제3조(정보주체와 법정대리인의 권리·의무 및 그 행사방법)

① 정보주체는 ELLO에 대해 언제든지 개인정보 열람·정정·삭제·처리정지 요구 등의 권리를 행사할 수 있습니다.

② 제1항에 따른 권리 행사는ELLO에 대해 「개인정보 보호법」 시행령 제41조제1항에 따라 서면, 전자우편, 모사전송(FAX) 등을 통하여 하실 수 있으며 ELLO은(는) 이에 대해 지체 없이 조치하겠습니다.

③ 제1항에 따른 권리 행사는 정보주체의 법정대리인이나 위임을 받은 자 등 대리인을 통하여 하실 수 있습니다.이 경우 “개인정보 처리 방법에 관한 고시(제2020-7호)” 별지 제11호 서식에 따른 위임장을 제출하셔야 합니다.

④ 개인정보 열람 및 처리정지 요구는 「개인정보 보호법」 제35조 제4항, 제37조 제2항에 의하여 정보주체의 권리가 제한 될 수 있습니다.

⑤ 개인정보의 정정 및 삭제 요구는 다른 법령에서 그 개인정보가 수집 대상으로 명시되어 있는 경우에는 그 삭제를 요구할 수 없습니다.

⑥ ELLO은(는) 정보주체 권리에 따른 열람의 요구, 정정·삭제의 요구, 처리정지의 요구 시 열람 등 요구를 한 자가 본인이거나 정당한 대리인인지를 확인합니다.

제4조(개인정보의 파기)

① < ELLO > 은(는) 개인정보 보유기간의 경과, 처리목적 달성 등 개인정보가 불필요하게 되었을 때에는 지체없이 해당 개인정보를 파기합니다.

② 정보주체로부터 동의받은 개인정보 보유기간이 경과하거나 처리목적이 달성되었음에도 불구하고 다른 법령에 따라 개인정보를 계속 보존하여야 하는 경우에는, 해당 개인정보를 별도의 데이터베이스(DB)로 옮기거나 보관장소를 달리하여 보존합니다.
1. 법령 근거 :
2. 보존하는 개인정보 항목 : 계좌정보, 거래날짜

③ 개인정보 파기의 절차 및 방법은 다음과 같습니다.
1. 파기절차
< ELLO > 은(는) 파기 사유가 발생한 개인정보를 선정하고, < ELLO > 의 개인정보 보호책임자의 승인을 받아 개인정보를 파기합니다.

2. 파기방법

전자적 파일 형태의 정보는 기록을 재생할 수 없는 기술적 방법을 사용합니다

제5조(개인정보의 안전성 확보 조치)

< ELLO >은(는) 개인정보의 안전성 확보를 위해 다음과 같은 조치를 취하고 있습니다.

1. 개인정보에 대한 접근 제한
개인정보를 처리하는 데이터베이스시스템에 대한 접근권한의 부여,변경,말소를 통하여 개인정보에 대한 접근통제를 위하여 필요한 조치를 하고 있으며 침입차단시스템을 이용하여 외부로부터의 무단 접근을 통제하고 있습니다.

제6조(개인정보 자동 수집 장치의 설치•운영 및 거부에 관한 사항)

ELLO 은(는) 정보주체의 이용정보를 저장하고 수시로 불러오는 ‘쿠키(cookie)’를 사용하지 않습니다.

제7조 (개인정보 보호책임자)

① ELLO 은(는) 개인정보 처리에 관한 업무를 총괄해서 책임지고, 개인정보 처리와 관련한 정보주체의 불만처리 및 피해구제 등을 위하여 아래와 같이 개인정보 보호책임자를 지정하고 있습니다.

▶ 개인정보 보호책임자
성명 : 이승민
이메일 : dltmdals0608@naver.com

제8조(권익침해 구제방법)

정보주체는 개인정보침해로 인한 구제를 받기 위하여 개인정보분쟁조정위원회, 한국인터넷진흥원 개인정보침해신고센터 등에 분쟁해결이나 상담 등을 신청할 수 있습니다. 이 밖에 기타 개인정보침해의 신고, 상담에 대하여는 아래의 기관에 문의하시기 바랍니다.

1. 개인정보분쟁조정위원회 : (국번없이) 1833-6972 (www.kopico.go.kr)
2. 개인정보침해신고센터 : (국번없이) 118 (privacy.kisa.or.kr)
3. 대검찰청 : (국번없이) 1301 (www.spo.go.kr)
4. 경찰청 : (국번없이) 182 (ecrm.cyber.go.kr)

「개인정보보호법」제35조(개인정보의 열람), 제36조(개인정보의 정정·삭제), 제37조(개인정보의 처리정지 등)의 규정에 의한 요구에 대 하여 공공기관의 장이 행한 처분 또는 부작위로 인하여 권리 또는 이익의 침해를 받은 자는 행정심판법이 정하는 바에 따라 행정심판을 청구할 수 있습니다.

※ 행정심판에 대해 자세한 사항은 중앙행정심판위원회(www.simpan.go.kr) 홈페이지를 참고하시기 바랍니다.

제9조(개인정보 처리방침 변경)

① 이 개인정보처리방침은 2022년 1월 1부터 적용됩니다.

ELLO의 개발일지

깃으로 협업하기 - 실습편

※ 우리팀 룰:

1. 브랜치 생성하기

2. 모든 작업이 완료되면, 자신의 작업을 임시저장(stash)합니다.

3. dev 브랜치 최신화

4. will 브랜치를 dev 브랜치로 최신화(merge)

5. 임시 저장한 작업 불러오기

6. 충돌 수정

7. 수정 사항 반영

기록 및 정리에 대한 생각's

[iOS / RxSwift] Subject

Subject

Varieties of Subject(Subject의 종류)

AsyncSubject

BehaviorSubject

PublishSubject

ReplaySubject

※ 참고 출처

[iOS / RxSwift] Single

Single

Composition via Single Operators

※ 참고 출처

[iOS / RxSwift] Operators

Introduction

Chaining Operators

Operators By Category

Creating Observables(Observable 생성)

Transforming Observables(Observable 변환)

Filtering Observables(Observable 필터링)

Combining Observables(Observables 결합)

오류 처리 연산자

Observable 유틸리티 연산자

조건과 불린 연산자(Boolean)

수학과 집계 연산자

역압(Backpressure) 연산자

연결 가능한 Observable 연산자

Observable 변환 연산자

※ 참고 출처

[iOS / RxSwift] Observable

Observable

Background

Establishing Observers

onNext, onCompleted, and onError

Unsubscribing

Some Notes on Naming Conventions(네이밍 규칙 참고 사항)

“Hot” and “Cold” Observables

Composition via Observable Operators(관찰 가능한 연산자를 통한 구성)

※ 참고 출처

[iOS / Swift] Memory Safety

Memory Safety(메모리 안전)

Understanding Conflicting Access to Memory(메모리에 대한 충돌 액세스 이해)

Characteristics of Memory Access(메모리 액세스의 특성)

Conflicting Access to In-Out Parameters(In-Out 매개변수에 대한 액세스 충돌)

Conflicting Access to self in Methods(메서드에서 self에 대한 충돌 액세스)

Conflicting Access to Properties(프로퍼티에 대한 액세스 충돌)

※ 참고 출처

[iOS / UIKit] View Controller Life Cycle(뷰 컨트롤러 생명 주기)

1. init(coder:)

2. init(nibName:bundle:)

3. loadView()

4. viewDidLoad()

5. viewWillAppear(_:)

6. viewDidAppear(_:)

7. viewWillDisappear(_:)

8. viewDidDisappear(_:)

9. deinit()

※ 참고 출처

Join Us - 지원

Join Us - 개인정보 처리 방침

3. `dev` 브랜치 최신화

4. `will` 브랜치를 `dev` 브랜치로 최신화(merge)