[Web] API character encoding

java 에서 API 통신할 때 꼭 인코딩을 확인하자.

인코딩 정보가 없으면 fiddler로 확인한뒤에 인코딩 정보를 명시하면 텍스트가 깨지는 것을 방지할 수 있다.


post.setHeader("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8");
post.setHeader("Accept-Language", "ko-KR,ko;q=0.8,en-US;q=0.6,en;q=0.4");
post.setHeader("Accept-Charset", "EUC-KR");

List urlParameters = new ArrayList();
post.setEntity(new UrlEncodedFormEntity(urlParameters, "euc-kr"));

요즘은 코딩하면서 논다….

[IOS] 코딩 가이드 & 시작 지점

무턱대고 아이폰을 개발한지 3주가 되었다.

1. 처음으로 되돌아 갔을 때 도움이 되는 문서 (어디서 부터 시작해야 할까 난감할 때)

https://developer.apple.com/library/ios/referencelibrary/GettingStarted/RoadMapiOS/WhereToGoFromHere.html#//apple_ref/doc/uid/TP40011343-CH12-SW1

2. 이건 개발하면서 뭔가 기준이 없어서 해매고 있을 때 코딩 가이드라인을 제시한 문서.

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html

정말 IOS 개발은 웹 개발보다 공부할게 많은 것 같다. ㅜ_ㅜ

web develop 4year VS IOS 3 weeks

[IOS] 아이폰 폰별 분기처리

아이폰을 이제 처음 입문한 새내기 입장에서 무엇이 좋고 무엇이 나쁜지는 아직 모른다.

많은 삽질 끝에 깨달음을 얻고 보다 효과적인 방법을 몸에 익히는 방법이 최선인것 같다.

답을 찾아가는 과정이 고통스럽다.

얼마전에 Storyboard, XIB, Code를 가지고 프로그래밍을 하는 것의 장단점에 대해 블로깅을 해보았는데 결론은 다음과 같다.

ㅇ storyboard : 복잡한 view controller 전환을 파악하는데 효과적이다.’
ㅇ XIB : View Template를 관리하는데 효과적이다.
ㅇ Code : View를 만드는 것을 코드로 관리하기 때문에 한눈에 파악하기 어렵다. (즉 해석하는데, 오래 걸린다)
대신 SVN 충돌이 났을 경우 StoryBoard나 XIB 파일보다는 복구하기 용이하다.
코드로 만들었기 때문에 상속에 유리하다.
자유도는 높지만 그만큼 시간과 노력이 필요하다.

그럼 기계 타입별로 관리하기 위해서는 코드가 최선일까?
아직까지 아이폰 디바이스 단편화가 안드로이드만큼 많은 것은 아니다…그래서 이런 여유있는 답변이 나오는 것이 아닐까?
-> http://stackoverflow.com/questions/12696242/how-to-switch-to-different-storyboard-for-iphone-5

내용을 요약하면 iphone4, iphone5 즉 버전별로 스토리보드를 따로 만들면 된다. 가 요지인데….
장점은 각 디바이스별 디자인이 따로 따로 나온 경우 스토리보드를 이용하여 손쉽게 UI를 개발할 수 있다는 것이다.
그리고 각 디바이스별로 스토리보드를 분기처리하여 로드하면 View 정보를 분리 할 수 있다.

로직은 코드로 관리
view 메타 정보는 스토리보드로 관리….

아직까지 반박할 수 없고 훌륭한 답변이다.

난 아직도 초보다…ㅜ_ㅜ

[IOS] code vs nib vs storyboard

원본글 : -> http://www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code

요즘은 내공이 생기니 이런 기준으로 프로그래밍을 하게 됩니다.

StoryBoard를 사용하여 ViewController의 전환을 이해 할 수 있도록 흐름을 설계 한다.

Template가 되는 View는 Nib를 사용하여 디자인 한다 : 많은 곳에서 재활용 될 수 있는 View

Code : 동적으로 변화하는 Graphic User Interface를 사용하여 디자인 하기 어려운 View는 Code로 작성한다. (웬만하면 지양한다)

StoryBoard의 네비게이션이 복잡한 경우 Segue를 쓰지 않고 코드로 작성한다.

[이전에 작성한 내용]

저도 소스 merge conflict 부분에서 공감 됩니다만 

아직 내공이 부족해서 모든 것에 대해 공감할 수 없었습니다.

ㅇ 후기 결론 : 

ㄴ> 결국 상황 수습 하려면 모두 다 할 줄 알아야 한다….;;;;

하단은 케이스별 용도, 잘못된 사용예, 장/단점에 대해 정리 해보았습니다.

ㅇ 본문 번역 요약 

ㅁ 스토리보드 

용도 : 

TableViewController 의 cell view를 프로토타이핑 할 때 유용하다.

여러가지 cell template은 부모 컨트롤러 안에서 디자인 할 수 있다.

static table 구현 가능.

잘못된 사용 예 : 

복잡한 레이아웃 구현 (코드가 최고)

NIB파일로 view 가 구현되었다면 storyboard로 구현할 필요가 없다.

장점 : 

전체적인 뷰 컨트롤러의 흐름을 파악하는데 용이하다. (프로토타입)

성능 부담이 없다. 오직 초기화 되는 View Controller만 생성. (성능)

단점 :

재사용성이 떨어진다. (copy paste하게 되면 storyboard에 bind된 IBAction, IBOutlet의 의존성이 그대로 카피되며 오류를 발생 시킨다.)

인터페이스 빌더 안에서 데이터가 어떻게 이동하는지 보기 어렵다.

View Controller 간에 이동할 때 prepareForSegue를 override하는데 이러한 구현 방식은 에러를 발생시키며 불필요한 코드를 만들어낸다.

예 ) 

- (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
    NSString *identifier = [segue identifier];
    if ([identifier isEqualToString@"segue_name_1"]) {
        MyViewController *vc = (MyViewController *) [segue destinationViewController];
        [vc setData:myData];
    } else if ([identifier isEqualToString@"segue_name_2"]) {
        ...
    } else if ...
}

ㅁ NIBs (인터페이스 빌더)

용도 : 

Modal View 디자인

간단한 로그인과 등록화면

설정

팝업 윈도우

재사용가능한 뷰 템플릿

재사용 가능한 테이블 뷰 cell 템플릿

잘못된 사용 : 

view 가 동적으로 변하는 구간. (레이아웃이 컨텐츠 종류별로 많이 바뀌는 경우)

interface builder로 디자인하기 어려운 뷰

View Controller flow가 복잡한 경우 (story board)를 사용한다.

장점 : 

재사용성

여러 클래스에 공유할 수 있다.

TTLoginView, TTSignupView 

거의 비슷한데 약간의 문구 내용만 다른 경우 view template 를 공유 해서 사용 가능.

NIB는 lazy load

ㅁ 코드 UI 구현

용도 : 

동적인 layout

View 특수 효과

NIB나 Storyboard를 사용하면 복잡해지는 경우

잘못된 사용 : 

모든 상황은 코드로 해결 가능하다. 

장점 : 

보다 유연하게 Code level 에서 다루기 용이하다.

xml파일로 이뤄진 view 구조 안에서 무엇이 변경되었는데 merge conflict가 발생 했다면….문제 해결이 용이하지 않다.

(이유가 xml에 이루어진 view Controller, view 들의 Id가 알기 어려운 랜덤 문자로 이뤄져있기 때문입니다)

그런데 코드는 code만 보면 쉽게 해결 가능하다.

storyboard나 NIB 파일은 xml 을 parsing하는데 overhead가 있으며 결국 ui정보를 코드로 변환하는 작업이 있다.

재사용 가능성이 높다. 코드 레벨로 되어 있기 때문에 별도의 클래스로 분리한 뒤 상속이 용이하다.

단 과도한 상속과 override는 UI디자인이 어떻게 되어 있는지, 알기 어렵게 만든다.

단점 : 

프로토타이핑이 어렵다. 실행 해보기 전까지 레이아웃을 확인하기 어렵다.

리팩토링이 어렵다. (매직 넘버와 custom method는 디버깅을 어렵게 한다)

TODO : 개행과 들여쓰기 정리 할것

 

[IOS] 스토리보드 영문을 알기 어려운 오류 발생 시 대처 방법

정말로 view controller id를 storyboard에 지정 했는데도 불구하고 오류가 발행 하였다.

원인은 잘 모르겠으나 해결 방법은 ? ㅋㅋ

폰이나 시뮬레이터에서 빌드한 앱을 삭제하고 다시 돌리면

마법처럼 잘 돌아간다 ㅋㅋ

storyboard를 사용하게 되면 케이스별로 발생 할 수 있는 문제점에 대해 정리 해본다.

1. 다른 uiView 복사 할 때 발생 가능
IBOutlet과 연결 해줘야 할 필드가 존재하지 않는다. 라는 오류인데
다른 스토리보드에 ViewController와 바인딩 된 디자인 정보를 카피 했기 때문이다.
새로 지정한 ViewController 는 이전 컨트롤러와 달리 바인딩된 outlet, action 정보가 없기 때문에
우측 메뉴의 connection insepctor를 이용하여 outlet, action을 일단 청소하고 난 뒤에 작업을 시작한다.

2. view controller id를 찾을 수 없다고?
분명 storyboard에 있는 view controller의 속성에서 storyboard id를 지정 해주었는데 이런 문제가 발생한 경우는 빌드한 앱을 삭제한다.(시뮬레이터, 테스트 디바이스)
앱 삭제 후 다시 돌리면 마법과 같이 잘 돌아간다. ㅋ
앱을 삭제 후 다시 배포 하지 않는것 같다.

* 참고 링크
http://stackoverflow.com/questions/11653861/storyboard-doesnt-contain-a-view-controller-with-identifier
http://stackoverflow.com/questions/8295471/storyboard-doesnt-contain-a-view-controller-with-identifier