読者です 読者をやめる 読者になる 読者になる

shobylogy

叩けシンプルの杖

iOS 7をサポート対象外にして得られたもの

年末に「iOS 7をサポート対象外にしよう!」ということを勧めていたのですが、

blog.shoby.jp

この度無事に自分の関わるプロジェクトでiOS 7をサポート対象外にすることに成功しました。

せっかくなので、開発において何が変わったかを書いておきます。

概要

  • UIAlertViewをUIAlertControllerに移行できた
  • Assets Library FrameworkをPhotos Frameworkに移行できた
  • UIDeviceをNSProcessInfoに移行できた
  • iOS 7が未対応になったライブラリを最新版に更新できた
  • 新規コードをSwiftで書くというルールができた

UIAlertViewをUIAlertControllerに移行できた

iOS 8からはdeprecatedになっていたUIAlertViewを使わなくても済むようになりました。 また、UIAlertViewとUIAlertControllerをOSによって使い分けるためのwrapperクラスを使わなくなりました。

Assets Library FrameworkをPhotos Frameworkに移行できた

iOS 9からはdeprecatedになっていたAssets Library Frameworkを使わなくても済むようになりました。 Assets Library Frameworkでは、サイムネイルとして取得できる画像のサイズがかなり小さく、写真一覧画面での表示が荒くなっていましたが、解決しました。

UIDeviceをNSProcessInfoに移行できた

[[UIDevice currentDevice] systemVersion][[NSProcessInfo processInfo] operatingSystemVersion] に移行したことで、文字列で比較したり、floatに変換してメジャーバージョンを判定する必要がなくなりました。

iOS 7が未対応になったライブラリを最新版に更新できた

具体的には、QBImagePickerAdobeCreativeSDKです。

新規コードをSwiftで書くというルールができた

直接は関係ないですが、開発が気分的にかなり楽になったためか、新規コードはSwiftで書くというルールができました。 iOS 7を対象外にできたことで、互換性を考えたコードを書くというプレッシャーが減り、気分が晴れ晴れしています。

まとめ

iOS 7を切ることで、deprecatedになったframeworkを移行したり、OSの関係上で更新することができなかったライブラリを最新版に上げることができました。 また、直接関係はないですが、開発が気分的に楽になり、新規コードをSwiftで書くというルールもできました。

これからObjective-C製のライブラリをSwift製のライブラリに乗り換えていく予定です。

RMagickでHSLへの変換がうまく動かないことがある

RMagickのPixel#to_hslaでsやlが正しく変換できない現象が発生していた。*1

原因はImageMagickのバグだった。

2011-05-14 6.6.9-9 Cristy <quetzlzacatenango@image...>
Fix transient bug for HSL to RGB and back.

http://www.imagemagick.org/script/changelog.php

6.6.9-9 以降のImageMagickであれば問題ないが、それ以前だと発生する。

可能ならImageMagickのバージョンを上げるのが良いが、難しい場合はcolorというgemでHSLへの変換を行うと良い。 *2

*1:主に白や黒、グレーといった無彩色でのズレが大きかった

*2:よく考えると、HSLへの変換でいちいちImageMagickを経由するのは不健全な気もするので、これで良かった気がする

Universal Linksの運用の手間を減らす

概要

  • apple-app-site-associationを署名したファイルではなく、JSON形式のAPIにする
  • JLRoutesを使ってWebPageURLをCustomURLと合わせてハンドリングする

apple-app-site-associationを署名したファイルではなく、JSON形式のAPIにする

iOS 9以降の場合、HTTPSでアクセス可能なドメインであれば apple-app-site-association のファイル自体を署名する必要がなくなりました。 *1

サーバの証明書のみを気にすれば、ファイルの署名の期限切れを気にする必要がなくなります。

また、Content-Typeをapplication/jsonで返せれば良いので、JSON形式のAPIとしてapple-app-site-association を提供することができます。

If your app runs in iOS 9 or later and you use HTTPS to serve the apple-app-site-association file, you can create a plain text file that uses the application/json MIME type and you don’t need to sign it.

Support Universal Links より

JLRoutesを使ってWebPageURLをCustomURLと合わせてハンドリングする

AppIndexingを使うとアプリ側にWebPageURLが渡ってきますが、ハンドリングする部分は煩雑になりがちです。

JLRoutesというライブラリを使うと、WebPageURLをCustomURLと合わせてハンドリングすることができます。*2

ユーザー情報を取得するCustomURLがapple://users/:user_id、WebPageURLがhttps://apple.com/users/:user_id だとすると、以下のように同じような処理をまとめて書けます。

// apple://users/:user_id
JLRoutes *router = [JLRoutes routesForScheme:@"apple"];
[router addRoute:@"/shop/:user_id" handler:^BOOL(NSDictionary *parameters) {
    // open user view controller
}];

// https://apple.com/users/:user_id
JLRoutes *router = [JLRoutes routesForScheme:@"https"];
[router addRoute:@"/apple.com/users/:user_id" handler:^BOOL(NSDictionary *parameters) {
    // open user view controller
}];

まとめ

  • apple-app-site-associationを署名したファイルではなく、JSON形式のAPIにする
  • ファイル自体の署名を気にする必要がなくなる
  • JLRoutesを使ってWebPageURLをCustomURLと合わせてハンドリングする
  • 同じような処理をまとめて書ける

*1:iOS 8でHandOffやShared Web Credentialに対応している場合はダメ

*2:試してないですが、SwiftだとSwiftRouterが使えそうです

「 iOS 7をサポート対象外にして開発を健全化する」というタイトルで発表しました

第24回 potatotipsで、「 iOS 7をサポート対象外にして開発を健全化する」というタイトルで発表しました。

こちらの発表には、業界全体で、最先端の技術を追い求められる健全な開発環境を当たり前にしたいという思いを込めています。

最近は、Swiftがオープンソース化されるなど、iOSが盛り上がりを見せており、最先端の技術に注目が集まっていると思います。

ただし、ありがちなのが「趣味ではiOS 9でSwiftだけど、業務はiOS 7でObjective-C」「Swiftが導入できるのは新規プロダクトだけ」という状況です。

たとえモダンな環境でなくても、Objective-Cで書かれていても、ユーザーに愛されている既存のプロダクトには価値があります。

古いバージョンのOSをサポート対象外にしたり、少しずつSwiftに書き換えるなど、技術的負債と折り合いを付けながら、ユーザーの喜ぶ機能を、楽しく開発できるようにしていきたいと思っています。

皆さんも、少しずつ始めてみませんか?

モックAPIを使ってアプリの開発をスムーズに進める

mokable.ioという実際に叩けるモックAPIを作れるサービスがあります。

これを使うとアプリの開発をスムーズに進められることが分かったので、書いておきます。

モックAPIを使った開発フロー

  1. クライアント側のエンジニアがAPIのレスポンス(仮)を考える
  2. APIレスポンス(仮)を元に皆で話し合ってレスポンスを確定させる
  3. サーバー側のエンジニアはAPIの開発をする。その間、クライアント側のエンジニアはモックAPIを使って機能を実装する
  4. 実際のAPIが完成したらそれと差し替えて動作チェックをする
  5. リリース!

この開発フローのメリットは主に二つです。

APIの開発とクライアントの開発が同時進行で進む

モックAPIを利用して開発を進めるため、「APIの実装待ち」という状況が発生しづらいです。 また、実際に叩けるモックAPIを使用することで、実装完了後はURLを差し替えて動作をチェックするだけで済みます。

APIの仕様確定が早まり、実装後の仕様変更が少なくなる

モックAPIを作るには、きちんとAPIのレスポンスが確定していなければなりません。 そのため、最初にきちんとAPIのレスポンスを確定させようという想いが生まれます。 また、クライアント側のエンジニアにとっては、「APIがまだ完成してないから開発に入れない」という言い訳が通用しなくなるため、クライアントのエンジニアがAPIの仕様策定に進んで参加するようになります。

クライアント側のエンジニアがAPIの仕様策定に参加することで、クライアント側にとって使いやすいAPIが生まれ、APIが完成した後の仕様変更が減ります。(「こういうデータが足りなかった」「ここのデータ構造が使いづらい」等が減る)

まとめ

モックAPIを使用することで、APIの開発とクライアントの開発を同時進行で進めることができ、開発がスムーズになります。 また、APIの仕様確定が早まり、実装後の仕様変更も少なくなる効果もありました。

mokable.ioを賢く使ってアプリの開発速度を上げましょう。

LGTM画像に貼る用の猫画像を集める

結論から。The Cat APIというサービスを使うと猫画像を効率的に集められます。

その名の通りAPIを提供してくれているので、アニメーションGIF画像だけを集めることもできます。

http://thecatapi.com/api/images/get?format=html&results_per_page=20&type=gif

可愛い猫画像を貼ってコミュニケーション円滑にしましょう!!

f:id:shoby:20150727131618g:plain

Google I/O & WWDC情報共有会でiOS 9の新機能について発表しました

iOS 9の新機能について、実際にサービスに活かすとしたら、という観点で発表しました。

今回、Search APIsがサービス運営的な意味では特に意味を持つと考えています。

Webとアプリの連携が強まり、アプリ内のコンテンツが検索できるようになりましたが、これから大きく意味を持つことなると思います。

早めに対応しておくと良さそうです。