dentakurouの日記 RSSフィード

2018-05-13 アクセスログでみるとiPadはまだまだ売れる

[] アクセスログでみるとiPadはまだまだ売れる

先日アクセスログ統計を見て、やっぱり一般消費者iPadはまだまだ売れると確信を持ちました。

数年前にAppleiPadタブレット市場は頭打ちだと予測し、仕事で使うハイエンドiPad Pro、学校で使うローエンドのiPadの2種類にしてしまいました。

つまり真ん中が無い。

そこはiPhone plusを位置付けている感があります。

なので、私が電子書籍を読むのに最適だと思っているiPad miniは何年もアップデートされない。

本当?

そんなに市場ないのかなとずっと思っていました。

先日アクセスログ統計を見て驚きました。

f:id:dentakurou:20180513203150p:image:w640

これはiPadSafariのバージョンごとに集計したものですが、なんと過半数Safariの9.0。つまりiOS9.xのユーザーです。このことからiOS9.xまでしかサポートしていないiPad2iPad miniのユーザーが過半数いると推測できます。

この消費者は、初代iPadを買ったアーリアダプターではなく、その後にiPadを買った大量の消費者たち。その人たちが買い替えをためらっている感が見て取れます。というのも私もそうだからです。iPad mini4の次がでたら買い換えようと思って早数年。

f:id:dentakurou:20180513203154p:image:w640

一方でiPhoneはなんとなく2年で買い換える人が多いからか、順当にiOS11が過半数という結果になっています。

今となってはminiは最低でもローエンドのiPadと同様にペンをサポートしないとminiを買い換える気は湧かないです。今ので本も動画も見れますので。iPad2も持ち歩きませんがBose SoundTouchに接続してミュージックプレイヤーになっていますが現役です。

Apple Musicや動画アプリに夢中で、iBooksにあまり力を入れていないAppleがこのことに気づくのはいつかなぁ。もっと高額で引き取るとか、Apple WatchのようにSIMの共用ができないと買い換えないなー。

 

本題と関係ないですが浴室のミュージックプレイヤーでiPhone5も現役ですし、iPhone6は電話としても現役です。バッテリーは30分あれば自分で交換できますし。

Face IDはユーザー体験に関係ないので全く興味ないですねぇ。この先iPhoneiPadだらけになるのを、アップルが何かしらの消費者が腑に落ちる理由をつくって捨てさせないと、この先もっと市場が縮小すると思います。

2018-04-27 iOS11.3で俺アプリが全部クラッシュしたので対処した

[]iOS11.3で俺アプリが全部クラッシュしたので対処した

ある日、App Storeにリリースしている俺アプリが動かないことに気づきました。

しかもリジェクトされていないアプリ10本全部。

ローンチスクリーンを一瞬表示して消える。だけど、アップスイッチャーでは見えている。

f:id:dentakurou:20180427195713p:image:w360

でもこれはアップスイッチャーが勘違いした残骸みたいで、バックグラウンド処理は動いていないことからクラッシュしているところまでわかりました。

少し前にネットのニュースでiOS11.3になってSkypeとかがクラッシュしているのは知っていたのですが、ユーザーインタフェースがぜんぜん凝っていない自分のアプリがまさかと思いスルーしていましたが全滅でした。

ネットで類似した現象を探したのですがコレといったものはありませんでした。Storyboardを作り直して治ったというのはありましたが、既存のアプリを全部作り直すのはなんとも現実的ではなく気絶しました。

それでやったこと。

1)iOS11.3をiOS11.3.1にアップグレード。=>かわらず。

2)次に現象Xcodeと実機でみるためにiOS11.3に対応するXcode9.3をダウンロード

ところがXcode9.3からmacOS 10.13 High Sierraしかサポートしていないことが判明。これまでのパターンだとXcodeは開発ツールということもあり、一つ前のmacOSまでサポートしていたのですが、これがだめに。これで1日が経過。

3)それでmacOS High Sierraダウンロードしてインストール。そしてXcode9.3をダウンロードしてXcode9.2からXcode9.3にアップグレード。これで2日経過。

4)Xcode9.3で再ビルドしただけでクラッシュが解消されることを発見。これまでにリリースしたすべてのアプリビルドしなおしてiTunes Connectでレビュー待ちにしました。この作業でまるまる半日かかり、トータルで3日経過。

5)5日目の早朝にすべて審査を通過してApp Storeへリリース完了

今回のアプリは、昨年にiPhone Xの画面に対応した時のXcode9.1でビルドしたものだったので、そのSDKに何らかのバグがあったのではと思います。

ゴールデンウィークにバリバリ使う予定のアプリだったので焦り、疲れました。でも旅先で愕然としなくてよかったです。

有料アプリをご購入いただいているユーザ様にはご迷惑をおかけしたと思います。

申し訳ありませんでした。m(. .)m

あと数日で審査を通る見込みですので今しばらくお待ちください。

2018-01-27 5分でもできる!iFixit翻訳ボランティアで英語とライティング力UP

[]5分でもできる!iFixit翻訳ボランティアで英語力とライティング力をアップ

私が最近ハマって楽しんでいるiFixitの翻訳ボランティアというのをご紹介します。

iFixitって何?

iFixit社は、修理して使い続けることがエコであるという理念で修理パーツやツールの販売を手掛けている会社です。そして、iFixit社は単にパーツやツールの販売だけでなく、正しくパーツ交換をするための修理ガイドをソーシャルで作成し公開して交流できるサイトを運営しています。ここが従来のパーツ屋さんのスタンスと違うところだと思います。

f:id:dentakurou:20180127143603p:image:w640

ifixit.com(日本語)

私は昨年秋までiFixit社がどのような会社か正しく知りませんでした。それまでは「毎年恒例の秋にでるiPhoneの新機種を真っ先に分解してネットのニュースになる解体屋さん。」ぐらい。数年前から自分でiPhoneバッテリー交換をしており、何度もネットで情報収集した経験があるのですが、それでもそのぐらいの認知度でした。たぶん当時は日本語の修理ガイドの充実度とかでGoogle検索の上位にヒットしていなかったのかなと思います。そして昨年9月24日に、iPhoneの修理について追加の情報がないか検索していたところ、iFixitの日本語の修理ガイドにたどり着きました。

 

オレ、翻訳ボランティアになる

とても洗練された修理ガイドのページに、これまで気づかなかった自分に驚きました。たとえばiPhone 7だと以下のように細かく18ものガイドが整備されています。

f:id:dentakurou:20180127172141p:image:w640

各パーツの修理ガイドはすべて統一されたフォーマットで見やすいと思いました。またバッテリー交換のような複数のパーツの手順の組み合わせで成り立つガイドは、ちゃんと個々の修理ガイドが連動しており、同じ修理が異なる手順にならない工夫もされています。

f:id:dentakurou:20180127172134p:image:w640

そこで目に留まったのが「翻訳」のボタン。恐る恐るクリックしました。そうすると日本語のページが下記のような英語と日本語の翻訳用ページに切り替わりました。

f:id:dentakurou:20180127172130p:image:w640

最初は何も知らなかったので、「えっ?自分で翻訳していーの?ほんとにー?」という感じで、気になるところを翻訳(というか微修正)して保存しました。そうしたら数日後に、なんと自分の翻訳が修理ガイドに反映されている!

 

この体験で初めてiFixitの修理ガイドというのは、世界中のたくさんの翻訳ボランティアの手によって作成や翻訳されていることを知りました。(反映にあたってはiFixitスタッフのレビューが入ります)

上記の画面のとおり、ちょこっとした単位での翻訳もできるのです。

これは「目的を持って英語に接したい」「テクニカルライティングを継続的にしてスキルアップをしたい」という自分の求めていたことにマッチしました。それまでは自分の開発チームのために洋書を部分的に翻訳した経験はあったのですが広く公開されるような文章の翻訳って自分のスキルでは機会は絶望的だと思っていたし、テクニカルライティングソフトウェア関連は昔に経験があるのですが機会を得るために売り込むのは面倒。でもここなら好きな時に自由にやれる!と思いました。それからランチタイムや仕事帰りの通勤時間にちょこちょこ開始。

f:id:dentakurou:20180127172052p:image:w640

これはアカウント情報でみることができる私の翻訳活動の時間帯(UTC-7)。日本時間(+16)で、もろランチタイム、仕事帰り、晩飯の後に傾向がでていますね。

f:id:dentakurou:20180127172045p:image:w640

こちらもアカウント情報でみることができる私の時間軸の活動グラフ。12月はプログラミングに時間を割くことが多く翻訳は少なめですが、お正月のお餅もカレーも飽きてムクムクっとデルタが上昇しているのがわかるかと思います(笑)

 

サプライズあり!

翻訳を始めたある日、iFixitの日本人スタッフの方からコンタクトがあり、グッズを送っていただけるとのこと。

f:id:dentakurou:20180127172102p:image:w640

ギークなステッカーやTシャツをいただきました。先日はパーカーをいただきました。職場のPCにもステッカーを貼ってしまいました。今度、海外の翻訳ボランティアに見つけてもらえるようにスーツケースに貼ってみようかなと思います。

f:id:dentakurou:20180127172055j:image:w640

グッズは大好物なので燃えます!

 

楽しいこと

やってみて勉強になるのが、ソフトウェア開発とまた違う英単語がビジバシ使われている点です。ハードウェア関係ってこんな表現使うのだーと毎回発見がありますし、表現の意図に苦しむ時もあります。苦しむのも楽しい。

プラスネジのドライバーをPhillips Driverと呼ぶのを翻訳ボランティア活動で初めて知りました。昔、海外旅行先で「Plus Driver貸してください」って言って、なかなか通じなかったのはこのせいかーと謎が解けました。このようにDIYレベルで日常英会話でも使うハードウェア関連の英単語もバンバン吸収できます。

最近は最初にフランス語で書かれた修理ガイドを、Google翻訳で英語に翻訳して、それをもとに日本語に翻訳したりする余裕もでてきました。

今年すっごく楽しい体験をしました。ある日、ランチタイムに同時に同じ修理ガイドの翻訳を他の翻訳ボランティアの方としてしまったことです。私の翻訳は5分かけたぐらい捨てることになったのですが、それよりもどこかで同じ楽しみを持って取り組んでいる翻訳仲間がいることが嬉しかったです。

 

翻訳で気をつけていること

翻訳対象の製品のメーカーの商品紹介サイト、取扱説明書の日本語バージョンの訳語を優先しています。たとえばTaptic EngineやTouch IDのような名称。メーカーが英語のまま日本語サイトでつかっているならばiFixitでも継承するようにしています。たとえば、iPhoneの各種サイドボタンの呼び方は新機種でアップル社が変えることがあるので要注意です。

もう一点が、ミスリードしないように修理ガイドに沿って脳内シミュレーションしながら翻訳の文章を組み立てること。たとえばiPhoneの下側と原文に書いてあるときに、それは表面の下側なのか、下側の側面の外側なのか、下側の側面の内側なのかとか。脳内で修理をシミュレーションすると、正確に伝わりやすい日本語を見つけられます。

 

ところでiFixitのパーツや工具は日本で買えないのか?

一部取り扱っているお店はあるようですがiFixitの日本向けネットショッピングサイトは今現在はありません。米国から輸入はできると思いますがリチュームイオンバッテリーの郵送は国際的に規制がかかっているのでそれ以外のパーツや工具までかなと思います。でも、ヨーロッパやオーストラリア向けサイトは立ち上がっているので、今年ぐらいにはと期待しています。

 

どのジャンルの修理ガイドが対象か?

冒頭のiPhoneをバラす会社のイメージで作成や翻訳できる修理ガイドもスマホやパソコンかなと思っていたのですが、なんと服や車まで多岐にわたっています。

f:id:dentakurou:20180127172040p:image:w640

服の場合は、ファストファッションのリフォームも公開できると面白いかもしれませんね。

自分の場合は、スマホやPC以外にはオーディオ関係には参戦できそうな気がしてます。

 

おまけ・DOZUKI

実はiFixit社は修理ガイドを共同作成するためのプラットフォームDOZUKIを開発し保有しています。DOZUKIだけクラウドサービスとして提供しているようです。DOZUKIの公式サイト

f:id:dentakurou:20180127193337p:image:w360

仕事関係で手順書を作ることがあるので、DOZUKIの日本への展開も期待しています。金融系の膨大な手順書整備とかにいいんじゃないかなー。

 

日本語に翻訳されていない修理ガイドはたくさんありますので、ぜひみなさんも翻訳仲間になってください。

2018-01-13 iOSプログラミング:iOS11のStoryboardのSegueの使い方(その3)

[] iOSプログラミング:iOS11のStoryboardの「Present Modally」Segueを深掘り

今回は、iOS11のStoryboardの画面遷移で用意されているSegueの種類の違いついて掘り下げたいと思います。

iOSプログラミング:iOS11のStoryboardのSegueの使い方(その1)では、古いSegueがDeprecated(非推奨)になっており、今のiOS11でのほぼノンコーディングでの簡単な書き方を紹介しました。

iOSプログラミング:iOS11のStoryboardのSegueの使い方(その2)では、Navigation Controllerを追加すると自動的にNavigation Barと戻るボタンが作成されて、画面遷移をノンコーディングで作れるやり方を紹介しました。この時は、

  • Show (e.g. Push)
  • Show Detail (e.g. Replace)
  • Present Modally
  • Present As Popover

の4種類のSegueのうち「Show (e.g. Push)」を使いました。じゃあ、他は何が違うのよというところを調べたのでご紹介します。

サンプルとして前回のアプリをSegueの種類が試せるように以下のように改造しました。

f:id:dentakurou:20180113123233p:image:w360

Storyboardでみると千手観音のようになります。

f:id:dentakurou:20180113123230p:image:w640

このStoryboardをみると一番上の「Show (e.g. Push)」以外のSegueではUINavigationControllerを使っていてもNavigation Barが自動的に追加されていないことがわかります。用途として「Show (e.g. Push)」は元の画面の延長となる画面に遷移する場合、他はそうではない場合を想定した設計思想になっているように思えます。

 

「Show (e.g. Push)」以外ではSafeAreaに注意

NavigationBarが自動的に追加されないので、自由にレイアウトできますが、かわりにSafeAreaを気にする必要があります。気にしないとiPhone Xの切り欠きやその他のiPhoneのステータスバーに被ります。

f:id:dentakurou:20180113130225p:image:w360

SafeAreaについては、iOS8対応の古いアプリをiPhone Xに対応する手順で説明していますので、古くないアプリの場合もそちらを参照してください。

 

Show Detail (e.g. Replace)

基本的にはNavigation Barが自動的に追加されない以外は、「Show (e.g. Push)」のSegueと違いはないようです。しかしNavigation Controllerなしで「Show (e.g. Push)」のSegueを使った時と同様に下から上にポップアップして画面が遷移します。右から左に遷移しない理由はわかりませんが、iOS11ではそのようになりました。またその挙動を変えるようなプロパティも見当たりません。ひょっとしてiPadでは違うのかなと思い検証したのですが変化なかったです。

f:id:dentakurou:20180113123227p:image:w360

 

Present Modally

デフォルトだと「Show Detail (e.g. Replace)」のSegueと見分けがつかない画面遷移をします。しかし、「Present Modally」のSegueにはTransitionという遷移の時の挙動(アニメーション)を変えるプロパティが用意されています。

f:id:dentakurou:20180113123223p:image:w360

  • Default
  • Cover Vertical
  • Flip Horizontal
  • Cross Dissolve
  • Partial Curl

の5つで「Default」は、iOS11では「Cover Vertical」と同じ挙動でした。「右から左に滑り込む」のがないのが不思議です。ユーザーインタフェース設計思想でしょうか。

 

Cover Vertical

下から上にポップアップします。「Show Detail (e.g. Replace)」のSegueと見た目の挙動は同じです。

 

Flip Horizontal

画面がひっくり返って、裏側の次の画面が表示されます。

f:id:dentakurou:20180113123220p:image:w360

 

Cross Dissolve

画面がフェードアウトして、次の画面がフェードインします。

フェードアウト・フェードインのスピードはかなり速くて、スクリーンショット取れませんでした。

 

Partial Curl

画面がめくり上がって、次の画面が表示されます。

f:id:dentakurou:20180113123216p:image:w360

初期のiPhoneグーグルマップストリートビューに切り替えるので見かけましたし、見た目が面白いので自分も使いました。当時はめくり上がった後に次の画面の上にめくれが見えていて、そこをタップすると元の画面に戻ったのですが、フラットデザインになったiOSからこの次の画面で見えている「めくれ」がなくなりました。依然として「めくれ」が以前にあったところをタップすると戻れたのですが、わかりづらい。それで私は順次使うのをやめています。

 

iPhoneシミュレータバグ

この検証をしているときに遭遇したのですが、挙動を観察するためにシミュレータの「Debug」の「Slow Animations」にした時に、「Flip Horizontal」だと、遷移した後にボタンをタップしてもアプリが反応しなくなります。その状態で「Slow Animations」を解除すると反応する時と、依然としてしない時があります。シミュレータバグだと思います。

 

今回紹介した「Present Modally」のSegueはいろいろと挙動を変えられるので、ユーザーインタフェースをデザインする時に便利です。

Present As Popoverは又の機会で、今回はここまで。

2018-01-09 iOSプログラミング:iOS11のStoryboardのSegueの使い方(その2)

[]iOSプログラミング:iOS11 NavigationControllerを使うと画面遷移が楽チン(2018年版)

前回では2画面間をSegueで画面遷移して、その1本のSegueを逆に戻るunwindをほぼコーディングで実装する方法を紹介しました。

でももっと楽チンな方法があるのです。

 

まず例として前回のunwindを消したアプリを作ります。

f:id:dentakurou:20180109200445p:image:w640

Navigation Barという画面の上にアプリ名とか画面名を表示しているアプリを見たことあると思いますが、それを使います。

ただし、下記のXcode右下のObject Libraryに表示されているのをドラッグして貼ってはいけません!

 

これダメ

f:id:dentakurou:20180109200946p:image:w360

これをやっちゃうと縦幅が融通きかなくて、自分で上に隙間を設けないとiPhoneのステータスバーやiPhone Xの切り欠きとオーバーラップしてしまいます。

 

隙間がダサい

f:id:dentakurou:20180109200942p:image:w360

このように、上の隙間がダサいし、今回の目的が達成できません。

ではどうするのかというとNavigationControllerクラスを追加します。しかし、これまた下記のXcode右下のObject Libraryに表示されているのをドラッグして貼ってはいけません!

 

これダメ

f:id:dentakurou:20180109202904p:image:w360

この方法だと、なぜかいらないTableViewControllerまで作られちゃいます。勉強のためにやってみていいけど、消してください。

ではどうやって足すのかというと、Storyboardで最初に表示するUIViewControllerを選んで、Xcodeの「Editor」メニューをプルダウン、「Embed in」メニューのところにあるNavigation Controllerを選びます。

f:id:dentakurou:20180109202852p:image:w640

 

さぁ、やってみてください。じゃーん

f:id:dentakurou:20180109204951p:image:w640

左にNavigation Controllerが増えただけでなく、遷移先の右のUIViewControllerまでNavigation Barが追加されました。しかも縦幅もちょうどよく長くなり、「<Back」ボタンまであります。

前回と違い完全なノンコーディングで、この状態でunwindの画面遷移まで動きます。あと前回最後に問題点として触れた、下から上に滑り込んで画面遷移するのではなく、正しく右から左に画面が滑り込んできます。

 

しかも最初の画面のNavigation Barにタイトルをセットすると、先ほどの<Backボタンが自動的に前の画面タイトルに変わります。

f:id:dentakurou:20180109203937p:image:w640

遷移先のナビゲーションバーのタイトルの設定はちょっと独特です。最初の画面のようにナビゲーションバーのタイトルのあたりをクリックしても何も起きません。

なんとUIViewControllerにもTitleというプロパティがあって、このNavigationControllerを使った実装ではそのUIViewControllerのTitleが反映されるのでした。

f:id:dentakurou:20180109203927p:image:w320

これに気づいたの結構最近です。

 

今回はここまで。まだまだSegueの画面遷移は奥が深いです。