ListView와 같은 스크롤 가능한 위젯에서는 많은 위젯이 동적으로 생성되고 제거됩니다. 이러한 과정에서 스크롤 위치를 유지하기 위해 Flutter는 스크롤 위치에 대한 정보를 저장하고 관리합니다.

이때, 스크롤 가능한 위젯의 하위 위젯들이 각각 고유한 키를 가지지 않으면, Flutter가 위젯을 동적으로 생성하거나 제거할 때 오류가 발생할 수 있습니다. 이는 위젯이 중복되거나 삭제되지 않아 스크롤 위치가 변경되지 않는 문제를 초래할 수 있습니다.

따라서, ListView와 같은 스크롤 가능한 위젯에서는 고유한 키를 지정하여 위젯을 식별하고, 스크롤 위치를 유지하는 것이 중요합니다. 특히, ListView.builder나 ListView.separated와 같이 동적으로 위젯을 생성하는 경우에는 key가 중요한 역할을 합니다.

즉, 스크롤 위젯의 하위 위젯들이 키를 갖고 있지 않으면, 스크롤 위젯에 오류가 발생할 수 있다네?

맞습니다. 스크롤 가능한 위젯의 하위 위젯들이 고유한 키를 갖고 있지 않으면, 스크롤 가능한 위젯이 동적으로 생성되거나 제거될 때 위젯의 상태가 유지되지 않을 수 있습니다. 이는 스크롤 위치가 변경되지 않아서 위젯이 중복되거나 삭제되지 않는 문제를 초래할 수 있습니다. 따라서 스크롤 가능한 위젯에서는 하위 위젯들에게 고유한 키를 부여하여 위젯을 식별하고 스크롤 위치를 유지하는 것이 중요합니다. 특히 동적으로 위젯을 생성하는 경우에는 키가 매우 중요합니다.

즉, 자식 위젯들은 ValueKey를 넣으면 충분하겠네?

ValueKey는 위젯의 값(value)에 의해 식별됩니다. 값이 같으면 같은 위젯으로 간주됩니다. 따라서 자식 위젯들이 고유한 값을 갖고 있다면 ValueKey를 사용할 수 있습니다.

하지만 스크롤 가능한 위젯에서는 자식 위젯이 생성 및 삭제되면서 값이 변경되는 경우가 많기 때문에 고유한 값이 유지되지 않을 수 있습니다. 따라서 고유한 값이 없거나 값이 변경될 가능성이 있는 경우에는 ObjectKey나 UniqueKey를 사용하는 것이 좋습니다. 이렇게 하면 스크롤 위치를 정확하게 유지할 수 있습니다.

그렇군. 고유값이 있다면 ValueKey로 충분하고, 그렇지 않다면, UniqueKey 같은걸 쓰면 되겠네?

네, 그렇습니다. 만약 위젯이 고유한 값이 있다면 그 값을 기반으로 ValueKey를 사용하는 것이 좋습니다. 예를 들어, 리스트 뷰의 아이템이라면, 그 아이템이 가지고 있는 고유한 ID 값을 사용하여 ValueKey를 생성할 수 있습니다.

하지만, 만약 위젯이 고유한 값이 없다면, UniqueKey를 사용하여 위젯을 식별하는 것이 좋습니다. UniqueKey는 위젯이 생성될 때 랜덤한 값을 가지므로, 고유성이 보장됩니다.

부분적으로 맞습니다. Flutter에서 StatefulWidget은 위젯 트리에서 변경 가능한 상태를 관리하기 위해 사용됩니다. StatefulWidget은 위젯 트리의 구조가 변경되면 새로 생성될 수 있지만, 그와 동시에 State 객체는 상태 정보를 보존하기 위해 재사용될 수 있습니다.

하지만, 이것이 항상 Key를 사용하여 이전에 생성된 위젯과 연결된 State를 재사용하는 것은 아닙니다. Key는 위젯을 식별하기 위한 유일한 값입니다. Key를 사용하면, Flutter 프레임워크가 위젯 트리의 위치가 변경되거나 재구성되었을 때 이전에 생성된 위젯과 연결된 상태를 보존하거나 재사용할 수 있도록 돕습니다.

StatefulWidget에 Key를 할당하지 않으면, 프레임워크가 위젯 인스턴스와 연관된 State 객체를 재사용할 수 없습니다. 이 경우, 위젯이 다시 빌드되면 새로운 State 객체가 생성됩니다.

따라서, 이전에 생성된 StatefulWidget 위젯과 연결된 State를 재사용하려면, 해당 위젯에 적절한 Key를 할당해야 합니다. 이렇게 하면 프레임워크가 필요한 경우 이전 상태를 보존하고 재사용할 수 있습니다.

key가 없으면 state가 절대 재사용되지 않아?

일반적으로 Key가 없는 경우 State 객체가 재사용되지 않습니다. 그러나 StatefulWidget이 동일한 위치에 있고 위젯 트리의 구성이 변경되지 않은 경우, Flutter 프레임워크는 기존 State 객체를 계속 사용할 수 있습니다.

Key는 위젯이 이동하거나 위젯 트리의 구성이 변경되었을 때, Flutter 프레임워크가 이전에 생성된 위젯과 연결된 상태를 보존하고 재사용할 수 있도록 도와줍니다. 따라서 위젯 인스턴스를 올바르게 식별하고 관리하려면 Key를 사용하는 것이 좋습니다.

요약하면, Key가 없으면 State 객체의 재사용은 제한적입니다. 동일한 위치에 있는 StatefulWidget에 대해서는 재사용이 가능하지만, 위젯의 위치가 변경되거나 위젯 트리의 구성이 변경된 경우에는 State 객체가 재사용되지 않습니다. 이러한 상황에서 상태를 보존하고 재사용하려면, Key를 사용해야 합니다.

위에 내가 설명한 내용이 어떤것이 미묘하게 잘못된걸까?

제가 이해한 바로는, 주된 차이점은 다음과 같습니다.

원래의 설명:

• StatefulWidget이 다시 생성되더라도 Key를 사용하여 이전에 생성된 위젯에 연결된 State를 재사용할 수 있다고 설명하셨습니다.

수정된 설명:

• State 객체는 일반적으로 동일한 위치에 있는 StatefulWidget에 대해 재사용됩니다. 하지만 위젯이 이동되거나 위젯 트리의 구성이 변경되었을 때, Key를 사용하여 이전에 생성된 위젯과 연결된 상태를 보존하고 재사용할 수 있습니다.

원래의 설명에서는 StatefulWidget이 다시 생성되더라도 이전에 생성된 위젯에 연결된 State를 재사용할 수 있다고 언급되어 있지만, 이는 Key를 사용할 때만 해당됩니다. 일반적으로 StatefulWidget이 같은 위치에 있고 위젯 트리의 구성이 변경되지 않은 경우에는 State 객체가 재사용됩니다. 그러나 위젯의 위치가 변경되거나 위젯 트리의 구성이 변경되었을 때에는 Key를 사용하여 상태를 보존하고 재사용할 수 있습니다.

즉, 너가 말하고 싶은 것은, key가 없어도, 재사용될 수 있다. key는 위젯이 이동하거나 위젯 트리가 변경되었을 때 유용하다 이네?

네, 정확하게 말씀하셨습니다. Key가 없어도 동일한 위치에 있는 StatefulWidget에 대해서는 State 객체가 재사용될 수 있습니다. 그러나 위젯이 이동하거나 위젯 트리의 구성이 변경되었을 때, 이전에 생성된 위젯과 연결된 상태를 보존하고 재사용하기 위해서는 Key를 사용해야 합니다.

Key를 사용하면 Flutter 프레임워크가 위젯 트리에서 위젯 인스턴스와 관련된 상태를 올바르게 추적하고 관리할 수 있으므로, 상태가 보존되고 재사용될 수 있습니다. 따라서 Key는 위젯이 이동하거나 위젯 트리의 구성이 변경되었을 때 상태를 올바르게 관리하는 데 유용합니다.

key의 종류와 각각의 key는 언제 사용하면 좋은지 알려줘. 그리고 원리도 알려주면 좋겠어.

Flutter에서는 다양한 종류의 Key가 있으며, 각각이 특정 상황에 적합하게 설계되어 있습니다. 여기 몇 가지 주요 Key 유형과 사용 사례를 소개합니다.

1. ValueKey: ValueKey는 주어진 값에 기반하여 위젯을 구별하는 데 사용됩니다. 이 키는 데이터의 실제 값에 따라 위젯을 식별하므로, 동일한 유형의 위젯이 동일한 값을 표시할 때 유용합니다. 예: ValueKey를 사용하여 동일한 데이터를 표시하는 두 개의 리스트 항목을 구별할 수 있습니다.

2. ObjectKey: ObjectKey는 주어진 객체에 기반하여 위젯을 구별하는 데 사용됩니다. 이 키는 객체의 참조에 따라 위젯을 식별하므로, 동일한 유형의 위젯이 동일한 객체를 참조할 때 유용합니다. 예: ObjectKey를 사용하여 동일한 객체를 참조하는 두 개의 카드 위젯을 구별할 수 있습니다.

3. UniqueKey: UniqueKey는 각 인스턴스에 대해 고유한 값을 생성하여 위젯을 구별하는 데 사용됩니다. 이 키는 위젯 인스턴스를 고유하게 식별해야 할 때 유용합니다. 일반적으로 재사용되지 않는 경우에 사용됩니다. 예: UniqueKey를 사용하여 동적으로 생성된 위젯의 인스턴스를 구별할 수 있습니다.

4. GlobalKey: GlobalKey는 전체 위젯 트리에서 고유하게 식별할 수 있는 키입니다. 이 키는 위젯 트리의 한 부분에서 다른 부분으로 데이터를 전달하거나, 상태를 보존하고 재사용할 때 유용합니다. 또한 GlobalKey를 사용하면 전체 애플리케이션에서 위젯 인스턴스에 직접 액세스할 수 있습니다. 그러나 남용하지 않도록 주의해야 합니다. 과도한 사용은 성능에 부정적인 영향을 미칠 수 있습니다. 예: 폼 위젯에서 유효성 검사를 수행하거나 글로벌로 액세스해야 하는 상태를 관리할 때 GlobalKey를 사용할 수 있습니다.

원리: Key의 원리는 위젯 인스턴스와 연관된 상태를 올바르게 추적하고 관리하기 위해 Flutter 프레임워크에 도움을 주는 것입니다. 위젯이 이동하거나 위젯

위 key들은 지역적으로 작동해? 전역적으로 작동해? 그것에 따라 분류해줘. 그리고 더 많은 key에 대해 알려줘. scroll 관련 key도 있더라.

Flutter의 Key는 대부분 지역적으로 작동하며, GlobalKey만 전역적으로 작동합니다. 지역적인 키들은 주로 위젯의 하위 트리 내에서 작동하며, 전역 키는 전체 애플리케이션에서 작동합니다. 각 키를 지역적인 키와 전역적인 키로 분류하면 다음과 같습니다.

지역적인 키:

1. ValueKey
2. ObjectKey
3. UniqueKey

전역적인 키:

1. GlobalKey

추가적인 키:

1. ScrollController 및 ScrollPhysics: 스크롤 동작과 관련된 키입니다. ScrollController를 사용하면 스크롤 가능한 위젯의 스크롤 위치를 제어할 수 있으며, ScrollPhysics를 사용하면 스크롤 동작을 사용자 정의할 수 있습니다. 이러한 키는 스크롤 관련 위젯에서 사용됩니다.

2. PageStorageKey: 이 키는 페이지 저장소를 위한 키로, 페이지 저장소는 스크롤 가능한 위젯의 스크롤 오프셋을 저장하고 복원하는 데 사용됩니다. 예를 들어, ListView 또는 GridView와 같은 스크롤 가능한 위젯에서 사용할 수 있습니다.

3. LabeledGlobalKey: 이 키는 GlobalKey의 서브클래스로, 디버깅을 돕기 위해 문자열 레이블이 추가된 키입니다. 이 키는 위젯 인스턴스를 전역적으로 식별할 수 있게 해주는 동시에 디버깅에 유용한 정보를 제공합니다.

4. LocalKey: Key 클래스의 추상 서브클래스로, 모든 지역적인 키의 기본 클래스입니다. ValueKey, ObjectKey 및 UniqueKey와 같은 다양한 지역적인 키 유형은 LocalKey에서 파생됩니다. 이 클래스를 사용하여 사용자 정의 지역 키를 생성할 수 있습니다.

전역적인 키를 제외한 나머지 키들은 주로 지역적인 범위에서 작동하며, 위젯의 하위 트리 내에서 상태를 관리하는 데 도움을 줍니다. 전역 키는 전체 애플리케이션에서 작동하므로, 전역적으로 상태를 보존하거나 위젯에 액세스하는 경우에 유용합니다.

ScrollController와 ScrollPhysics는 key가 아닌 것 같은데?

죄송합니다. 제가 오해를 일으키는 정보를 제공했습니다. 말씀하신대로 ScrollController와 ScrollPhysics는 키가 아닙니다. 이들은 스크롤 동작과 관련된 클래스이며, 키와 관련이 없습니다. 키와 관련된 추가 정보를 요청하셨으므로, 해당 내용을 다시 정리하겠습니다.

1. ValueKey: 지역적인 키
2. `ObjectKey

정말 key들인 것만 남겨주고, 모두 지역적인지, 전역적인지 분류해줘. 다른 분류가 필요하면 알려줘.

죄송합니다. 앞서 제공한 정보 중에서 실제 키와 관련된 것만 남기고 지역적인 키와 전역적인 키로 분류하겠습니다.

지역적인 키:

1. ValueKey: 주어진 값에 기반하여 위젯을 구별하는 데 사용됩니다.
2. ObjectKey: 주어진 객체에 기반하여 위젯을 구별하는 데 사용됩니다.
3. UniqueKey: 각 인스턴스에 대해 고유한 값을 생성하여 위젯을 구별하는 데 사용됩니다.
4. PageStorageKey: 페이지 저장소를 위한 키로, 페이지 저장소는 스크롤 가능한 위젯의 스크롤 오프셋을 저장하고 복원하는 데 사용됩니다.

전역적인 키:

1. GlobalKey: 전체 위젯 트리에서 고유하게 식별할 수 있는 키입니다. 위젯 트리의 한 부분에서 다른 부분으로 데이터를 전달하거나, 상태를 보존하고 재사용할 때 유용합니다.

디버깅용 키:

1. LabeledGlobalKey: GlobalKey의 서브클래스로, 디버깅을 돕기 위해 문자열 레이블이 추가된 키입니다. 이 키는 위젯 인스턴스를 전역적으로 식별할 수 있게 해주는 동시에 디버깅에 유용한 정보를 제공합니다.

일반적으로 키들은 지역적인 키와 전역적인 키로 분류됩니다. 지역적인 키들은 주로 위젯의 하위 트리 내에서 작동하며, 전역 키는 전체 애플리케이션에서 작동합니다. 디버깅용 키인 LabeledGlobalKey는 전역 키이지만, 주로 디버깅 목적으로 사용됩니다.

LabeledGlobalKey를 쓰는게 더 좋겠네? 장단점이 있니?

LabeledGlobalKey는 GlobalKey의 서브클래스로, 주로 디버깅 목적으로 사용됩니다. 문자열 레이블이 추가되어 있어 디버깅 과정에서 더 많은 정보를 제공합니다. 이 키를 사용하는 경우에 대한 장단점을 살펴보겠습니다.

장점:

1. 디버깅 정보 제공: LabeledGlobalKey는 디버깅 정보를 제공하여 문제가 발생했을 때 원인을 찾기 쉽게 만들어 줍니다. 문자열 레이블을 통해 위젯 인스턴스를 더 쉽게 식별할 수 있습니다.
2. 전역 키의 모든 기능 포함: GlobalKey의 모든 기능을 포함하므로, 상태를 전역적으로 보존하거나 위젯 트리의 한 부분에서 다른 부분으로 데이터를 전달하는 데 사용할 수 있습니다.

단점:

1. 성능: LabeledGlobalKey를 사용하면 추가적인 문자열 레이블이 필요하기 때문에 약간의 메모리 및 성능 오버헤드가 발생할 수 있습니다. 따라서 대규모 애플리케이션에서 불필요한 LabeledGlobalKey 사용은 최소화해야 합니다.
2. 디버깅 이외의 목적에는 불필요: LabeledGlobalKey는 주로 디버깅에 유용한 정보를 제공하기 위한 목적으로 사용됩니다. 디버깅에 관련되지 않은 상황에서는 일반적인 GlobalKey를 사용하는 것이 좋습니다.

결론적으로, LabeledGlobalKey는 디버깅 과정에서 유용하지만, 일반적인 상황에서는 불필요한 오버헤드를 초래할 수 있으므로 사용을 최소화하는 것이 좋습니다. 디버깅 이외의 경우에는 일반적인 GlobalKey를 사용하는 것을 권장합니다.

요즘 모바일 기기 사양을 봤을 때 유의미한 성능 오버헤드일까?

요즘 모바일 기기의 사양이 상당히 좋아졌기 때문에, 일부 LabeledGlobalKey를 사용하는 것이 성능에 큰 영향을 미치지 않을 수 있습니다. 하지만, 대규모 애플리케이션에서 여러 개의 LabeledGlobalKey를 사용하게 되면 성능과 메모리 오버헤드가 누적될 수 있습니다.

애플리케이션의 성능과 메모리 사용량을 최적화하는 것은 중요한 고려 사항입니다. 따라서 필요한 경우에만 LabeledGlobalKey를 사용하고, 그 외의 경우에는 일반적인 GlobalKey를 사용하는 것이 좋습니다. 이렇게 하면 애플리케이션의 성능과 메모리 사용량을 관리하는 데 도움이 됩니다.

개발 과정에서 디버깅이 필요한 경우에는 LabeledGlobalKey를 사용하고, 최종 배포 전에 일반적인 GlobalKey로 교체하는 것을 고려할 수 있습니다. 이렇게 하면 디버깅에 도움이 되는 동시에 애플리케이션의 성능을 유지할 수 있습니다.

전역 키를 사용하면, 지역 키에 비해 얼마나 성능적으로 손해를 보는거야?

GlobalKey와 지역 키(예: ValueKey, ObjectKey, UniqueKey) 간의 성능 차이는 상황에 따라 다릅니다. 일반적으로, GlobalKey는 전역적으로 고유하게 식별할 수 있는 키로, 더 복잡한 기능을 제공합니다. 이로 인해 GlobalKey가 지역 키에 비해 약간의 성능 오버헤드를 초래할 수 있습니다.

하지만, GlobalKey와 지역 키 간의 성능 차이는 대부분의 경우 크지 않습니다. 애플리케이션의 성능에 미치는 영향은 키의 사용 방식과 개수, 애플리케이션의 복잡성 등 다양한 요소에 따라 달라집니다.

GlobalKey를 사용할 때 주의할 점은, 과도한 사용으로 인한 위젯 트리의 재구성이 빈번하게 발생할 경우 성능에 영향을 미칠 수 있다는 것입니다. 이러한 상황을 피하기 위해 필요한 경우에만 GlobalKey를 사용하고, 그 외의 경우에는 지역 키를 사용하는 것이 좋습니다.

결론적으로, GlobalKey와 지역 키 간의 성능 차이는 상황에 따라 다르지만 일반적으로 크지 않습니다. 애플리케이션의 성능을 최적화하려면 키를 적절하게 사용하는 것이 중요합니다.

결론

각 키의 특징을 자세히 설명하면 다음과 같습니다.

• 식별키(Identification Key): 위젯을 고유하게 식별하는 용도로 사용되는 키입니다.

  • 지역 키(Local Key) ValueKey: 위젯의 값(value)에 의해 식별됩니다. 값이 같으면 같은 위젯으로 간주됩니다. ObjectKey: 위젯의 객체(identity)에 의해 식별됩니다. 객체가 같으면 같은 위젯으로 간주됩니다. UniqueKey: 랜덤한 유니크한 값에 의해 식별됩니다. 일반적으로 위젯의 생성 시점에 자동으로 생성됩니다. BuildContextKey: 해당 위젯의 BuildContext에 의해 식별됩니다. 같은 BuildContext를 가지는 위젯끼리 같은 것으로 간주됩니다. FocusKey: 위젯이 포커스를 가지는 여부에 따라 식별됩니다. SemanticsObjectKey: 위젯의 semantics(의미론) 정보에 의해 식별됩니다. 접근성과 관련된 정보를 표현하는데 사용됩니다. CompositeKey: 위젯의 여러 속성을 결합하여 식별자를 생성합니다.

  • 전역 키(Global Key) GlobalKey: 전체 위젯 트리에서 유일한 식별자를 가지는 키입니다. 다른 위젯에서 해당 키를 참조할 수 있습니다. LabeledGlobalKey: GlobalKey와 비슷하지만, 개발자가 직접 키 값을 지정할 수 있습니다.

• 저장키(Persistence Key): 위젯을 식별하고, 상태를 저장하거나 복원하기 위해 사용되는 키입니다.

  • PageStorageKey: 위젯의 스크롤 위치나 상태 등을 저장하는 용도로 사용됩니다. 각 키의 역할과 특징을 이해하고 적절한 상황에서 적절한 키를 사용하는 것이 중요합니다.
  • TransitionKey: 애니메이션을 유지하고 다시 시작할 때 애니메이션의 이전 상태를 복원할 수 있습니다.

아래 형태로 활용 가능하다.

    const wordGroups = filteredLine.split('|');
    const words = genSequence(wordGroups)
        .concatMap(a => [a, ...a.split(regExpSpaceOrDash)])
        .concatMap(a => splitCamelCase(a))
        .map(a => a.trim())
        .filter(s => s.length > 2)
        .filter(s => !regExpRepeatChars.test(s))
        .map(a => a.toLowerCase())
        .reduceToSequence((s, w) => s.add(w), new Set());

설치

yarn add rxjs

typescript 설정

추가 설정이 필요 없다.

Observer의 생성 및 사용

(생성) pipe : 연산할 내용 기술
(사용) subscribe : pipe에서의 연산 내용을 사용한다.

``` //const source = from(fetch('/api/endpoint')); //const source = fromEvent(document, 'click'); //const source = of(1, 2, 3, 4, 5); //const source = interval(1000); const source = from([1, 2, 3, 4, 5, 6, 7, 8, 9, 10]);

//비동기적으로 활용하기 //var o = ajax('/api/data'); var o = source.pipe(skip(5)); o.subscribe(val => console.log(val));

참고) https://flyingsquirrel.medium.com/rxjs-rxjs-fruits-%EC%82%AC%EC%9D%B4%ED%8A%B8-%EB%AC%B8%EC%A0%9C-%ED%92%80%EC%96%B4%EB%B3%B4%EA%B8%B0-265c69be3ed7

위 명령어를 통해, xcode 프로젝트에 버전 내용이 반영된다. 하지만, 버전 적용을 위해서 매번 위 명령어를 사용하는 것은 매우 비효율적이다.

이를 위해서, 프로젝트에서 자동으로 pubspec.yaml에서 버전을 반영받는 방법이 있다. 그것은 FLUTTER_BUILD_NUMBER, FLUTTER_BUILD_NAME 환경 변수를 활용하는 것이다.

ios/Runner.xcodeproj/project.pbxproj에서 아래 내용을 수정하면 된다.

• 이전

  CURRENT_PROJECT_VERSION = your buildnumber
  MARKETING_VERSION = your version

• 이후

  CURRENT_PROJECT_VERSION = "$(FLUTTER_BUILD_NUMBER)";
  MARKETING_VERSION = "$(FLUTTER_BUILD_NAME)";

주의: CURRENT_PROJECT_VERSION,MARKETING_VERSION key가 해당 파일에 3번 나오므로, 3개 모두 수정해주어야한다.

참고) https://stackoverflow.com/questions/65277520/flutter-not-using-build-number-from-pubspec-yaml

참고) https://ios-development.tistory.com/251

• SHA-1를 아래 명령어로 돌리면, 카카오 로그인을 위한 해시키가 출력된다.

echo <구글플레이 SHA-1 인증서지문 입력> | xxd -r -p | openssl base64

Play 서명은 업로드 키와 서명 키로 동작한다.

업로드 키는 예전에 서명키로서 사용되었었지만, 사용자가 업로드 키를 분실하는 문제가 많아져, 구글에서 따로 서명키를 관리하기로 하여, 이전에 개발자가 활용하던 키를 업로드 키라고 부르게 되었다.

핵심

이제는 업로드 키를 잃어버리더라도, 나중에 업로드 키를 교체할 수 있는 매커니즘이 추가되었다.

즉, 업로드키는 업로드할 때 필요하고, 피치 못할 사정이 있을 시 교체된다. 서명키는 구글에서 잘 관리해주고, 서명할 때 필요해졌다.

주의

파이어베이스 로그인 시에, 디버그 때는 업로드키의 sha-1을 활용하여 로그인을 허용하고, 릴리즈 때는 서명키의 sha-1를 활용하여 로그인을 허용한다.

따라서, 로그인이 잘되도록 하기 위해서는, 업로드키, 서명키의 sha-1를 파이어베이스에 모두 등록해야한다.

AAB, APK

AAB는 서명하지 않은 배포 파일로서, 구글은 aab로 apk를 만듭니다. 그리고 apk를 서명키로 서명하여, 앱 스토어에 배포합니다.

APK 배포 파일, 21년 8월 이후로 APK로 배포할 수 없습니다.

참고)

https://cocoslime.github.io/blog/Android-App-Signing/

1. PKI란

• 공인 인증기관이 인터넷상에서 사용자간에 법적 효력이 있는 인증서를 전자적으로 분배, 전달, 제공함으로써 비인가된 자로부터 개인 정보보호, 전자상거래 위변조 방지 등을 수행 가능
• 목적 : 누구나 안전하고 편리하게, 효율적으로 공개키를 획득, 사용하게 함. 사용하는 인증서 표준은 주로 x.509
• pki는 공개키를 인증/등록 기관과 같이 신뢰성 있는 제3자를 통해 관리하고 전달함.

2. PKI의 주요 구성 요소

• 인증서 (Certificate) : 인증기관의 개인키로 서명한 인증서, 나의 공개키나 공개키의 정보를 포함하는 인증서

• 인증기관 (Certification Authority, CA) : 인증서의 발급 및 관리

• 등록기관 (Registration Authority, RA) : 신원확인, 고객 데이터 유지 등 인증기관의 입증을 대행하는 등록기관

• 저장소 (Repository) : 공개된 저장소 역할 (저장 및 검색 등) 인증서 : 버전, 일련번호, 유효기간, 식별자 등을 포함. 공개키와 공개키 소유자를 연결해줌.

• 사용자 : Client

  1. 사용자A가 인증서를 RA에 요청
  2. 신분 검증 후 RA는 CA에 인증서 발급 요청
  3. CA는 공개키와 개인키를 생성하여 사용자A에게 개인키를 주고 공개키와 인증서는 인증서 저장소에 저장

3. 인증서 폐기 여부 확인 방법

인증서 폐기 목록 (Certification Revocation List, CRL)

CRL은 폐기된 인증서를 식별하는 시간소인된 목록을 포함하는 서명된 데이터 구조입니다. 폐기된 인증서는 더 이상 신뢰되지 않아 인증에 사용할 수 없습니다. 일반적으로 CRL은 사용자의 고용 상태 또는 업무가 변경되거나, 사용자의 인증서 또는 개인 키가 노출되는 경우 액세스를 차단합니다.

공인인증기관 CA에서 이러한 인증서 폐기 목록을 관리한다. 따라서 인증기관을 통해 인증서 폐기 여부를 확인할 수 있다.

• 개인키(Private key), 공개키(Public key)
• 개인키로 암호화하면, 공개키로 복호화할 수 있고,
• 공개키로 암호화하면, 개인키로 복호화할 수 있다.

전자 서명의 이해

A-B 시스템이 있을 때, A가 B에게 안전한 메시지를 보내고 싶을 때 개인키, 공개키, 전자서명을 사용한다. 전자 서명? 공개키로 메시지를 암호화하는 것을 의미한다. 나만 복호화할 수 있기 때문에 전자서명했다고 한다.

A는 B에게 메시지 + 전자서명된메시지를 보낸다. B는 메시지+전자서명메시지를 받았을 때, 공개키로 전자서명 메시지를 복호화할 수 있다. 이 때, 메시지가 같은지 여부로 해당 메시지의 진위 여부를 파악할 수 있다.

• 위조된 문서
  • 복호화 되지 않는다.
  • 복호화한 메시지가 같이 온 메시지와 내용이 다르다.

즉, 메시지+전자서명메시지를 같이 보내면, 데이터 보낸 것의 무결성, 인증을 보장할 수 있다.

속도를 위해서, 메시지를 해시해서 해시된메시지를 전자서명하기도 한다.

기밀성의 이해

A는 B의 공개키를 갖고 문서를 암호화하면, B의 개인키로만 복호화할 수 있다. B는 A의 공개키를 갖고 문서를 암호화하면, A의 개인키로만 복호화할 수 있다.

• 개인키(Private key), 공개키(Public key)
• 개인키로 암호화하면, 공개키로 복호화할 수 있고,
• 공개키로 암호화하면, 개인키로 복호화할 수 있다.

A-B 시스템이 있을 때, A가 B에게 안전한 메시지를 받고 싶을 때 개인키, 공개키를 사용한다.

A는 개인키를 갖고 있고, B에게 공개키를 준다. B는 공개키를 갖고 메시지를 암호화해서 A에게 전달한다. 이 과정에서, 네트워크에서 암호화된것이 탈취당해도, 복호화할 개인키가 없기 때문에, 해당 메시지를 확인할 수 없다.

오로지, 비밀키를 갖고 있는 A만 B의 내용을 확인할 수 있다.

• 활용 방법
  • 요하네스 이텐의 색상환에서 연속된 3가지 색, 또는 그 색들의 Tone, TInt, Shade을 이용한 3가지 색
• 장점
  • 색이 유사하기에 시각적으로 피로하지 않다.

동일색 조합(구성)

• 활용 방법
  • 하나의 색에 대해 원색, Tint와 Shade로 3가지 구성
• 장점
  • 동일 색에 대해서 명도만 바꾸었기 때문에 통일감, 정리감, 안정감이 느껴진다.

무채색 조합(구성)

• 활용 방법
  • 채색(잉크) 없이, 명도(빛)를 조절한다.
• 장점
  • 진지한 느낌, 무거운 느낌, 경외감 등을 느낄 수 있다.

보색 조합(구성)

• 활용 방법
  • 색상환의 보색(반대색)을 활용한다.
• 장점
  • 반대색을 활용하였기에, 눈에 잘 띈다.

1차색, 2차색 조합(구성)

• 활용 방법
  • 1차색 조합, 2차색 조합
• 장점
  • 원색을 활용했기 때문에 순순한 느낌을 줄 수 있다.

• 중앙에서부터 Color, Shade, Tone, Tint

색은 연속적이지만, 사람이 색을 표현하려면 이산적이어야 한다.

컬러 그라디언트

(이산적분류) 요하네스 이텐의 12색상환

• 1차색(3개) + 2차색(3개) + 3차색(6개)을 섞어서 12개의 색을 완성하였다.

  1차색 (3개)

• 절대로 다른 색을 섞어서 만들 수 없는 기본이 되는 색
• 노파빨(Yellow, Blue, Red)를 나타냄

  2차색 (3개)

• 1차색 2개를 섞으면 나오는 색
• 오보초(Orange, Purple, Green)을 나타냄

  3차색 (6개)

• 1차색 + 2차색을 섞어 나오는 색
• Yellow-Oragne, Red-Orange, Red-Purple, Blue-Purple(남보라), Blue-Green(청록), Yellow-Green(연두)

색의 3속성

• HSV는 hue, saturation, value의 약자이다.
• 원색(hue), 채도(saturation), 명도(value),
  • 원색 : 12 색상환이 아닌, 연속적인 색의 원색
  • 채도 : 잉크가 얼마나 진한가? (유채색 : 색 Yes + 빛 조절)
  • 명도 : 빛이 얼마나 진한가? (무채색 : 색 No, 빛만 조절)

원색(Hue)의 이해

빨강, 주홍, 주황, 노랑, 연두와 같이 일반적으로 부르는 빛깔 이름을 뜻한다.

명도(Value)의 이해

여기서 하나의 색상에서도 밝은 색과 어두운 색까지 다양한 색상이 존재하는데 이렇듯 '밝다'와 '어둡다'로 표현하는 것을 명도라고 한다. 화이트를 많이 섞을 수록 명도가 높아지고, 블랙이 많이 섞이게 되면 명도가 낮아진다. 이때에 화이트가 높은(명도가 높은) 컬러를 틴트(tint), 블랙이 높은(명도가 낮은) 컬러를 쉐이드(shade)라고 한다.

채도(Saturation)의 이해

채도란 색의 선명함 정도를 말하며, 선명도가 높은지 낮은지에 따라 선명함이 달라진다. 여기서 채도가 0일 경우 무채색이라 칭한다