[ios] 아이폰 만랩을 향해서 – 2 중간 점검

내가 부족한 것이 무엇인지 목록으로 정리한다.

  1. 기초를 다진 뒤에
  2. UI 부분 신기술, 노하우를 쌓고
  3. 아키텍쳐를 고민하면서
  4. 틈틈히 xCode의 유용한 부분을 익힌다.
  5. 신기술은 필요하면 공부하고
  6. 강의 저서활동을 위해서 공부한 내용은 반드시 글로 다듬어 남긴다.

잔여 목표

기초 다지기

Back to the basic!!!!

NSOperation

UI

Auto-layuout,intrinsic content size, class-based layouts  만랩 찍기(2015.11.06 완료)

self sizing table view cells

NavigationBar, Custom BarButton Item, Backbutton “title” 항상 나오지 않도록 하는 방법은?

UIViewController Navigation technique(modify mutable navitaionController.viewControllers)

StackVC, SplitVC 사용 방법 익히기.

GestureRecognizer Interface Builder 에서 사용하는 방법 익히기 (code로 하는건 쉽지)

아키텍쳐

framework of Managing object’s Life Cycle (like spring bean container)

Open source code 분석 & Best Practice가 될만한 코드 패턴 배우기.

TDD, 코드 퀄리티

테스트 자동화 with os-x server with xcode’s bot

UITest

정적 결함 분석 & Quality Assurance

xCode

xcode 설정 -> build phase 분리하기

xcode build -> ad-hoc으로 배포하기

xcode 테스트 자동화 -> Source Code, UI Test 자동화

StoryBoard -> 참조(스토리보드가 너무 무거워 지는 이슈가 있어서 xcode7부터 스토리보드 reference가 도입됨)

신기술

iWatch OS 2

tvOS

OS-X

Swift2

끝판왕

강의 & 저서 활동. (여기까지 가는데 얼마나 걸릴까?)

[ios] 아이폰 만랩을 향해서 – 1 목표 설정

Advertisements

[ios] 아이폰 만랩을 향해서 – 1 목표 설정

아이폰 개발 만랩으로 가는 길…

자 여행을 떠나보자!

1. Pro iOS Continuous Integration 책 마스터 & 블로깅 & 연습

2. Install Multi-version apps

3. Localization app name.

4. Crash Report 수집 설정(plcrashreporter????)

5. TDD 연습

6. 테스트 자동화 with os-x server with xcode’s bot

7. UITest

8. 정적 결함 분석 & Quality Assurance

9. 빌드 배포 자동화.(dSYM, archive 파일 관리 for symbolicate, analyze crash log)

10. iWatch OS 2

11. OS-X 앱 개발

12. Swift2

13. framework of Managing object’s Life Cycle (like spring bean container)

14. 다양한 에러 사례 분석 & 트러블 슈팅 & 문제 해결

15. 중고급에서 고급으로 가는길…Back to the basic!!!!

16. Open source code 분석 & Best Practice가 될만한 코드 패턴 정립.

17. 강의 & 저서 활동.(여기까지 가는데 얼마나 걸릴까?)

[ios] 아이폰 만랩을 향해서 – 2 중간 점검

[ios] method naming guide

액션 이름 짓기

link : http://stackoverflow.com/questions/7222013/naming-conventions-on-ibaction-functions

1. prefix를 사용하지 말아라

2. 액션 이름은 동사로 시작한다.

3. do, dose와 같은 이름을 사용하지 말아라, 그 이유는 조동사는 의미가 없기 때문이다.

4. 그리고 부사(adverbs), 형용사(adjective)를 동사 전에 사용하지 말아라.

5. 만약 값을 반환하는 함수라면 get이라는 이름이 필요하지 않다. 값을 반환하는 이름을 바로 사용해라.

– (NSSize)cellSize;

6. 키워드를 적절히 활용 해라.
– (void)sendAction:(SEL)aSelector to:(id)anObject forAllCells:(BOOL)flag

-> 아름다운 문장이다….그러나 Objective-C ….swift가 어느면에서는 더 좋은점이 있다(안좋은 점도 있다…IPC 메시지 전송이 안된다고 했던 기억이…)

7. Argument가 오기 전에 argument를 표현 할 수 있도록 메서드 네이밍을 작성한다.

– (id)viewWithTag:(int)aTag;

코딩 가이드 라인

(결국 Apple 문서를 읽어라 인데…apple  문서는 너무나 길다 ㅋㅋ)

http://stackoverflow.com/questions/8410602/objective-c-method-naming-convention

구글 코딩 스타일

http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml

[IOS] APNS 개발 설정 – (ios8)

* Apple Push Notification Service 가이드 (개념 이해)

https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html

* 인증서 설정 가이드 :

https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/ConfiguringPushNotifications/ConfiguringPushNotifications.html

* 앱 개발 가이드 :

https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/IPhoneOSClientImp.html

* stack_overflow : adHoc-build

http://stackoverflow.com/questions/3820525/adhoc-build-receives-no-push-notifications

* adHoc build for production push test

http://stackoverflow.com/questions/7208669/enabling-apple-push-notifications-for-ad-hoc-distribution-environment

* provider(3rd party message server : 직접 구현 하거나 이미 만들어진 플랫폼을 이용 (아마존 SNS)
https://github.com/notnoop/java-apns

ㅇ APNS Push size : 2 kbytes (ios8 layer), 256 bytes (Prior to ios8)
ㅇ 앱이 실행 되지 않을 때 : alert message, sound, badge 의 형태로 전달.
ㅇ 앱이 실행 중일  때 : NSDictionary 형태로 전달 된다.
ㅇ 전달되는 메시지 : JSON structured and consist of primitive type
ㅇ 메시지 포멧 작성 주의 : customer information(민감한 데이터 포함해서는 안된다)
ㅇ notification 전달 : 항상 전달이 보장 되는 것이 아니다.

Push Server response packet

Code Error : https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html

Table 5-1  Codes in error-response packet
Status code Description
0 No errors encountered
1 Processing error
2 Missing device token
3 Missing topic
4 Missing payload
5 Invalid token size
6 Invalid topic size
7 Invalid payload size
8 Invalid token
10 Shutdown

closed the connection

255 None (unknown)

* UX 고려

Apple 문서에 보면 notiifcation 남용은 사용자를 귀찮게 만든다고 되어 있다.
과도한 push는 사용자에게 가치를 주는 행위가 아니다.
꼭 필요한 정보, 그리고 빈도수가 높으면 요약해서 전송하는 push 서버를 구현 해야 한다.

Push Notification은 반드시 필요한 정보만을 제공해야 한다.

* APNS Tester (app store – for os-x)

스크린샷 2015-07-23 오전 12.27.50

[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 메타 정보는 스토리보드로 관리….

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

난 아직도 초보다…ㅜ_ㅜ