#oi_study ios全般の知見を共有する iOS Creator’s Meetup vol.2に参加してきたまとめ
iOSの言語に関する知識だけでなく、デザイン, UX, Xcode, 審査提出など、iOSアプリを作る上で必要になることについて
エンジニア、デザイナー、ディレクターが興味のあることを共有するiOS Creator’s Meetup voi.2に参加してきたのでそのまとめです。
AutoLayoutのデバッグを試みる
- autolayoutの対処法について予期せぬ制約を見つけて直すところについて見てみる発表
- シンボリックブレークポイントは特定の条件、つまり、autolayoutでエラーが出たときなどに処理を止めてくれる
- 作成方法はブレークポイントを作成するところから「Symbolic Breakpoint」を選択して作成できます。
- ブレークポイントを有効にしてやると、viewの階層楮をデバッグとして出力することが出来ます。
- AMBIGUOUS LAYOUTがでたところが怪しいと見ることができる
- 例えばlldbで以下を入力すると、背景色を赤にしたりできるので原因特定がしやすくなる。
|
1 |
expr ((UILabel *)メモリアドレス).backgroundColor = [UIColor redColor] |
- ブレークポイントで止まったときは描画前で止まります。
Object思考な人がRxSwiftを試してみた（仮）
- RxSwiftがしっくり来た理由1
- オブザーバーパターンを踏襲しており、観察する人を観察対象がoverserverへ流れてくる設計になっている
- RxSwiftがしっくり来た理由2：メソッドチェーンで書ける
- 流れるようなインターフェースっぽいので、関数型プログラムの敷居が低くなる
- この形式はRxSwift固有の特性ではない
- RxSwiftがしっくり来た理由3：マーブル図で難しいタイムラインがわかりやすい
- マーブル図のおかげで時間の流れをシンプルに表現できるようになった！
作ってみた
- ボタンをタップして、ネットワーク処理を直列で起こし、順次結果を表示するものを作ってみた。
- 観察対象と観察者のペアを2つ作る
- publishsubjectのオブジェクトにボタンをタップすると追加していく
- RxCocoaはUIKitのクラスでRxSwiftを使えるようになります。
- publishsubjectのオブジェクトにボタンをタップすると追加していく
- bufferを使うと配列で情報を送られ、空配列も送られるのでfilterして送るようにしております
- ネットワーク処理は今回はライブラリで実装しました。
- 2つめの観察対象を観察することでネットワーク処理の結果を観察することができるようになる
- bindToを使って画面に表示しています
感想
- シンプルに処理がかけた
- エラー処理を入れるとどうなるかは不明
- ライブラリの全体像を把握するのに時間がかかった
スマホアプリディレクターが考えていること
- アプリは作ったら終わりではない。プロダクトを世に出してみんなに喜んでもらうところまで考える
- 色んな人とコミュニケーションをとり、開発の環境づくりや、売れるタイミングで何かあったらごめんなさいするのがディレクターの仕事
- 今回は日々直面する問題に対しての発表
全機能作って問題
- 他社アプリの機能を全部作ってというようなもの
- SNS共有機能などなど、全部作ってくれ
- 用途は何か？→友達に共有して欲しい
- 若いユーザが多いなかで、twitterやfacebookを使うか？と問いかけてバトったことがある
- 何を解決したい、ゴールは何かを問いかけている
Webと同じで問題
- webと同じにするのはアプリに必要なものなのかどうかを傾向を見て判断する
- 先にwebで試してアプリに展開するようにしている
アプリって必要問題
- インストールする手間がある
- 弊社の事情だと大体webとアプリだと7:3くらいの分布
- アプリならではの機能やUIで存在感を出すのを意識しながらやっています
- webとアプリを分けて考える必要もないかもしれないので、想像できなければアプリを作らなくてもいいかも
開発と企画のゴールが違う問題
- 開発は新しい技術もとりいれないといけなくてコストでしかない
- どうしたらいいかを聞いたら社内で偉い人になれ
- 重要な判断になればなるほど経営判断になる
- 信頼を積み重ねることが大事なのではないかと思っている
Realm Mobile Platformをさわってみた
- Realm Mobile Platformがリリースされました！
- MBaaSではないので、サーバを自分で用意する必要がある
- オンライン時はObjectServerとデータを同期し、オフラインはローカルで動く
- オフラインファースト
- オフラインであっても全て動作させる
- ネットワークの状態とコンフリクトを解決してくれる
- コンフリクト解消基本ルール
- Dleteは常に最優先
- 同じプロパティのUpdateは後ガチ
- Insertは時系列順
ためしてみた
- AMIを使ってEC2で立ててみた
- 22と9080のポートをあけておくだけ
- クライアントアプリの作成については、ドキュメントが分かりやすい
- 重要なのはsyncConfigurationというのがrealm2.0以上になると増えているのでそれにサーバ情報を指定するだけです。
Update後勝ちを試してみた
- 2つのデバイスをデータ同期している状態で、デバイスBをオフラインし、デバイスAをデータを変え、その後、デバイスBのオフラインのデータを変えた後にオンラインにしてみたが、先に更新したデバイスAnoデータに同期されることがあった
- どうやら、タイムスタンプ以外のロジックも動いている模様
同じオブジェクトのプロパティをupdateしてみた
- AとBがオフライン状態の時に、プロパティを変えてみたら、プロパティ単位でupdateが同期されました。
- 設定で変えられるかもしれません。
最後に
- 実装はとても楽
- コンフリクト解決の動きをしっておいたほうがいい
- DBの構造を考えておいたほうがいいです
- 今後いろいろ設定が増えていくと思うので期待してます。
iOSアプリにおけるリリースフローとCI環境
平田敏之様
- リリースフローの1サイクルに時間がかかってないか
- CI環境をどこまで導入できているか
- iosアプリにおけるリリースフローの例
- 企画、開発、検証、appleへ審査提出、リリース、リリース後検証という流れで、開発、検証、バイナリuploadの流れについてのお話
- 開発、検証、バイナリuploadは速く回すのが良い
- CI環境がない時はアプリを作って、xcodeを使って検証機にいれて検証をして、xcodeを使ってappstoreにあげていた
- CI環境があると開発者はコードをコミットすると、jenkinsがビルドしたりテストしてくれたり、その結果をslackで通知したりと、自動でやれるようになる
- 開発は開発、検証は検証に専念できるようになる
流れ
- 実装は、静的解析、アプリのビルド、アプリの自動テスト、コードレビューを行う
- コードレビューが一番コストかかるので、ある程度自動化して判定できるものは終えた上でレビューを行う
- 検証はjenkinsやdeploygateからインストールして、バグ報告する
- 最後はitunes connectにjenkinsがuploadする
リリースフローのコツ
- アプリのビルドについてはマシンパワーを良くしてビルド時間を短くする
- 自動テストは時間がかかるので並列化をして実行時間を短くする
- アプリのデプロイは問題なければ枚ビルドデプロイしてしまうのが良い
- コードレビューに関しては設計周りは予め相談する
- 検証についてはバグを登録するとslackで通知が来る
メリット
- CIをいれることで集中すべきものに集中できる
- 常に動くアプリが存在するようにするのが大事
まとめ
- リリースフローを簡単に素早く回すのが大事
- CI環境はプロダクトに関わるすべての人に必要な環境
- CI環境を用意してリリースを楽にしましょう
iOS10からのプッシュ通知入門
- プッシュ通知はユーザが使わなくなった時にユーザーを促す唯一の手段なので大事
- どんなことができるかの発表
通知の見た目と基本操作
- 受信してみると、ロック画面、ホーム画面、アプリ画面、通知センターでそれぞれ通知の見せかたがある
- それぞれ起動方法や、開く、消すといった手段が変わる
- プッシュ通知を開いてみるところがios10では左スワイプしてviewを選択すると詳細をみれるようになりました。
- 3D touchすると開く事もできます
タイトルを付ける
- 通知のペイロードはjsonでお送りします
- プッシュ通知にはタイトルとサブタイトル、本文がつけられます
カスタム警告音をつける
- soundというプロパティを指定して送ると音声を変えることが出来ます。
バッジを付ける
- バッジは6桁以上なると「12…56」といった表記になります
- badgeというプロパティを0で送るとバッジが消えます。
- alertプロパティなしなら通知されません
アクションを付ける
- プッシュ通知からアクションがios8からできるようになった
- アクション実行型はcategoryを送るとそのcategoryに応じたアクションを実行できる（用実装）
リッチ通知
- 画像、動画、音声、独自のビューを表示できる通知
- AppExtensionを作って実現します
- 通知ペイロードに画像URLを含めて送信する
- 通知を受け取ったら事前に画像をDLして、完了すると通知を表示する
気づいたこと
- 通知を送るのが楽しい
- Reproは通知送るのがいいらしい
- GrowthHackJournalを読むとプッシュ通知の効率的な送り方がわかるぞ！
コンテキストを意識したアプリデザイン（仮）
- UXがわからないので、UX MILKを作成しました
- アプリを作るときオリジナリティあふれる、イケてるアプリを作りたいと思いつくと思う
- 周りが見えていない、独りよがりなデザインのアプリが出来てしまった
- 認知的負荷：馴染みのないことを新しい認知にユーザは戸惑う
- ユーザがほしいのは使える、便利なサービス体験
- どう独りよがりなデザインから脱するか→プライドを捨てて正しくパクるべし
- コンテキスト：文脈、脈絡、背景
意識スべきコンテキスト
- ライフスタイルにおけるコンテキスト
- 通勤中で使うか、布団で使うかなどの利用状況を明確にすることでMUST機能がはっきりする
- マーケットにおけるコンテキスト
- 競合調査して周辺のサービスのトレンド、スタンダードによってデザインは規定される
- たとえばフリマアプリってこんな感じで並ぶなど
- マーケットのトレンドにのっかればユーザの戸惑いを減らせ、無駄なチュートリアルをなくすことができる
UX MILK Appの実例
- 記事を読むだけのアプリ
- あくまでwebメディアメインのため、サブプロジェクトとして進行して、最低限の機能でリリースした
- ライフスタイルにおけるコンテキストは「平日朝、通勤時に電車内で読む」
- マーケットのけるコンテキストは「ダブルレイアウト、ミニマルデザイン」
実際にやったこと
- paku-respect：先人たちが切り開いたUXを切り開く
- SmartnewsやGunosyなどのヒットアプリに沿うことで説明がいらない
- ユーザーは自然に使えるものが使いやすい
- 制作の意思疎通が明確
- 2人のチームでやっていて無駄な工数がさけない
- 各UIパーツや挙動に対してモチーフとなるアプリ、サービスを決めた。
- 例えば、カテゴリのタブの挙動どうするかというときに、どのアプリがよかったかを聞いて、大体のアプリの挙動に寄せた
- →すると、エンジニアがUIデザインを進められるようになった。
- 各パーツの挙動はすでにあるのでライブラリを用いてサクサク作ってもらったあと、細かい部分をSketchで作った
だめなパクリ
- スマニューみたいな、虹色の部分をぱくったりなど、サービスのアイデンティティをパクるのはだめ
- 同じアプリからいくつもパクるのはだめ。
- あくまでトレンドを踏襲する
サービスのアイデンティティ
- ロゴ、マスコット、カラー、トーン
- spotifyだと黒と緑のトーン、snapchatだと紫と白のトーンなど
- UX MILKの場合、キュレーションメディア風x ミニマルデザインx キャラクタを取り入れている
- オリジナリティを散りこむために、ローディング画面に、キャラクタの動画いれたり、未ロードサムネをキャラクタ画像にしたりした
まとめ
- 変なこだわりは捨ててトレンドに従い、その上でオリジナリティを盛り込む
@mogmetの所感
開発周りの知識だけでなく、デザインやプロダクトに関しても発表があったので幅広く目から鱗な情報を得られた勉強会でした。
最後のUXに関してはとても参考になり、自分自身も初めてのアプリを出したときパクリスペクトしまくったので、引き続きパクリスペクターとして開発を頑張っていこうと思う所存です。
