샘성의 iOS 개발 일지

[Web] CSS Flexbox와 Grid를 배워보자!

SamusesApple — Fri, 6 Dec 2024 17:34:19 +0900

CSS 의 꽃, Flexbox와 Grid 부시기

CSS 레이아웃 기술인 Flexbox와 Grid를 배울 수 있는 재미있고 유익한 리소스를 소개합니다.

재미있는 CSS 학습 게임

1. Flexbox Froggy:
- 게임 바로가기
- 개구리에게 CSS 코드를 사용하여 연꽃잎에 도달하도록 도와주는 게임
2. Grid Garden:
- 게임 바로가기
- CSS Grid 레이아웃을 활용하여 당근밭을 가꾸는 게임
3. Flexbox Adventure
- 게임 바로가기
- 모험을 통해 Flexbox 개념을 배우는 게임
4. CSS Dinner
- 게임 바로가기
- CSS 선택자에 대한 지식을 테스트하는 재미있는 게임
5. Flexbox Defense
- 게임 바로가기
- CSS Flexbox를 사용하여 적의 침입을 막는 디펜스 게임
6. Knights of the Flexbox Table
- 게임 바로가기
- Flexbox 개념을 활용하여 문제를 해결하는 게임

CSS 학습 리소스

7. Codecademy - Learn CSS
- 코스 바로가기
- CSS를 체계적으로 학습할 수 있는 온라인 코스
8. CSS Reference
- 사이트 바로가기
- CSS 속성에 대한 자세한 설명과 예제를 제공하는 참고 사이트

[Five Lines of Code] 2. 리펙터링 깊게 들여다보기

SamusesApple — Mon, 29 Jul 2024 11:34:02 +0900

1. 가독성 및 유지보수성 향상

의도 전달로 가독성 향상
불변속성의 범위 제한으로 유지보수성 향상
범위 밖의 코드에 영향 안 주고 위의 2항목 실행
가독성
- (의도한대로 코드가 잘 동작한다면)의도 전달하기 위한 코드의 상징
유지보수성
- 시작: 현존하는 일부 기능을 변경 할 때마다 ‘새 코드의 위치 선정을 위한 조사하기‘
  1. ’전역상태‘로 인해 예상치 못한 사이드 이펙트(취약성)이 발생할 수 있다
  2. 전역상태 찾는 트릭
    1. 중괄호 찾기 (중괄호 내부의 변수에 외부 데이터가 할당되는 경우가 많음)
    2. 전역적으로 사용되는 외부 데이터 관찰 및 불변속성 제거하기
- 코드의 작업을 변경하지 않은 채로 유지보수 하는 법
  - 리펙터링 중에는 코드가 느려져도 신경X (보통 가독성과 유지보수성보다 성능의 가치가 낮다)
  - 성능이 중요한 경우, 리펙토링 다 끝나고 프로파일링 도구 및 성능 전문가의 도움 받아 다른 단계에서 하자
  - 리펙터링 할 코드를 ‘예약’하자
    - 병합 충돌 이슈 방지

2. 속도, 유연성 및 안정성 확보

가장 좋은 메서드명을 짓자

상속 보다는 Composition을 사용하자
- 깔끔한 코드 결합과 재사용이 가능해짐 → 유연성!
- 예시
  - 변수에 클래스 객체 생성해서 할당하기
  - 프로토콜의 컴포지션 활용하기
수정 대신 ’추가에 의한 변경‘을!
- 컴포지션을 사용함으로써 ‘추가’가 용이해짐!
  - 기존 기능에 영향 주지 않고 새로운 기능 추가 혹은 변경 (개방 폐쇄 원칙)
- 프로그래밍 속도 상승
  1. 기존 기능의 코드를 두고 새로운 코드를 추가
  2. 코드 베이스 늘어남
  3. 더이상 사용하지 않는 코드가 무엇인지 잘 살펴보고 빠르게 제거하기
- 안정성
  - 새로운 코드가 실패한 경우, 기존 코드로 대체하기 용이

3. 리펙터링과 일상 업무

"항상 여러분이 왔을 때보다 더 좋게 만들어 놓고 떠나세요"

레거시 시스템에서는 변경하기 전에 리펙터링을 하자
코드 변경 후에도 리펙터링 하기
코드 전달하기 전에 리팩터링을 수행하자

리팩터링은 배우는 데 시간이 걸리지만 곧 익숙해진다!

> 리팩터링을 연습하면 코드에 대한 독특한 관점을 얻을 수 있으며, 이로 인해 더 나은 해결책을 찾을 수 있다.

[Five Lines of Code] 1. 리팩터링 리팩터링하기

SamusesApple — Mon, 29 Jul 2024 11:06:07 +0900

1. 리팩터링이란?

기능을 변경하지 않고 코드를 변경하는 것

대부분의 프로그래머는 코드를 치는 것보다 코드를 이해하는데에 더 많은 시간을 소비한다.
- 코드를 더 빠르게 동작하게 하기
- 더 작은 코드를 만들기
- 더 일반적이거나 재사용 가능한 코드 만들기
- 코드의 가독성 상승, 유지보수 용이
  - 가독성을 높여서 시간을 절약하자 (생각하기 편하게, 새로운 기능 추가하기 쉽게)
  - 유지보수가 용이해지면 버그가 줄고 수정이 용이해진다
테스트 주도 개발을 하면 효과적으로 할 수 있다 (하지만 여기선 다루지 않음)

2. 무엇을?

A. 냄새 나는 코드! (aka 코드 스멜)

여러개 작업을 수행하는 함수
5줄이 넘는 긴 함수
중복되는 함수
여러개의 기능을 가진 클래스

3. 언제?

코딩 할 때마다! (매일 샤워 하듯..)

탐색
명세화
구현
테스트
리펙터링
전달

의 순서로 진행된다.

[인앱결제] StoreKit2로 마이그레이션 하기 (+ 유실 방지 로직)

SamusesApple — Tue, 23 Jul 2024 17:13:03 +0900

StoreKit1 -> StoreKit2로 마이그레이션 하기 + 결제 정보를 서버 DB에서 안전하게 유지하도록 유실 방지 로직 추가하기

StoreKit 에서 StoreKit2로 변경

StoreKit은 Apple에서 제공하는 인앱 결제 라이브러리이다. 기존 StoreKit에서는 영수증 검증을 위해 transactionId endpoint를 사용했지만 deprecated되면서 영수증 검증을 자동으로 해주는 StoreKit2로 변경하게 되었다....

StoreKit2로 마이그레이션

StoreKit에서 StoreKit2로 변경하면서 기본적인 결제를 처리하는 코드

public func purchaseSubscription(_ productId: String) async throws -> Transaction? {
    // 제품 정보 가져오기
    guard let product = try await fetchProductById(productId) else {
        throw PurchaseError.productNotFound
    }
    // 구매 프로세스 시작
    let result = try await product.purchase()

    switch result {
    case .success(let verification):
        // 결제 검증
        let transaction = try await checkTransaction(verification)
        // 서버에 결제 정보 전송
        await sendTransactionToServer(transaction)

        return transaction

    case .userCancelled, .pending:
        // 유저가 결제를 취소하거나 결제가 진행 중인 경우
        return nil

    @unknown default:
        print("Unexpected Error")
        return nil
    }
}

코드 설명

제품 정보 가져오기:여기서는 productId를 기반으로 제품 정보를 가져오기! 해당되는 제품 정보를 가져오지 못하면 PurchaseError.productNotFound 에러를 던진다.
guard let product = try await fetchProductById(productId) else { throw PurchaseError.productNotFound }
구매 프로세스 시작:product.purchase() 메서드를 사용하여 구매 프로세스를 시작하기. 이 메서드는 async 메서드로, 비동기로 앱스토어 구매를 진행한다.
let result = try await product.purchase()
결제 검증:purchase() 메서드가 성공적으로 끝나면, 결제 검증하기. checkTransaction 메서드는 VerificationResult를 매개변수로 받아서 검증된 Transaction 객체를 반환한다.
let transaction = try await checkTransaction(verification)
서버에 결제 정보 전송: 마지막으로 결제된 정보를 서버로 전송한다. 이를 통해 서버에서도 결제 정보를 업데이트할 수 있다!
await sendTransactionToServer(transaction)

유실 방지 로직 추가

결제 정보가 서버에 제대로 반영되지 않으면 앱스토어 결제 자체는 성공했지만, 서버에는 기록되지 않는 경우가 발생할 수 있다. 이를 방지하기 위해 유실 방지 로직을 추가하자!

유실 방지 로직 구현

서버에 결제 정보를 안전하게 전송하는 로직

public func restoreSubscriptionPurchaseDataToServer() async {
    guard await shouldCheckIfPurchaseIsMissing() else {
        print("Need not restore purchase data")
        return
    }
    guard let lastTransaction = try await fetchLastTransaction(), !lastTransaction.isExpired else {
        print("No valid transaction found")
        return
    }
    await sendTransactionToServer(lastTransaction)
}

코드 설명

결제 유실 여부 확인:결제가 유실되었는지 확인하기. 유실되지 않았다면 로직 종료.
guard await shouldCheckIfPurchaseIsMissing() else { print("Need not restore purchase data") return }
마지막 트랜잭션 가져오기:마지막 트랜잭션을 가져와 유효한 결제 정보인지 확인하기. 만약 유효하지 않다면 로직을 종료.
guard let lastTransaction = try await fetchLastTransaction(), !lastTransaction.isExpired else { print("No valid transaction found") return }
서버로 결제 정보 전송: 마지막 트랜잭션 정보를 서버로 전송하여 결제 정보 업데이트.
await sendTransactionToServer(lastTransaction)

서버상 트랜잭션 정보 DB 유효성 검사

private func shouldCheckIfPurchaseIsMissing() async -> Bool {
    // 유저가 로그인했는지 확인
    guard let userId = fetchUserId() else { return false }

    // 유저의 결제 정보 확인 필요 여부
    let shouldCheck = UserDefaults.standard.bool(forKey: "SHOULD_CHECK_PURCHASE")
    return shouldCheck
}

유저가 로그인했는지 확인하고, 결제 정보 확인이 필요한지 UserDefaults에서 값을 가져온다.

만약, true값이 온다면 다시 서버에 유저의 마지막 결제 정보를 보내는 POST 요청을 보내면 된다.

[Tuist] 모듈 생성 자동화 하기 (tuist scaffold, .stencil)

SamusesApple — Tue, 18 Jun 2024 15:50:23 +0900

목적

원하는 모듈을 생성할 때마다 필요한 파일을 하나하나 세팅해주는 번거로움 해결하기.

→ 모듈에 필요한 코드를 템플릿 파일에 미리 작성해두고 tuist scaffold 명령어를 실행하면 자동으로 해당되는 모듈에 대한 파일 및 코드가 작성 됨.

준비물

Tuist 폴더 안에 Templates 폴더 생성
Templates 폴더의 하위 폴더로 '원하는 모듈 이름' 폴더 생성하기
'원하는 모듈 이름' 폴더 안에 '원하는모듈이름.swift' 파일 직접 생성하기

파일 구조

...
  └── Tuist
      └── Templates
          └── Domain
              └── Domain.swift       # Domain 모듈에 대한 템플릿 전체 설정
              └── Package.stencil    # Domain 모듈에 대한 패키지 템플릿 파일
              └── Project.stencil    # Domain 모듈에 대한 기본 프로젝트 템플릿 파일
              └── InfoPlist.stencil  # Domain 모듈에 대한 InfoPlist 템플릿 파일
              └── Test.stencil       # Domain 모듈의 테스트 파일에 대한 템플릿 파일

Domain.swift 파일

import ProjectDescription

// scaffold 명령어 시 받을 인자 정의
let name: Template.Attribute = .required("name") // 하위모듈명 (파일명)
let author: Template.Attribute = .required("author")  // 생성자
let currentDate: Template.Attribute = .required("currentDate") // 생성 날짜

// 템플릿 선언
let domainTemplate = Template(
    description: "A template for a new Domain modules",
    attributes: [
        name,
        author,
        currentDate
    ],
    items: DomainTemplate.allCases.map { $0.item }
)

enum DomainTemplate: CaseIterable {
    case package
    case project
    case infoPlist
    case test

    // 템플릿 내부에 추가할 파일
    var item: Template.Item {
        switch self {
        case .package:
            return .file(path: .basePath + "/Package.swift",
                        templatePath: "Package.stencil")
        case .project:
            return .file(path: .basePath + "/Sources/Project.swift",
                         templatePath: "Project.stencil")
        case .infoPlist:
            return .file(path: .basePath + "/\(name)-Info.plist", 
                        templatePath: "InfoPlist.stencil")
        case .test:
            return .file(path: .basePath + "/Tests/" + .testName + "/" + .testName + ".swift",
                         templatePath: "Test.stencil")
        }
    }
}

// 명령어 실행시 Domain 모듈 파일이 생성될 기본 경로.
extension String {
    static var basePath: Self {
        return "Modules/Domain/\(name)"
    }

    static var testName: Self {
        return "\(name)Tests"
    }
}

Package.stencil 파일

// swift-tools-version: 5.10

import PackageDescription

let package = Package(
    name: "{{ name }}",
    platforms: [
        .iOS(.v17) // 타겟 버전
    ],
    products: [
        .library(
            name: "{{ name }}",
            targets: ["{{ name }}"])
    ],
    dependencies: [
        // 필요한 의존성 추가
    ],
    targets: [
        .target(
            name: "{{ name }}",
            dependencies: []
        )
    ]
)

Project.stencil 파일

// 기본 빈 프로젝트 파일로 세팅

import Foundation

class {{ name }} { }

InfoPlist.stencil 파일

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>CFBundleDevelopmentRegion</key>
    <string>en</string> // region 설정
    <key>CFBundleExecutable</key>
    <string>{{ name }}</string>
    <key>CFBundleIdentifier</key>
    <string>앱번들.{{ name }}</string> // 번들 식별자 정의
    <key>CFBundleInfoDictionaryVersion</key>
    <string>6.0</string>
    <key>CFBundleName</key>
    <string>{{ name }}</string>
    <key>CFBundlePackageType</key>
    <string>FMWK</string>  // 패키지 타입 프레임워크로 세팅
    <key>CFBundleShortVersionString</key>
    <string>1.0</string>
    <key>CFBundleVersion</key>
    <string>1</string>
    <key>CFBundleSupportedPlatforms</key>
    <array>
        <string>iPhoneOS</string> // 타겟 플랫폼 설정
    </array>
    <key>MinimumOSVersion</key>
    <string>17.0</string>  // 최소 타겟 버전
</dict>
</plist>

Test.stencil 파일

// Test 코드를 위한 파일 템플릿

import XCTest
@testable import {{ name }}

class {{ name }}Tests: XCTestCase {
    func testExample() {
        // Example test case
    }
}

템플릿으로 Domain 모듈 만들기

tuist scaffold Domain --name DomainSample --author Sam --current-date 2024/06/18

참고로 Domain.swift 파일에서 'name', 'author', 'currentDate'를 필수 인자로 설정해두었기 때문에 셋 중 하나라도 빠지면 아래와 비슷한 오류가 발생하며 모듈 생성이 불가능하다.

App의 Project.swift 파일에 모듈 추가하기

1. 앱의 모듈 구성 및 의존성을 관리하는 Project.swift 파일에 새로 생성한 모듈 패키지 및 의존성을 추가한다.

// 앱의 Project.swift 파일

let project = Project(
    name: "MyApp",
    packages: [
        .local(path: .relativeToRoot("Modules/Domain/DomainSample")) // 생성한 모듈 패키지 추가
    ],
    targets: [
        .target(
            name: "MyApp",
            destinations: .iOS,
            product: .app,
            bundleId: "io.tuist.myApp",
            deploymentTargets: .iOS("17.0"),
            infoPlist: .extendingDefault(with: infoPlist),
            sources: ["App/Sources/**"],
            resources: ["App/Resources/**"],
            dependencies: [
            	.package(product: "DomainSample") // 앱에 모듈 의존성 추가
            ],
        ),
        .target(
            name: "MyAppTests",
            destinations: .iOS,
            product: .unitTests,
            bundleId: "io.tuist.myAppTests",
            infoPlist: .default,
            sources: ["App/Tests/**"],
            resources: [],
            dependencies: [.target(name: "MyApp")]
        ),
    ]
)

2. tuist generate 명령어를 통해 프로젝트를 재구성한다.

tuist generate

생성된 DomainSample 패키지 추가됨

앱에 Embeded 됨

[디자인 패턴] 추상 팩토리 패턴

SamusesApple — Tue, 18 Jun 2024 11:44:51 +0900

서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 생성자 패턴

팩토리 메서드 패턴과의 차이점?

[디자인 패턴] 팩토리 메서드 패턴

객체 생성을 캡슐화 하여 ‘팩토리 클래스’를 통해 생성하도록 하는 생성 디자인 패턴 구조CreatorProduct 객체를 생성하는 메서드 정의 (protocol / class)Concrete CreatorConcrete Product를 생성하기 위한 구

iossammy.tistory.com

팩토리 매서드
- 1 팩토리 - 1 객체 생성
- 구체적 객체 생성 과정을 하위 클래스에 구현하도록 하는 것이 point
- → 메서드 레벨에서의 구체화된 인스턴스의 생성 및 구성에 대한 의존성 감소
추상 팩토리
- 1 팩토리 - 연관된 여러 종류의 객체 생성
- 연관된 여러 종류 객체의 묶음을 구체적인 클래스에 의존하지 않고 생성 가능하도록 하는 것이 point
  - 클래스 레벨에서의 구체화된 객체의 생성 및 구성에 대한 의존성 감소

Swift 예제 코드

/*
 [배경]
    이전 View에서 **애플 키보드 마우스 세트** or **윈도우 키보드 마우스 세트**를 유저가 선택 할 수 있는 상황
    이전 View에서 어떤 세트를 선택했느냐에 따라 결제 View를 다르게 띄워줘야 한다.
 */

enum TechBrand: CaseIterable {
    case apple
    case window
}

// 추상 팩토리 인터페이스 - 연관된 추상 제품들을 반환하는 메서드들의 집합
protocol KeyboardMouseFactory {
    func createMouse() -> Mouse
    func createKeyboard() -> Keyboard
}

struct AppleKeyboardMouseFactory: KeyboardMouseFactory {
    func createMouse() -> any Mouse {
        return AppleMouse()
    }
    
    func createKeyboard() -> any Keyboard {
        return AppleKeyboard()
    }
}

struct WindowKeyboardMouseFactory: KeyboardMouseFactory {
    func createMouse() -> any Mouse {
        return WindowMouse()
    }
    
    func createKeyboard() -> any Keyboard {
        return WindowKeyboard()
    }
}

// 이미 선택된 TechBrand에 따라 다른 '키보드 + 마우스 세트'를 보여줘야하는 결제 화면
final class PurchaseViewController: UIViewController {
    
    private var keyboardMouseFactory: KeyboardMouseFactory
    
    private lazy var keyboard: Keyboard = keyboardMouseFactory.createKeyboard()
    private lazy var mouse: Mouse = keyboardMouseFactory.createMouse()
    
    // 팩토리 유형이 선택된 TechBrand에 따라 유연하게 바뀐다.
    init(selected type: TechBrand) {
        switch type {
        case .apple:
            self.keyboardMouseFactory = AppleKeyboardMouseFactory()
        case .window:
            self.keyboardMouseFactory = WindowKeyboardMouseFactory()
        }
    }
    
    .
    .
    .
    
    
    func getTotalPrice() {
        print(self.keyboard.price + self.mouse.price)
    }
}

// 마우스
protocol Mouse {
    var price: Int { get }
    
    func click()
    func scroll()
}

struct AppleMouse: Mouse {
    
    var price: Int = 70000
    
    func click() {
        print("애플 마우스 - 클릭")
    }
    
    func scroll() {
        print("애플 마우스 - 스크롤")
    }
}

struct WindowMouse: Mouse {
    
    var price: Int = 50000
    
    func click() {
        print("윈도우 마우스 - 클릭")
    }
    
    func scroll() {
        print("윈도우 마우스 - 스크롤")
    }
}

// 키보드
protocol Keyboard {
    
    var price: Int { get }
    
    func type(_ letter: String)
}

struct AppleKeyboard: Keyboard {
    
    var price: Int = 130000
    
    func type(_ letter: String) {
        print("애플 키보드 -'\\(letter)'")
    }
    
}

struct WindowKeyboard: Keyboard {
    
    var price: Int = 110000
    
    func type(_ letter: String) {
        print("윈도우 키보드 -'\\(letter)'")
    }
    
}

// 1. 애플 세트 선택
let applePurchaseViewController = PurchaseViewController(selected: .apple)

applePurchaseViewController.getTotalPrice() >> 200000

// 2. 윈도우 세트 선택
let windowPurchaseViewController = PurchaseViewController(selected: .window)

windowPurchaseViewController.getTotalPrice() >> 160000

언제 사용하면 좋을까?

객체 생성 과정을 추상화하여 코드의 유연성과 유지보수성을 높이고 결합도를 낮추는 데 큰 장점이 있다

클라이언트 단에서 구체적인 클래스를 모를 때
서로 연관된 여러 객체들을 함께 생성해야 할 때

주의 할 점

추상 팩토리 인터페이스에 연관되는 객체가 새로 추가 될 때마다 바꿔야 한다.
- e.g.) KeyboardMouseFactory에 ‘키링’이 추가 된 경우, AppleKeyboardMouseFactory, WindowKeyboardMouseFactory에 키링에 관련된 코드를 추가해야한다. → 번거로움

참고:

https://inpa.tistory.com/entry/GOF- -추상-팩토리Abstract-Factory-패턴-제대로-배워보자

https://refactoring.guru/ko/design-patterns/abstract-factory

[디자인 패턴] 팩토리 메서드 패턴

SamusesApple — Tue, 18 Jun 2024 11:39:56 +0900

객체 생성을 캡슐화 하여 ‘팩토리 클래스’를 통해 생성하도록 하는 생성 디자인 패턴

구조

Creator
- Product 객체를 생성하는 메서드 정의 (protocol / class)
Concrete Creator
- Concrete Product를 생성하기 위한 구체화 된 메서드를 가진 객체
Product
- Creator을 통해 생성될 수 있는 객체의 추상화 된 공통 Interface 선언 (protocol)
Concrete Product:
- Product에서 선언된 Interface가 구체화 된 실제 객체

출처: https://www.pentalog.com/blog/design-patterns/factory-method-design-pattern/

Swift 예제 코드

// Product
protocol Bread {
    var name: String { get }
}

// Concrete Product
struct CreamBread: Bread {
    var name: String = "크림빵"
}

struct SoboruBread: Bread {
    var name: String = "소보루빵"
}

// Creator
protocol BreadCreator {
    associatedtype Product: Bread
    
    func make() -> Product
}

// Concrete Creator
final class CreamBreadCreator: BreadCreator {
    typealias Product = CreamBread
    
    func make() -> CreamBread {
        CreamBread()
    }
}

// Concrete Creator
final class SoboruBreadCreator: BreadCreator {
    typealias Product = SoboruBread
    
    func make() -> SoboruBread {
        SoboruBread()
    }
}

언제 사용하면 좋을까?

객체 생성 과정을 추상화하여 코드의 유연성과 확장성을 높이는 데 큰 장점이 있다.

“다양한 구현체가 필요할 때” 음악 재생 앱에서 다양한 형태의 음악 파일을 재생해야 할 경우, 각 파일 형식에 맞는 재생기를 생성하는 데 팩토리 메서드 패턴을 사용하면 유연성이 높아질 수 있다.
“확장성이 중요한 경우” 애플리케이션의 요구 사항이 변경되어 새로운 객체 타입을 추가해야 할 때, 팩토리 메서드를 사용하면 기존 코드를 수정하지 않고도 새로운 클래스를 쉽게 추가할 수 있다.
“객체 생성 로직을 숨기고 싶을 때” 객체 생성에 복잡한 로직이나 조건이 필요한 경우, 이를 클라이언트로부터 숨기고 싶을 때 유용하다.

주의 할 점

“객체 생성 메서드의 다수 필요” 각 객체를 위한 팩토리 메서드를 각각 제공해야 합니다. 이는 단일 팩토리 클래스가 많은 수의 팩토리 메서드를 포함하게 되어, 클래스의 복잡도가 증가할 수 있다.
“코드의 복잡성 증가” 간단한 객체 생성에 팩토리 패턴을 적용할 경우, 오히려 코드의 이해와 유지보수를 어렵게 만들 수 있다.
“투머치 확장성과 유연성” 팩토리 패턴은 확장성과 유연성을 제공하지만, 때때로 이를 과도하게 추구하다 보면, 실제 필요 이상으로 복잡한 구조를 만들어낼 위험이 있다.

[iOS 16.4~] Inspector로 iOS 앱 내 띄운 웹뷰 디버깅 하기

SamusesApple — Wed, 27 Mar 2024 22:29:22 +0900

Inspector 사용 이유

앱 내에 띄운 WebView를 디버깅 할 때 Inspector를 사용한다.

해당 웹뷰가 띄워진 과정, 요청한 데이터 등을 확인할 수 있어 앱 내에서 웹뷰를 띄울 때 유용하게 사용된다.

예를 들면 필자는 네이버 로그인을 웹뷰로 구현하는 도중, 웹에서는 콜백 데이터를 넘겨주지만 앱에서는 해당 콜백 데이터를 받지 못하고 계속 흰색 빈 화면이 띄워지는 문제를 겪고 있었다. Xcode 디버깅으로는 웹 내 작업을 정확히 파악하기 힘들어 Inspector를 활용한 경험이 있다.

웹뷰 디버깅을 위한 Inspector 활성화 방법

iOS 16.4 버전부터는 WKWebView의 isInspectable 속성을 true로 설정해야 Inspector를 사용할 수 있다.

if #available(iOS 16.4, *) {
    webView.isInspectable = true
}

Safari 앱 > 설정 > 고급 > '웹 개발자를 위한 기능 보기' 체크

Inspector로 웹뷰 디버깅 방법

1. 띄우고자하는웹뷰.isInspectable = true 설정 (iOS 16.4 이후 부터) > 빌드하기 (시뮬레이터 or 실 디바이스)

2. Safari 앱 > '개발자용' > 빌드 된 시뮬레이터 선택 > 'm.naver.com' 선택 (빌드된 앱의 웹뷰에 띄워진 url)

3. Inspector로 디버깅이 필요한 부분 체크하기

(필자는 활용하여 Javascript 콜백 들어오는 url endpoint까지 도달했는지 + 웹뷰에서 API 요청이 정상적으로 들어갔는지 여부를 Inspector를 통해 확인 할 수 있었다.)

번외 +) HTTP 로 된 웹 띄우기 위한 설정

보안에 깐깐한 애플이기에 기본적으로 'https://웹주소'만 허용되어 있다.

따라서 http로 시작한 웹을 띄우기 위해서는 Info.plist에 key-value 설정을 추가해야한다.

1. App Transport Security Settings 딕셔너리 추가

2. App Transport Security Settings 딕셔너리에 Allow Arbitrary Loads를 YES 로 설정

[HIG] Launching - 실제 적용하여 리펙토링 하기(1)

SamusesApple — Wed, 15 Nov 2023 14:21:38 +0900

개요

저번주에 HIG 스터디에서 Launching 부분을 주제로 공부하였다.

스터디에서 출시한 앱 중 한 앱이 ‘앱을 처음으로 설치 → 실행’ 경우 사용자 정보를 요구한 것이 떠올라 이를 회고하고 리펙토링 하기로 했다.

스터디 내용

리펙토링 계획

우선, 해당 앱은 MVC 패턴, CoreData, Podfile, SPM등의 외부 라이브러리가 전혀 들어가있지 않은 상태이다. (심지어 네트워킹도 URLSession으로 함)

정보를 요청하는 화면 제거하기
MainVC에서 유저의 이름 부분을 터치 가능하도록 하기
- 유저 정보 없을 시에, "User"를 이름 대신 노출
- 터치시, 이름 등록 및 수정 하는 얼럿창 노출
지역을 나타내는 글자 옆에 버튼 추가하기
- 기본 날씨 제공 지역은 '서울'로 설정하기
- 버튼 터치시 CLLocation으로부터 현재 위치 좌표 받기
- 새로 받은 위치 좌표로 날씨 정보 요청하기

리펙토링 시작

이 글에서는 하단의 2가지 내용을 다룰 것이다.

정보를 요청하는 화면 제거하기
MainVC에서 유저의 이름 부분을 터치 가능하도록 하기

1. 정보를 요청하는 화면 제거하기

파일 제거
유저 이름을 최초에는 "User"로 임의 설정하기
CoreData에 저장된 지역 데이터가 없을 경우 네트워킹을 요청할 때 default 지역으로 '서울'의 데이터를 보여주도록 하기

1. 유저 정보 유무에 따라 화면 다르게 세팅하기

2. default 지역을 "Seoul" 로 세팅하도록 변경 /  앱 최초 설치 후의 모습

2. MainVC에서 유저의 이름 부분을 터치 가능하도록 하기

유저 이름이 표시된 label에 TabGestureRecognizer 추가하기
label이 탭 된 경우 이름을 변경할 수 있는 얼럿창 띄우기
얼럿창의 확인 버튼이 눌리면 CoreData에 변경된 이름 반영 및 view 다시 그리기

1. label에 제스처 추가

2. CoreData에 유저 이름 없을 경우 -> 생성(Create) / 있는 경우 -> 수정(Update)

시연 영상

[정보처리기사] 2. 재공학

SamusesApple — Thu, 9 Nov 2023 14:55:46 +0900

1. 재공학

1-1) 소프트웨어 재공학(Software Reengineering)의 개념

“기존의 시스템을 변경 혹은 재구조화 해서 사용하자.”

소프트웨어 위기를 유지보수의 생산성으로 해결하려는 방법을 뜻함

1-2) 재공학의 장점, 목표, 과정

장점
- 개발 시간 및 비용 감소
- 품질 향상 (기존에 존재하는 것을 다시 만든 것이니까)
- 신뢰성 향상 (기존에 사용했기 때문에 검증됨)
- 구축 방법에 대한 지식의 공유, 프로젝트 실패 위험 감소
목표
- 최우선 목표는 소프트웨어 유지보수성 향상이다.
- 복잡한 시스템을 다루는 방법 구현, 다른 뷰의 생성, 잃어버린 정보 복구 및 제거
- 재사용을 수월하게 해서 소프트웨어의 수명을 연장시키자.
과정
- 분석(사용 가치 여부 분석) → 구성(구조 리펙토링) → 역공학(기존에 있는 것을 뜯어보기) → 이식(실제 필요한 곳에 적용시키기)

2. 역공학

소프트웨어를 분석하여 소프트웨어 개발 과정, 데이터 처리 과정을 설명하는 설계 정보를 재문서화 하는 것

3. CASE

Computer Aided Software Engineering의 약자, 소프트웨어 개발의 자동화 도구

3-1) CASE가 제공하는 기능

개발을 신속하게 할 수 있음, 오류 수정이 쉬움 → 소프트웨어 품질 향상됨
소프트웨어 생명주기의 전체 단계를 연결해주고 자동화 및 통합 도구를 제공함
소프트웨어 시스템의 문서화 및 명세화를 위한 그래픽 기능 제공
소프트웨어 개발 단계 표준화 기할 수 있음, 자료 흐름도 작성 기능 제공
모델들 사이의 모순 검사 기능 제공
원천 기술
- 구조적 기법
- 프로토타이핑 기술
- 정보 저장소 기술

3-2) CASE 사용의 장점

기간 단축, 비용 감소 → 생산성 향상
소프트웨어 설계, 구현, 유지보수를 모두 관리할 수 있는 문서화 도구

3-3) CASE의 분류

상위 CASE
- 요구 분석 및 설계 단계 지원
하위 CASE
- 소스 코드 작성, 테스트, 문서화 과정 지원
통합 CASE
- 소프트웨어 개발 주기 전체 과정 지원

3-4) 요구사항 분석을 위한 CASE 도구

SADT (Structured Analysis and Design Technique)
- 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해 사용되어 온 구조적 분석 및 설계 도구
- SoftTech사에서 개발함
- 구조적 요구분석을 위한 블록 다이어그램을 채택한 자동화 도구