storyboardがコンフリクトした時のマージ手順メモ

storyboardがconflictした時のマージ手順メモ。
殆どここの通りGit-のブランチ機能-ブランチとマージの基本

<前提条件>
・masterと機能ブランチfooがある
・カレントディレクトリは機能ブランチfoo<やりたい事>
・masterの最新状態を機能ブランチfooにマージしたい
・conflictした箇所はfooの内容は破棄しmasterを生かしたい
※マージせずconflictする前に戻したいならgit reset --hard HEADで。参考:git-resetは結局何を戻すのか

<手順>
masterの変更をfooにマージ

git merge master

storyboardがconflictし自動マージが失敗する

warning: Cannot merge binary files:xxx/Base.lproj/MainStoryboard.storyboard (HEAD vs. master)
Auto-merging xxx/Base.lproj/MainStoryboard.storyboard
CONFLICT (content): Merge conflict in xxx/Base.lproj/MainStoryboard.storyboard

conflictが発生したxxx.storyboardをエディタで開くと以下のようになっている。
=======の上がローカルの変更、下がmasterの変更となる

<<<<<<< HEAD
xxxxx(ローカルの変更)
=======
yyyyy(リモートの変更)
>>>>>>> master

masterの変更を採用しローカルの変更を取り消したいので<<やHEAD、>>master等の行を削除

yyyyy(リモートの変更)

全ての箇所を同様に修正し保存するが、これだけではxcode上のCマークは消えない為conflictの解決を通知

git add xxx.storyboard

storyboardをaddでステージングしてもxcodeのGUIからpush、commitしようとすると、
マージ中のエラーとなったのでterminalからgit commitしてpushした。

fatal: cannot do a partial commit during a merge

<その他>
以下記事を参考に*.storyborad -crlf -diff -mergeを記載した.gitattributeを.gitと同階層に配置したが、
マージ時にHEADの状態が維持されずconflictしてしまった。理由が分かる人教えてください。
iOS開発でGitを利用する際のTips

AutoLayoutメモ

• IBで設定するIntrinsicSizeはPlaceholderを選択する事ができるが、実行時にそのサイズは反映されない

• Add Missing Constraintsは不要な制約も追加されるのでALを良く理解していないと扱いが難しい

• 上、左、幅、高さの制約のみをつけて行くと調整しやすい
• frame変更 > cmd+shift+=で制約を更新の繰り返しで調整していく
• Labelは高さを丁度良くにしないと上スペースができ、一つ上のUIとのTopSpaceが設定されてしまったり

Google Maps SDK for iOS 1.6.1が出てますね

GoogleMapsSDK for iOSの1.6.1が出ていた。以下はリリースノート。
https://developers.google.com/maps/documentation/ios/releases?hl=ja

1.6.1では以下の問題が修正されている様子。
・Resolved a memory leak involving vector tiles.
→メモリリークの修正

・Markers not immediately added to a GMSMapView no longer fail to appear when configured at a later point. (Issue 6092)
→マーカーをGMSMapViewにすぐ設定せず、後から設定しても表示されない問題の修正

GMSMapView/GMSPanoramaView will now continue to render while your application is resigned. (Issue 5546)
→ アプリがリサインされるときもレンダリングし続ける問題の修正（意味違うかも、汗）
※ちなみに1.6は1.6.1にリプレイスされているのでもう1.6.0はダウンロードできない。


1.6の機能
・32bit,64bitアーキテクチャのサポート
・GMSMapViewにズームの最小値、最大値の制限を追加
例) [mapView_ setMinZoom:<#(float)#> maxZoom:<#(float)#>]
・GMSTileLayerとGMSMarkerに透過プロパティを追加 0は完全に透明、1は不透過（デフォルトは1）
・GMSMapView上のCore Animationは、現在設定されるモデル値が必要となった（よくわからない）

AFNetworking 2.0 Migration Guideを読みながらメモ

AFNetworking 2.0 Migration Guideを脱線メモしながら意訳中です。

AFNetworking 2.0 Migration Guide

AFNetworking 2.0 is the next major release of AFNetworking, a delightful networking library for iOS & Mac OS X.
As a major release, following Semantic Versioning conventions, 2.0 introduces several API-breaking changes with its new architecture, which adds support for NSURLSession and introduces a new serialization-based approach to content negotiation.
This guide is provided in order to ease the transition of existing applications using AFNetworking 1.X to the latest APIs, as well as explain the design and structure of new and changed functionality.

AFNetworking 2.0はAFNetworkingの次のメジャーリリースで、
iOSとMac OS Xの為の快適なネットワーキングライブラリです。
メジャーリリースとして、セマンティックバージョン管理規則に従い、
2.0ではNSURLSessionのサポートと、コンテントネゴシエーションの為のSerialization-based approach等
新しいアーキテクチャを採用し、いくつかのAPI互換性に影響する変更を導入しました。

このガイドは又、新規かつ変更された機能の設計と構造を説明し、
AFNetworking 1.Xの最新APIを使用した既存アプリケーションの平易な移行の為に設けられました。

ここまでで自分の理解が浅いキーワード

コンテントネゴシエーション

• Apache公式 https://httpd.apache.org/docs/2.2/ja/content-negotiation.html
• http仕様RFC2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html

セマンティックバージョニング

• セマンティックバージョニング仕様書 http://semver.org/
• 上記の日本語訳 http://shijimiii.info/technical-memo/semver/

New Requirements: iOS 6, Mac OS X 10.8, & Xcode 5

AFNetworking 2.0 officially supports iOS 6+, Mac OS X 10.8+, and Xcode 5.
If you'd like to use AFNetworking in a project targeting a base SDK of iOS 5, or Mac OS X 10.7, use the latest tagged 1.x release. For iOS 4.3 and Mac OS X 10.6 support, use the latest tagged 0.10.x release.

AFNetworking2.0は正式にiOS6以降、Mac OS X10.8以降、そしてXcode5をサポートしています。
iOS5のBaseSDK、又はMac OS X 10.7をターゲットプロジェクトにAFNetworkingを使用したい場合は、
最新のタグ付けされた1.xのリリースを使用して下さい。
iOS4.3及びMac OS X 10.6のサポートについては、最新のタグ付け0.10.xリリースを使用して下さい。

Serialization

One of the most significant changes in AFNetworking 2.0 is its new architecture for content negotiation and serialization. Previously, response validation and serialization was delegated to AFHTTPRequestOperation and its subclasses, with content-specific logic scattered throughout implementations for setCompletionBlockWithSuccess:failure: and other properties. In 2.0, all of this logic is encapsulated in a serializer object that conforms to .

Both & are lightweight protocols, with a single method each:

AFNetworking2.0における最も重要な変化の一つは、
コンテントネゴシエーションとシリアル化のための新しいアーキテクチャです。
以前はレスポンスの検証とシリアル化はコンテンツ固有のロジックがsetCompletionBlockWithSuccessの実装に点在しAFHTTPRequestOperationとそのサブクラスに委譲されていました。
2.0では、このロジックのすべてがに準拠したシリアライザオブジェクトにカプセル化されます。

と はそれぞれ１つのメソッドを持つ軽量なプロトコルです。

- (NSURLRequest *)requestBySerializingRequest:(NSURLRequest *)request
                               withParameters:(NSDictionary *)parameters
                                        error:(NSError *__autoreleasing *)error

 (id)responseObjectForResponse:(NSURLResponse *)response
                           data:(NSData *)data
                          error:(NSError *__autoreleasing *)error

AFNetworking 2.0 comes with a base set of serializations for content types like JSON, XML, property lists, and images. Each of these serializers inherit from a common superclass, AFHTTPSerializer, which serves as a concrete implementation of both & , providing a default URL query string parameter serialization scheme and default headers for requests, and MIME type and status code validation for responses.

For requests with methods not included in HTTPMethodsEncodingParametersInURI, AFJSONSerializer will encode parameters as JSON in the HTTP body, setting the Content-Type header accordingly. Likewise, AFPropertyListSerializer will encode parameters and set the request header for plist content.

AFNetworking2.0は、JSON、XML、プロパティリスト、および画像等のコンテントタイプの為のシリアル化の基本セットが付属しています。
これらのシリアライザはと双方の具体的な実装となる共通のスーパークラス、AFHTTPSerializerから継承していて、
デフォルトのURLクエリ文字列パラメータのシリアル化スキームおよびリクエストに対するデフォルトヘッダー、そしてレスポンスに対するMIMEタイプとステータスコードの検証を提供します。

HTTPMethodsEncodingParametersInURIに含まれていないメソッドを持つ要求の場合、AFJSONSerializerに応じてContent-Typeヘッダを設定し、HTTPボディにJSONなどのパラメータをエンコードします。同様に、AFPropertyListSerializerはパラメータをエンコードし、plistコンテンツの要求ヘッダーを設定します。

AFHTTPRequestOperationManager and AFHTTPSessionManager both have requestSerializer and responseSerializer properties. AFHTTPRequestOperation adds a responseSerializer property as well, which makes it the preferred request operation class for requests of any content type, rather than being merely a superclass.

requestSerializer is responsible for adding authentication and other shared headers to requests created with -requestWithMethod:URLString:parameters:.

responseSerializer is responsible for serializing a response and its associated data into a response object, or generating an error if the response is invalid. Serialization occurs in the completion block of request operations and session tasks.

AFHTTPRequestOperationManagerとAFHTTPSessionManagerはrequestSerializerとresponseSerializerの両方のプロパティを持ち、
AFHTTPRequestOperationは単にスーパークラスであることより、むしろ任意のコンテンツタイプの要求の優先要求操作クラスとなり、同様にresponseSerializerプロパティを追加します。

requestSerializerにはrequestWithMethod:URLString:parametersによって生成されたリクエストの共有ヘッダと認証を追加する為の責任があります。

responseSerializerにはレスポンスとレスポンスオブジェクト内のそれに関連したデータをシリアライズする責任と、レスポンスが無効な場合にエラーを生成する責任があります。
シリアル化はリクエスト操作とセッションタスクの完了ブロックで発生します。

AFHTTPRequestOperation Example

NSURL *URL = [NSURL URLWithString:@"http://example.com/foo.json"];
NSURLRequest *request = [NSURLRequest requestWithURL:URL];
AFHTTPRequestOperation *operation = [[AFHTTPRequestOperation alloc]
                                     initWithRequest:request];
operation.responseSerializer = [AFJSONResponseSerializer serializer];
[operation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {
    NSLog(@"%@", responseObject);
} failure:nil];
[operation start];

AFHTTPRequestOperationManager Example

AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];
manager.responseSerializer = [AFJSONResponseSerializer serializer];
[manager GET:@"http://example.com/foo.json" parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject) {
    NSLog(@"%@", responseObject);
} failure:nil];

Response serializers can also be chained, using AFCompoundSerializer. Compound serializers consult each component serializer in order, until it finds one that successfully performs responseObjectForResponse:data:error: without generating an error.
If a request operation or task, for example, wanted to be able to handle both JSON and XML responses using a single code path, this can be accomplished by setting a compound serializer with XML and JSON serializer components as the responseSerializer of the HTTP request operation or HTTP client. By default, AFHTTPRequestOperationManager and AFHTTPSessionManager have JSON serializers.

Response serializersは又、AFCompoundSerializerを使うことで連鎖させることもできます。
Compound serializersは正常にエラーなく動作するserializerを見つけるまで各シリアライザーを順番に参照します。
...

その他公式資料

AFNetworking2.0のドキュメント
http://cocoadocs.org/docsets/AFNetworking/2.0.0/

GitHub
マスター https://github.com/AFNetworking/AFNetworking
1.x https://github.com/AFNetworking/AFNetworking/tree/1.x

AFNetworking-2.0-Migration-Guide
https://github.com/AFNetworking/AFNetworking/wiki/AFNetworking-2.0-Migration-Guide

iOS開発のスモールチームに良さそうなBitbucket

2-3人でiPhoneアプリ開発を地味に進める中、
以下希望にマッチしたのでbitbucketを導入。

• 無料(2013/09/15時点で5ユーザーまで無料)
• 引き続き2-3人で利用予定
• バグと簡単なタスクがチケット管理できれば十分
• privateなGitリポジトリが必要
• wikiも使いたい

公式サイトhttps://bitbucket.org/
機能追加やサーバーメンテナンス情報はhttp://blog.bitbucket.org/をウォッチ

Bitbucket管理用のiOSアプリは以下

• bitissues

issue管理に特化したiOSクライアント、手軽で無料。
issueの作成、閲覧、編集、コメントの投稿等できる。
verupでissueのclose、reopen等に期待

CoreData再学習_Appleのサンプルを読む_TaggedLocations

CoreDataがなかなか身に付かないので改めてAppleのサンプルコードを読んでます。
今回はTaggedLocationsを読んだので、気付いた事やクラスの依存関係をメモします。


・どんなサンプル？
イベントとタグを位置情報を紐づけて登録できるアプリです。


・何が学べる？
多対多の関連と削除ルール等が学べます。
特にあるタグを削除した時に、そのタグを参照していたイベントがどうなるか..
こういった所は動かしてみると分かりやすいです。


・クラスの依存関係は？
以下ざっくりとした依存関係です。相互参照はEventとTag以外ない感じですが、
手書きなのでミスっているかもです。



・モデルファイルは？
以下はxcdatamodeldの状態

・折角なので試した方が良さそうなこと
削除ルールがNullifyなのでDenyに変更して挙動を確認する。
同じくCascadeに変更して挙動を確認する。


以下はサンプルならではの問題等
・APLAppDelegateにCoreDataスタックを生成するコードが丸々ある。
=>CoreDataManagerを作って移動


・TableViewControllerがでかい
=>フェッチ、位置情報取得、データアクセス等はラッパーを経由して取得、委譲


・Cellのパターンが増えた時に困るかも。
=>TableViewCellFactory等を作りそこから生成

コンビニエンスコンストラクタの初期化にはselfを使う

コンビニエンスコンストラクタを実装する時はselfを使う。


(例1) User : NSObjectクラスを初期化するコンビニエンスコンストラクタ

+ (instancetype)userWithName:(NSString *)inName age:(NSInteger)inAge
{
    // 悪い例
    //return [[User alloc] initWithName:inName age:inAge];
    
    // 良い例
    return [[self alloc] initWithName:inName age:inAge];
}

悪い例でも動作はするが、
FreeUser : User等継承したFreeUser内でuserWithNameをコールした際、
FreeUserのインスタンス変数が正しく初期化できなくなる。


以下呼び出し時にUserが悪い例の実装のままだと、
FreeUserの保持するプロパティにアクセスした時に例外が発生する。

FreeUser *freeUser = [FreeUser userWithName:@"mike" age:40];
NSLog(@"%ld",((long)freeUser.launchCount));

(例1)でselfはメッセージを実行中のレシーバを指すので、
[FreeUser userWithName..略];とコールされた時はselfはFreeUserになり、
[User userWithName..略];とコールされた時はselfはUserとなる。