close
프로필 배경
프로필 로고

DK308C

TIL · 2023. 8. 29. fullscreen 넓게보기

[SeSAC] August 28, 2023

목차

✔︎ 오늘의 정리

  • Main 스토리보드 제거하기
  • 뷰 전환 시 nil이 나오는 경우
  • codebase ContentHugging, ContentCompressionResistance
  • lazy weak var

 

 

 

Main 스토리보드 제거하기

저번 주 TIL에 적었던 것 같은데 생각해 보니 올린 거엔 없길래,,, 아 날린 애 중 하나구나 싶었다

암튼!!

이제 스토리보드는 사용하지 않으니 제거해 보려고 한다.

굳이 스토리보드를 남겨두어 빈 스토리보드가 컴파일되는 시간을 줄 필요 없으니까!! (시간낭비임...)

하지만 스토리보드를 제거한 이후에 

스토리보드를 제거한 이후 해 줄 일은 다음과 같다.

  • info.plist에서 메인 스토리보드 설정 제거하기
  • target - buildSetting에서 스토리보드 설정 제거하기
  • initail View 설정해 주기

 

먼저, info.plist에서 메인 스토리보드 설정 제거해 주자.

etc-image-0

요 설정을 아예 지워주면 댄다!!

 

 

 

 

 

 

etc-image-1

이후 target - buildSetting에서 스토리보드 설정 제거해 주면 된다.

찾기에는 넘 시간이 걸려서 항상 Main을 검색해서 지우게 대는 거 같다

 

 

 

 

이후, SceneDelegate에서 inital View를 설정해 주면 된다.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?


    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        // Use this method to optionally configure and attach the UIWindow `window` to the provided UIWindowScene `scene`.
        // If using a storyboard, the `window` property will automatically be initialized and attached to the scene.
        // This delegate does not imply the connecting scene or session are new (see `application:configurationForConnectingSceneSession` instead).
        
        guard let scene = (scene as? UIWindowScene) else { return }
        window = UIWindow(windowScene: scene)
        let vc = AddViewController()
        window?.rootViewController = UINavigationController(rootViewController: vc)
        window?.makeKeyAndVisible()
    }
    
    ... ...
    
 }

이런 식으로!

 

 

 

 

 

 

 

 

 

뷰 전환 시 nil이 나오는 오류

etc-image-2

Thread 1: Fatal error: Unexpectedly found nil while implicitly unwrapping an Optional value

 

스토리보드로 작성한 뷰컨트롤러에 코드베이스처럼 화면 전환을 하려고 했을 때 발생한다. 

 

코드베이스 화면 전환은 vc를 선언하고 해당 변수에 뷰컨트롤러 인스턴스를 선언해 준 뒤에 그 뷰컨을 불러오는 것만으로도 화면 전환이 된다.

        let vc = OnboardingViewController()
            
        navigationController?.pushViewController(vc, animated: true)

 

 

다만, 스토리보드는 

        guard let vc = storyboard?.instantiateViewController(withIdentifier: "DetailTableViewController") as? DetailTableViewController else { return }
       
        navigationController?.pushViewController(vc, animated: true)

요런 식으로 써줘야 하는 걸 까묵었다 ㅋㅋ

 

 

 

 

 

 

 

 

 

 

 

 

 

 

codebase Content Hugging, Content Compression Resistance

레이아웃을 잡다 보면, 레이블에 작성되어 있는 양에 따라 칸 길이를 조절해 주고 싶을 때가 있을 것이다. 

그러려면 해당 view의 본질적인 크기를 아는 것이 중요하다!

이 본질적인 크기를 Intrinsic Content Size라고 하며, 요 크기에 대해서는 추후 정리할 때 hugging과 compression Resistance를 같이 정리해서 올려보겟다 ^_^ 일단은 우리는 본질적인 크기를 알고 있어야 뷰의 레이아웃을 제대로 잡아줄 수 있고!! 그 우선 순위까지 정해줄 수 있는 것이다.

서론이 길었다! 레이아웃을 모두 설정하고 나서도 공간이 남을 때, 본질적인 크기에 대해서 우선 순위를 설정해 주는 것을 Content Hugging, Content Compression Resistance라고 한다.

 

근데 그러면 각각은 무슨 차이일까?

 

 

요약하자면 다음과 같다.

  • content Hugging: 숫자가 크면 본질적인 크기만큼 작아져 줄게~~
    • 공간이 남으면 그 크기는 숫자가 작은 애가 차지할게!
  • content Compression Resistance: 숫자가 크면 클수록 나도 커질게 ㅇㅇ
    • 정확히는, 컨텐츠의 양만큼 내 크기를 유지하겠다는 뜻이다.

 

 

 

codebase 기반에서, 그 수치는 아래와 같다.

+-------------------------+---------------+------------------------------+
|         Object          | Hugging (H,V) | Compression Resistance (H,V) |
+-------------------------+---------------+------------------------------+
| UIActivityIndicatorView | 750,750       | 750,750                      |
| UIButton                | 250,250       | 750,750                      |
| UIDatePicker            | 250,250       | 750,750                      |
| UIImageView             | 251,251       | 750,750                      |
| UILabel                 | 251,251       | 750,750                      |
| UIPageControl           | 250,250       | 750,750                      |
| UIPickerView            | 250,250       | 750,750                      |
| UIProgressView          | 250,750       | 750,750                      |
| UIScrollView            | 250,250       | 750,750                      |
| UISearchBar             | 250,250       | 750,750                      |
| UISegmentedControl      | 250,250       | 750,750                      |
| UISlider                | 250,250       | 750,750                      |
| UIStepper               | 750,750       | 750,750                      |
| UISwitch                | 750,750       | 750,750                      |
| UITabBar                | 250,250       | 750,750                      |
| UITextField             | 250,250       | 750,750                      |
| UITextView              | 250,250       | 750,750                      |
| UIToolbar               | 250,250       | 750,750                      |
| UIView                  | 250,250       | 750,750                      |
+-------------------------+---------------+------------------------------+

https://stackoverflow.com/questions/36924093/what-are-the-default-auto-layout-content-hugging-and-content-compression-resista

 

 

 

 

 

ContentHugging

etc-image-3
etc-image-4
etc-image-5

위 숫자들은 각 label의 각 contentHugging을 말한다. 위에서 말했던대로, 숫자가 크면 클수록 본질적인 크기만큼 작아진다!

레이블의 본질적인 크기는 보여주는 text 자체니까 고만큼만 작아지는 것이다.

 

 

 

 

ContentCompressionResistance

etc-image-6
etc-image-7

Content Compression Resistance는 Content hugging을 설정하고 나서 추가적으로 설정해 주면 좋다.

빈 공간을 메꾸고 있다가 나 이만큼 작아지면 안 되고 최소 공간 확보해야 되지 않을까?! 하고 자기 공간을 완전히 확보한 뒤에 옆의 label을 ...으로 만들어 버린다.

 

위 사진에서 보면, hugging prioity는 빨간색 레이블이 크기에 노란색이 나머지 공간을 모두 차지하고 있다. 또, content Compression Resistance Priority의 경우에도 빨간색이 커서 본래의 텍스트가 줄어들지 않고 모두 보이고 있다.

 

만약에 hugging priority가 빨간색이 크고, content compression Resistance priority는 작다면 어떻게 될까?

 

 

etc-image-8

^_^ ......

이런 식으로 완전 찌그러지게 된다.

노란색이 추가적으로 공간을 차지하고, 노란색이 추가적으로 자신의 텍스트를 유지할 우선순위마저 높으니 빨간색이 설 자리를 잃은 것이다,,

 

 

 

근데 갑자기 요 얘기가 왜 나오냐고?!

 

etc-image-9

사유: 얘 때문이다.

왼쪽 라벨에는 기존 title이 들어가도록 했고, 오른쪽 라벨에는 originalTitle이 들어가도록 설정하여 각각 hugging과 compression Resistance를 잡아주었다.

근데 막상 코드로 잡으려고 하니 어떻게 잡아야 할지가 넘 막막햇는데

해 보니까 별거 없더라

 

 

    titleLabel.setContentCompressionResistancePriority(UILayoutPriority(rawValue: Float(751)), for: .horizontal)
    titleLabel.setContentHuggingPriority(UILayoutPriority(rawValue: Float(250)), for: .horizontal)

이런 식으루 잡아줬다.

일단, 나는 하나를 기준으로 잡고서 놔두고 다른 하나의 값을 바꾸어 조정해 주었다. (그러면 적절하게 CompressionResistance와 hugging 모두 조절이 가능하니까!

근데 막상 하고보니 둘 중 하나만 뜨는 게 더 예버서 걍 if else문으로 처리해줬다...

 

 

 

 

 

 

 

 

 

 

 

 

lazy weak var

둘이 같이 썼을 때 컴파일 오류가 난다. 왜 그럴까?!

나중에 lazy에 대해서 조금 더 공부하고 게시글을 작성할 예정이지만, 찾아본 게 흥미로워서 TIL에 같이 적어두려고 한다. 

 

`lazy` tells Swift that you don't want your variable created until the first time you access it, but once it is created, you want to keep it indefinitely for future reference, while
`weak` tells Swift that you don't want your variable to be the last link that keeps your variable from being deallocated, which works against the "keep indefinitely" goal of lazy variables.

원문의 출처는 여기! https://stackoverflow.com/questions/38171933/swift-weak-lazy-variable-wont-compile

 

 

결론부터 말하자면, 둘은 같이 사용할 수 없기 때문이다!

애초에 사용하는 용도가 아예 다른 둘을 같이 사용하려고 하니 나는 오류이다.

 

lazy는 지연 저장 프로퍼티로, 해당 변수가 사용되기 전까지 메모리에 할당되지 않다가 사용하는 순간 메모리에 해당 변수를 저장하여 사용할 때마다 그 변수를 참조하려고 한다.

반면, weak는 해당 인스턴스의 주솟값만을 가지고 있는 포인터의 개념으로, weak keyword를 사용하게 된다면 해당 변수의 Reference를 카운팅하지 않겠다는 뜻이 된다. (실제로 release와 retain이 모두 일어나지 않는다!!) weak으로 선언한 객체에 대해서 다른 변수가 강한 참조를 가지지 않는다면 해당 객체는 사라진다.

 

어라? 뭔가 각자의 개념만 보아도 완전 다른 친구인 걸 알 수 있다.

lazy는 사용하기 전까지는 메모리에 존재하지 않다가(RC: 0) 사용하게 되면 프로그램이 종료되기 전까지 RC가 1로 유지된다.

그에 반해 weak은 처음부터 끝까지 RC를 올리지 않겠다는 선언이 아닌가!!

lazy와 weak을 같이 사용하는 것은 lazy의 쓰임에도, weak의 쓰임에도 위배되기 때문에 같이 사용할 수 없다고 못을 박아 놓았다.

 

먼가 weak과 lazy를 좀 더 상세하게 정리해서 나중에 게시글 하나로 따로 올리고 싶당 ㅋㅋ

 

 

 

 

 

 

하~~~~~ 아니 어제부터 진짜 삽질삽질삽질햇는데

k님이 순식간에 다 해결해주셧다...

왜케 나는 만들어놓고 부르지를 않는걸까

왜배웟던건데도헷갈리지!??!!?!

그래도다행인건 복습을.. 그럭저럭? 잘? 해놓은 게 아닐까??? 하는 생각이 실쩍 든다는 것이다

꽤 수월하게 뭔가를 맹그는 거 같고... 조금 익숙해진 거 같기도 하고... ㅋㅋ

근데 벌써 두 달인 걸 생각하면 아니!!!!!! 더해야지!!!!!!!!! 싶은 맘이 들어서 스스로를 몰아치게댄다

하

아침에일어나는건왜케힘들까

잠자는건왜케행복할까

맘먹는건일케힘든데 왜 하면 또 잼써서 잠두안자고붙잡고잇게대는가...................

 

진짜자야겟다...

 

'TIL' 카테고리의 다른 글

[SeSAC] September 1, 2023  (0) 2023.09.02
[SeSAC] August 29, 2023  (2) 2023.08.30
[SeSAC] August 27, 2023  (1) 2023.08.28
[SeSAC] August 21, 2023  (2) 2023.08.22
[SeSAC] August 19, 2023  (4) 2023.08.21
TIL 관련 글
더 보기

티스토리툴바