안녕하세요 유윤선입니다.

시작하세요 아이폰 4 프로그래밍 관련 공지입니다.

이 책은 본래 XCode 3.x 기반으로 저술됐는데

제가 XCode 4.x 기반으로 수정하는 과정에서

(XCode 4는 classes 같은 논리적인 그룹을 기본으로 사용하지 않아서)

일부 폴더 구조가 좀 바뀌었는데

이것 때문에 독자들이 조금 혼란스러워하는 것 같습니다.

그래서 오늘 중으로 제가 작업한 프로젝트 소스를 첨부해 드릴 테니

참고하시기 바랍니다.


아울러 다음과 같이 오탈자(또는 오류)를 수정합니다.

78 페이지. 인터페이스 빌드 -> 인터페이스의 개발

130 페이지. 그림 5-8에서 상단부터 좌 -> 우측순으로 1, 2, 3, 4, 5, 6 번호 표시가 누락돼 있습니다.

161 페이지. -(void) application:(UIApplication *)application didFinishLaunchingWithOptions: (NSDictionary *) launchOptions { 메서드에서

[self.window addSubView:switchViewController.view] <= 볼드체

170 페이지. (그림 6-19 참고) -> (그림 6-20 참고).

225 페이지 <UIPickerViewDataSource, UIPickerViewDelegate> { 부터 -(IBAction)spin; 까지 모두 볼드체

238 페이지 button.hidden = YES; 볼드체

274 페이지 그림 8-16. 그림에서는 Table View가 선택돼 있지만 실제로는 Table View Cell을 선택하는 게 맞음.

280 페이지 <UITableViewDataSource, UITableViewDelegate> 볼드체

293 페이지 #import "NSDictionary-MutableDeepCopy.h" 볼드체

307 페이지 [keyArray addObject:UITableViewIndexSearch]; 볼드체

345 페이지

그런 후에는 선언한 문자열을 릴리스하고 셀을 반환한다.

[rowTitle release];

return cell;

-> 그런 후에는 셀을 반환한다.

return cell; (원문의 오류가 번역 과정에서 그대로 반영됨)

375 페이지

@implementation President 볼드체 아님

421 페이지 cell.textLabel.text = [president objectForKey:@"name"]; 취소선 아님

431 페이지

이 함수는 조금 전 synthesize 명령문 바로 전, 파일 상단부에 추가해 보자 -> 이 함수는 조금 전 synthesize 명령 바로 다음, 파일 상단부에 추가하자.

433 페이지

self.languageButton = nil;

self.languagePopOverController = nil;

모두 볼드체

[languageButton release];

[languagePopoverController release];

모두 볼드체

472 페이지

[NSNotificationCenter defaultCenter] removeObserver:self]; 볼드체

494 페이지

@implementation FourLines 볼드체 아님

495 페이지

#define kFilename @"data.plist" 삭제

504 페이지

#define kFilename @"data.plist"

#define kFilename @"archive"

모두 삭제

505 페이지

NSString *filePath = [self dataFilePath]; 부터 sqlite3 *database; 바로 앞 괄호까지 모두 삭제

564 페이지

[self rotateLabelDown]; 볼드체 아님

591 페이지

typedef enum{ 볼드체

647 페이지

UISwipeGestureRecognizer *vertical; 볼드체

675 페이지

<CLLocationManagerDelegate> 볼드체

691 페이지

[motionManager stopAccelerometerUpdates]; 볼드체

702 페이지

UIImageView *imageView; 볼드체

708 페이지

#define kUpdateInterval (1.0f/60.0f) 볼드체

709 페이지

#import <CoreMotion/CoreMotion.h> 볼드체

그 외에 책을 따라 하시다가 제대로 실행 안 되는 부분이 있으면

제 블로그 방명록에 남겨주시면 시간이 나는 대로 답변드리겠습니다.

불편을 드려 대단히 죄송합니다.

아울러  10장 433페이지에서 언어 버튼을 연속 탭할 경우 런타임 예외가 나는 코드는

- (IBAction)touchLanguageButton {

       

       if(self.languagePopoverController == nil)

       {

           LanguageListController *languageListController = [[LanguageListController alloc]

                                                            init];

           languageListController.detailViewController = self;

           UIPopoverController *poc = [[UIPopoverController alloc]

                                       initWithContentViewController:languageListController];

           [poc presentPopoverFromBarButtonItem:languageButton 

                       permittedArrowDirections:UIPopoverArrowDirectionAny 

                                       animated:YES];

           

           self.languagePopoverController = poc;

           [poc release];

           

           

           [languageListController release];

       }

       else

       {

           if ([self.languagePopoverController isPopoverVisible])

           {

               [languagePopoverController dismissPopoverAnimated:YES];

           }

           else

           {

               [languagePopoverController presentPopoverFromBarButtonItem:languageButton 

                           permittedArrowDirections:UIPopoverArrowDirectionAny 

                                           animated:YES];

           }

       }

}

처럼 수정하시면 예외가 나지 않습니다. 이 부분은 저자들도 그렇고 저도 그렇고

테스트하면서 미처 살펴보지 못했네요.

Beginning iPhone 4 Programming.zip

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by joshy21

1. 애플은 사용자 경험뿐 아니라 개발자 경험까지 고려해 API를 만들었다.

그에 반해 안드로이드는 개발자 경험은 전혀 별로 고려하지 않았고

사용자 경험마저 살리기 어렵게 만들었다.

2. 애플 SDK에서 스택 구조가 직관적이기는 하지만 좀 더 고수준으로 끌어올렸더라면

어떨가 하는 생각을 한다. 그에 반해 안드로이드의 인텐트와 액티비티는

uni-tasking을 프로그래밍적으로 잘 정의한 백미라 할 수 있다.

3. 전반적으로 안드로이드 프로그래밍은 파편화의 연속이다. 따라서 안드로이드 프로그래밍을

할 때는 기본 프로그래밍 요소 외에 파편화에 따른 예외 처리 및 코드 분기가 꼭 필요하다.

4. 안드로이드 구 버전 API도 좀 더 고수준으로 만들어준다면 어떨까 하는 생각을 한다.

아니면 새로운 API에서 하위 버전 호환성을 최대한 지원한다면 개발하기가 한결 쉬울 것 같다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by joshy21

스프링을 아는 개발자와

모르는 개발자가 있다.

스프링을 아는 개발자는 행복한 거고

모르는 개발자는 조금 불행한 거다.

-끝-

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by joshy21

요즘 개콘을 보면

마지막 봉숭아 학당 끝날 때

adios라고 한다.

그런데 이건 잘못된 표현이다.

adios는 a (to) + dios (신)이란 뜻으로

프랑스어의 adieu와 어원적으로나 의미적으로 같으며

'영원한 안녕'이란 뜻이다.

따라서 adios라고 하면

적어도 살아 생전에는 다시 보면 안 된다.

개콘처럼 매주 다시 볼 거면

스페인어로는 hasta luego나 hasta la proxima semana(또는 vez)라고 해야 한다.

아니면 프랑스어로는 Au revoir라든가 A bientot라고 하든가.

여튼 adios는 아니다ㅠ

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by joshy21

안드로이드 커스텀 컴포넌트를 만들 때는

Context context를 매개변수로 받는 기본 생성자 이외에

xml에서 태그로 정의해 컴포넌트를 선언할 수 있게

<ClassName>(Context context, AttributSet attrs) 생성자 또한 구현해야 한다.

아이폰 프로그래밍에서 nib 파일에 아카이빙된 객체가 초기화될 때 별도 메서드를 호출하는 것처럼

안드로이드에서도 Inflater를 통해 초기화되는 클래스는 이 클래스 생성자를 통해서만 초기화되고

이 클래스 생성자를 명시적으로 구현하지 않으면 예외가 발생한다.

물론 커스텀 컴포넌트를 직접 코드로 초기화한다면 저 생성자를 호출하지 않겠지만

컴포넌트를 어떻게 사용할지 모르므로 항상 두 생성자 메서드를 명시적으로 구현하는

습관을 들이는 게 좋다.

이런 식으로 커스텀 컴포넌트를 레이아웃 xml에서 사용하면 컴포넌트를 매번 재사용하기가 쉽고

고유 아이디를 매번 일일이 생각하지 않아도 되므로 편하며

컴포넌트 단위로 기능을 캡슐화할 수 있어서 좋다.

이 경우 커스텀 컴포넌트가 컨테이너라면 내부에 있는 컴포넌트의 참조는

커스텀 컨테이너의 공개 API를 통해 (필요한 것들만) 접근할 수 있게 해주면 된다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by joshy21

예전에, 그러니까 한 2001년 쯤일 테니 한 10년쯤 됐을 것이다.

앙드레 미셸이 작성한 코드의 프랑스어 주석을 본 이래 처음으로

이곳에서 프랑스어로 된 코드 관련 설명을 본 것 같다.

내용은 AIR에서 SQLite를 조회할 때 테이블 조인을 할 경우

VO로 어떻게 매핑할지에 대한 건데

해결책은 VO 안에 또 다른 VO를 속성으로 정의한 후

조인한 키에 따라 describeType을 통해 클래스 정보를 추출하고 데이터를 매핑한 후

라벨 함수를 활용해 내부 VO의 값을 반환하는 것이다.

(이해는 되지만... 이게 최선이라는 생각은 안 든다. 유감스럽게도...)

그러고 보니 나도 안드로이드 SQL 자동 매핑 툴을 만들면서 테이블 조인 조건을

생각하지 않은 게 문뜩 떠올랐다. 하지만 아직은 테이블 조인을 할 일도 없고

한다 하더라도 어차피 커스텀 VO를 UI에 매핑하는 곳이 아닌 이상 모두 인터페이스 타입으로

받고 있으므로 아직까지는 현 상태대로 써도 될 것 같다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by joshy21

이게 전부는 아닐지언정

이 정도는 해야 제대로 된 거 아닌가 싶다.

1. 비밀번호/개인 정보 암호화

당연하다. 그런데 너무 안 지킨다. 최근 일어난 일련의 보안 침해 사례를 가만히 보면서

'과연 비밀번호를 암호화했을까?' 하는 고민에 빠졌다.

이에 대해서는 내가 내부 개발자도 아니고 공식적인 입장을 들은 바도 없으므로

그냥 '과연? 과연?'이라고 추측만 할 뿐이지만

만약 비밀번호나 개인 정보를 암호화하지 않았다면

정말 안타까운 일이 아닐 수 없다.

물론 가만히 있는 사이트를 먼저 침해한 해커가 나쁘다.

그런데 웹 사이트도 만일의 사태에 항상 대비할 책임은 있다.

기본적인 비밀번호, 개인 정보까지 암호화를 하지 않았다면

정말 유감이다.

2. 비밀번호 솔트

이건 선택 항목이지만 필수처럼 생각하고 꼭 적용하기를 바란다.

비밀번호 솔트를 적용하면 레인보우 테이블 같은 공격을 피할 수 있다.

예를 들어 해커가 충분히 많은 값을 입력해 레인보우 테이블 공격을 하면

비밀번호 암호화를 했다 하더라도 비밀번호를 역추적할 수 있다.

하지만 여기에 소금(salt)을 뿌려서 해커를 혼란케 하면

레인보우 테이블 공격조차도 무력화할 수 있다.

즉, 자동화된 프로세스만으로는 비밀번호를 알아내 사용자 계정에 침입하기가

몹시 어려워지는 것이다.

3. 보안 프로토콜의 사용

익명 접근이 가능한 곳에서는 http 프로토콜을 사용하더라도 상관없지만

일단 로그인한 후에는 https 프로토콜을 사용해 패킷을 암호화하는 게 좋다.

4.  사용자 크리덴셜 요청

사용자 인증 정보를 제공해 한번 로그인하면 쿠키가 만료될 때까지

자동 로그인을 지원하는 사이트라 하더라도

주요 개인 정보에 접근해야 할 때는 꼭 별도로 로그인을 거치게 하는 게 좋다.

예를 들어 온라인 쇼핑 사이트라면 카트에 담는 것까지는 익명으로 또는

자동 로그인 인증 정보를 바탕으로 얼마든지 지원할 수 있지만

실제 구매 시에는 항상 로그인을 명시적으로 요청하는 게 좋다. 이렇게 하지 않으면

중간자 공격 등을 통해 다른 사용자 계정에 침입한 해커가

사용자의 주요 개인 정보를 마음대로 사용해 이를테면

값 비싼 물품을 웹사이트에서 구매하거나

개인 정보를 빼갈 수 있다.

5. 웹 사이트의 권한 영역을 세분화한다

4번과도 일맥상통하는 얘기인데 이를테면 guest/user/purchaser/admin 등으로

웹 사이트의 권한 영역을 세분화하고 각 권한 역할에 따라 보안을 강화한다.

6. 기왕이면 보안 프레임워크를 활용한다.

보안 프레임워크를 활용하지 않으면 전체 사이트에 보안을 적용하기가 몹시 어렵다.

예를 들어 한 곳에는 보안을 제대로 적용했지만 다른 곳에서는 특정 보안 요소를 빼먹기 일쑤고

이를 검증하기도 쉽지 않으며, 더불어 똑같은 보안 요소를

적용하기 위한 코드를 반복적으로 적용(boilerplate 코드의 양산)해야 한다.

따라서 가능하다면 스프링 시큐리티 같은 프레임워크를 사용해 사이트 전체에 보안을

일관되게 적용하는 게 좋다.

7. 지금까지의 내용은 모두 내가 번역한 스프링 시큐리티 3 책 (위키북스)에 나오는 내용들이다.

-끝-

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by joshy21

가끔 난

번역이 감정 노동이 아닌가 싶다.

본래 번역을 끝내고 나면

다른 저자나 역자들이 그렇듯이

책을 다시 안 펼쳐보는 나로서는

어떤 책은 가끔...

이대로 보내버리기엔 너무 좋은데...

하고 나 혼자 계속 읽어버리는 경우가 있다.

하지만 헤어질 때를 알아야 하기에

가끔은 헤어지기 싫어도 책을 손에서 놓아야 한다...

지금도 2권의 책을

손에서 내려 놓으려 한다...

언젠가 또 만날 날이 있겠지+_+

Je me suis bien amusé! Au revoir et merci :)

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by joshy21

사람들은 합성이 더 좋은 거라는 걸

잘 이해하지 못한다.

난 합성이 왜 더 좋은지 이해하지 못하는 사람들을

이해하지 못하겠다.

합성은 상속으로부터 자유롭기 때문에

OOP 원칙에 더 잘 부합된다.

상속은 상속하는 순간

제명이 됐어요


상속 계층구조에 묶여버리기 때문에

아무리 상위 클래스의 메서드를 스텁 함수로 만든다 하더라도

상위 클래스의 로직으로부터 완전히 자유로울 수 없다.

하지만 합성은 설령 상위 클래스가 바뀌더라도

얼마든지 자유롭게 구현할 수 있다.


사실 플렉스 개발자 중에 TextInput 컴포넌트가 실제로는

상속이 아니라 합성으로 구현한 것임을 제대로 알고 있는 개발자가 얼마나 될까?

사실 상속으로 치자면 TextInput 컴포넌트는 그냥 UIComponent다.

그런데 합성을 통해 마치, "훗, 난 처음부터 텍스트 인풋이었다고"라고 말하는 것처럼

누가 보기에도 텍스트 인풋처럼 돼 버렸다(심지어 클래스명까지...)

이처럼 합성은 마법 같은 힘이 있다.

원하는 요소를 모아서 내가 원하는 대로 버무릴 수 있고

내부에서 사용(합성)할 다른 컴포넌트의 속성을 커스텀 컴포넌트에 정의하고

커스텀 컴포넌트에서 내부 클래스 인스턴스로 속성을 잘 전달해주기만 하면

내부 컴포넌트를 얼마든지 부려 쓸 수 있다.

이렇게 되면 상속으로 인한 상위 클래스와의 결합도를 줄일 수 있고

필요한 로직을 언제든 추가하거나 뺄 수 있다.

또 DI나 ioC를 통해 특정 기능을 수행하는 컴포넌트를 동적으로 주입해

기능을 추가하기도 훨씬 쉽다.

예를 들어 안드로이드의 DatePickerDialog도 사실은 상속으로 치자면 AlertDialog지만

내부적으로 private final DatePicker mDatePicker;를 선언해


"내가 바로 데이트피커 다이알로그다"하고 광고하고 있다.


이는 마치 인터페이스와도 닮아 있다.


한 클래스가 다중 클래스를 상속할 수는 없지만 다중 인터페이스를 구현할 수는


있는 것처럼 한 클래스는 여러 내부 클래스 인스턴스를 합성해


마치 여러 기능을 갖춘 클래스마냥 (마치 여러 클래스를 상속한 것처럼)


행동할 수 있다.


이런 사실을 잘 이해하면 얼마든지 AlertDialog를 상속해 또 다른 컴포넌트를


합성할 수 있다. 하지만 이런 사실이 잘 이해되지 않는다면


이해될 때까지 좀 더 공부할 것을 권장한다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by joshy21

오늘 외국 저자한테 메일을 보내는데

파일을 첨부한다고 하고는 깜박하고

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by joshy21