つばくろぐ @takamii228

知は力なり

2020年にお金を払ったサービス一覧

2020年にお金を払ったサービスのまとめの今年分をまとめました。

2019年版はこちら。

takamii.hatenablog.com

新規

Zoom 2200円 / 月

仕事で必要になったので課金し始めて、プライベートでも使うようになったのでそのまま課金している。年間契約にしようか悩み中...。

Apple Music 9800円 / 年

在宅勤務メインになって音楽鳴らしながら作業できるようになったのだけど、毎回聞きたい曲を調達してってのが面倒になったので課金を始めた。

継続

マネーフォワードME 5300円 / 年

安定。2年目なので年単位の比較ができるようになった。自前スプレッドシートと併用してるけどそろそろこれ一本にしてもよさそう。

Apple Developer Program $99 / 年

iOSアプリ開発のお仕事をやるケースがあるので。土日にお家で検証する時に役立った。

Amazon Prime 4900円 / 年

Amazonカードをメインに使わなくなったし通販はヨドバシが多くなったのだけど、自粛生活でPrime Videoに大変お世話になった。Prime Readingもたまに見る。

dマガジン 440円 / 月

今年もお世話になった。コスパいい。

Evernote Plus 3100円 / 年

メモツールとしてはあんまり活用できてないけど、Twitterの投稿保存したり過去のメモを参照する時に使ってるので悩ましい。

Google One 2500円 / 年

Google Driveから名前が変わった。

To Me Card 2200円 / 年

自粛生活で通勤で電車乗ることは少なくなったけど、なんだかんだ電車乗ったときにポイント貯まるので年会費は余裕でペイできている。

日本経済新聞Wプラン 5900円 / 月

実家と折半継続。もうそろそろ電子プランかな...。

IntelliJ IDEA Ultimate Personal 11110円 / 年

あんまり使わなかった...。

お名前.com 4224円 / 3年

面倒なので3年プランで買った。

Nintendo Online 2400円 / 年

去年載せ忘れてた。スマブラ、あつ森、桃鉄でお世話になった。

NHK 24770円 / 年

これも去年載せてなかった。値下げしてくれ。

新宿御苑年間パスポート 2000円 / 年

500円に値上がりしたけど年パスは据え置きなので4回で元が取れるようになった。コロナであんまり行かなくなったけどまた行きたいな。

1月分だけ課金したもの

ニコニコ動画 550円/月

iOSDCでタイムシフト予約するためだけに1月分だけ課金した。

FOD 976円/月

アンサングシンデレラ見逃したので1月分だけ課金した。

WindowsからApp Store Connectにipaファイルをアップロードする

ipaファイルをApp Store Connectへアップロードする場合、Xcode上でAcrhive後にそのままアップロードする方法と、macOSアプリとして配布されているTransporter というアップローダーツールを使う方法があります。

Transporter

Transporter

apps.apple.com

このTransporterについて詳しく調べていたら、どうやらjavaベースのCLIツールもあってしかもLinuxWindows向けも用意されていることが判明しました。

help.apple.com

What is Transporter?
Transporter is Apple’s Java-based command-line tool for large catalog deliveries. You can use Transporter to deliver your pre-generated content, in a Store Package, to the iTunes Store, Apple Books, and App Store.
...
(中略)
Transporter includes the following features:

An easy-to-use, out-of-the-box installation package, including installers for macOS, Microsoft’s Windows, and Red Hat Enterprise Linux.
...

iTunes StoreApple Booksとあるのでメディア・コンテンツのアップロードツールっぽいですが、App Storeへのアップロードもサポートしているようです。

iOSアプリの開発にはmacOSは必須ですし、App Store Connectへのアップロードには当然macOSが必要だと思ってたらWindowsでもLinuxでもアップロードできるんですね。

ということで今回はこのTransporterのCLIツールを使ってWindowsipaファイルをアップロードする方法をまとめてみます。

TransporterをWindows上でインストールする

マニュアルの Install Transporter on Windowsに従ってexeをダウンロードして、実行するとダウンロードコマンド一式が落ちてきます。

'C:\Program Files (x86)\itms というところに iTMSTransporter.cmd があるので、これをPowerShell上で実行すればよさそうです。

PS C:\Users\xxxxxx> & 'C:\Program Files (x86)\itms\iTMSTransporter.cmd' -help
[2020-12-26 13:32:18 JST] <main>  INFO: Configuring logging...
[2020-12-26 13:32:18 JST] <main>  INFO: Logging level set to eXtreme
[2020-12-26 13:32:18 JST] <main>  INFO: Transporter is searching for new software components.
[2020-12-26 13:32:18 JST] <main>  INFO: INFO: using cached repository.xml file.
[2020-12-26 13:32:19 JST] <main>  INFO: Update check complete.
[2020-12-26 13:32:21 JST] <main> DEBUG: Attempting refresh of configuration data from https://contentdelivery.itunes.apple.com/transporter/Defaults.properties
[2020-12-26 13:32:21 JST] <main> DEBUG: Configuration refresh successful.
[2020-12-26 13:32:21 JST] <main> DEBUG: Saving configuration to local path: C:\Users\xxxxxi\.itmstransporter\Defaults.properties
usage: iTMSTransporter [-help <arg> | -info | -m <arg> | -version]   [-o <arg>] [-v
       <arg>]  [-WONoPause <arg>] [-Xmx4096m]
iTMSTransporter : iTunes Store Transporter 2.1.0
 -help <arg>        Show this help.  If a mode value is specified, show help specific
                    to that mode.
 -info              The -info option should be used by itself and returns the
                    copyright notice and acknowledgements.
 -m <arg>           The -m option specifies the tool's mode.  The valid values are:
                    verify, upload, provider, diagnostic, lookupMetadata,
                    createArtist, lookupArtist, status, statusAll,
                    createMetadataTicket, queryTickets, generateSchema, transferTest,
                    downloadMetadataGuides, listReports, requestReport
 -o <arg>           The -o option specifies the directory and filename you want to use
                    to log output information.  By default, Transporter logs output
                    information to standard out. If you specify a filename,
                    Transporter logs the output to the specified file, as well as to
                    standard out.
 -v <arg>           The -v option specifies the level of logging.  The five values
                    are: off, detailed, informational, critical, eXtreme.
 -version           The -version option should be used by itself and returns the
                    version of the tool.
 -WONoPause <arg>   The -WONoPause option is only valid on Windows and its value can
                    be 'true' or 'false'.  If an error occurs during script execution,
                    the process idles because the message 'Press any key...' is
                    displayed on the console and the system awaits a keypress. To
                    avoid this behavior, set this property to true
 -Xmx4096m          Specifies that you want to change the Java Virtual Machine's (JVM)
                    allocated memory by increasing the JVM heap size.  By default,
                    Transporter uses a 2048MB heap size. You can use the -Xmx4096m
                    option to specify a 4-gigabyte (GB) heap size. Apple recommends,
                    if needed, increasing the heap size to 4096MB by specifying the
                    -Xmx4096m (or -Xmx4g) option and adjusting as needed.
[2020-12-26 13:32:21 JST] <main> DBG-X: Returning 0

今回はApp Store Connectへのアップロードなのでmodeとしてはuploadを使えばよさそうです。

-u-pオプションでApp Store Connectへのクレデンシャル情報を設定するようです。

アップロードするipaファイルパスの指定は -assetFile オプションを使うようで、さらにLinuxWindowsの場合は-assetDescriptionオプションをつけろと書いてあります。

App uploads for macOS, Linux, and Windows: Specifies the directory and filename for the app source file (.pkg or .ipa). For Linux and Windows, -assetDescription is required.

なんじゃこのファイルと思ったらArchiveをExportするときに生成するファイルのようで、ExportOption.plistファイルに指定しておけばよさそうです。

https://help.apple.com/xcode/mac/current/#/deva1f2ab5a2

ipaファイルを作成する

適当なサンプルアプリをmacOS上で作ってipaファイルを配布用の証明書で署名し、Exportします。

ExportOption.plistファイルに以下のようにgenerateAppStoreInformationをセットするとAppStoreInfo.plistというファイルが生成されました。

<dict>
        ...
    <key>generateAppStoreInformation</key>
    <true/>
</dict>

設定の詳細はこちら。

qiita.com

生成したipaファイルとAppStoreInfo.plistファイルをWindowsに持っていきます。

Windows上でTransporterのコマンドを実行してみる

いよいよWindows上でTransporterコマンドを実行してみます。

PS C:\Users\xxxxxx> & 'C:\Program Files (x86)\itms\iTMSTransporter.cmd' -m upload -assetFile .\Desktop\sample.ipa -u xxxxx
  -p xxxxxx -assetDescription .\Desktop\AppStoreInfo.plist -v eXtreme

実行してみると、アップロード処理に失敗して以下のようなエラーが発生しました。

[2020-12-26 13:46:24 JST] <main> ERROR: Sign in with the app-specific password you generated. If you forgot the app-specific password or need to create a new one, go to appleid.apple.com (-22938)

どうやらここで指定するパスワードはApple IDのパスワードではなくてapp-specific passwordというのを指定するようです。

Transporterのドキュメントにも書いてありました。二段階認証を設定しているアカウント向けのアクセストークン相当のもののようです。

Two-factor authentication

If you have enabled two-factor authentication on your account, you must create an app-specific password, as described in Using app-specific passwords. Using an app-specific password increases the level of security and ensures your Apple ID password won’t be collected or stored by third-party apps.

発行方法はこちらに書いてありました。

support.apple.com

Apple IDの設定画面でapp-specific passwordを生成し、設定して再度実行すると無事アップロードが成功しました。

PS C:\Users\xxxxxx> & 'C:\Program Files (x86)\itms\iTMSTransporter.cmd' -m upload -assetFile .\Desktop\sample.ipa -u xxxxx
  -p xxxxxx -assetDescription .\Desktop\AppStoreInfo.plist -v eXtreme

今回は試しませんが、おそらく似たようなやり方でLinuxからもアップロードできるでしょう。

まとめ

WindowsでもTransporterのコマンドラインツールを使えばApp Store Connectへアップロードできることがわかりました。

政治的にmacOSが使えなかったり購入できなくて「どうしてもWindowsでできないのか」と聞かれた時にはぜひこのやり方を紹介するとよいでしょう。

個人的にはXcodeやTransporter使った方が楽なので、macOSのマシンを1台購入することをおすすめします。

FlutterにおけるPluginとの付き合い方 #flutter

本記事は Flutter #1 Advent Calendar 2020 の12/13の記事です。

qiita.com

Flutterでアプリ開発を行う時、 pub.dev で公開されているプラグインを使うことで特定の実装やネイティブ実装を代用することができます。

このときそのまま公開されているプラグインを使うか、自作でMethodChannelとネイティブコードで実装するか選択することができます。本記事では私が普段どのような考え方で判断しているかを一例として紹介したいと思います。

なお今回はWebやDesktopは含めず、iOSAndroidアプリに絞った話になります。

Flutterにおけるプラグイン

Flutterにおいてプラグインを利用する場合、pubspec.yamlに利用したいパッケージ名を記入した状態でflutter pub getを実行することで利用することができます。

flutter.dev

プラグインを使うメリットとデメリット

Flutterにおけるプラグインを使うメリットとデメリットを上げてみると以下のものが考えられます。

  • メリット
    • プラグインで代用することで実装を省略でき開発を高速化できる
    • iOSAndroidのネイティブ実装の知識がなくてもネイティブ機能が利用できる
  • デメリット
    • 自分の利用したいインターフェースや機能の実装になってない場合がある
    • プラグイン同士で含まれるライブラリが競合する場合がある
    • プラグインにバグが含まれている可能性がある
    • メンテナンスが放置されてFlutterのバージョンアップの足かせになる場合がある

まずメリットですが、そもそもFlutterという技術選択をした理由に開発の高速化が念頭にあることが多いと思うので、プラグインを利用することでさらなる高速化が望めます。 またWebViewやカメラなどのOSのネイティブ機能を使った機能を実装する場合は本来であればiOSAndroidの知識が十分に必要になりますが、プラグインを利用することでFlutterの知識があれば機能を実装することができます。

一方でデメリットでいうと、プラグインが提供するインターフェースが必ずしも自分が使いたい形式になっていなかったり、必要な機能を実装していないケースがあります。また複数のプラグインを組み合わせて使う場合、バージョンやライブラリの競合が起きるケースもあるでしょう。 OSSとして個人が公開しているものにはバグが含まれている可能性もあります。また利用し始めた当初は問題なかったけど、時間がたってからメンテナンスが放置されてFlutterのバージョンアップ時にエラーになる、なんてケースも考えられます。

これらのメリデメを踏まえてプラグインを使うべきか自力で実装すべきかをどのように考えていけばよいかを考察します。

プラグインを利用するか、自力で実装するか

まずプラグインを利用するか自力で実装するかについては答えはなく、プロジェクトの状況に合わせて最適な選択をするのがよいです。

iOSAndroidそれぞれ個別の実装している余裕がなかったり、そもそもネイティブ実装ができるメンバーがチームいない場合は結果的にプラグインを積極的に利用することになると思います。

一方で公開されているプラグインが提供する機能では不十分だったり、そのアプリが提供するコア機能となる部分として自由なカスタマイズをしたいケースであればプラグインを利用せずに自力で実装することになると思います。

FlutterではMethodChannelを使うことでネイティブで実装した機能を画面、部分的な画面、関数単位で実行することができます。

flutter.dev

プラグインの選定基準

次にプラグインの選定を見ていきます。

ネイティブの機能を利用するプラグインはある程度は公式が用意してくれているので、まずはそれを使って期待する使い方ができるかどうかを確認してみましょう。

github.com

Firebaseを利用する場合も公式が利用を推奨しているプラグインから選ぶとよいでしょう。

github.com

medium.com

3rd partyが公開しているSDKをラップしたプラグインを利用する場合もまずは公式が出しているものを見てみるとよいです。

その他のプラグインを利用したい場合は以下の観点で選ぶとよいでしょう。

  • 評価が高く、利用実績が豊富であること
  • ドキュメントが充実していること
  • ライセンスの自由度が高いこと
  • 更新が活発であること

利用を検討しているプラグインについては、ネイティブの知識がある程度必要になりますが、なるべく中身のソースコードも読むようにしましょう。ソースコードを読んでみて、これなら自分でも実装できそうだ、と判断したら自力での実装で切り替えるのもありだと思います。

プラグインへの依存と付き合っていく

自身のプロダクトにプラグインを利用するという選択をした場合、そのプラグインの依存関係を常に念頭にして追加開発・運用していく必要があります。

Flutterのバージョンアップや新OSが出たときに利用しているプラグインがきちんと対応できるのか、仮に対応できない場合はパッチを当てるのか、別のプラグインを検討するのか、利用をやめて自力で実装し直すのかなどを定期的に見直すようにしておくとよいです。

FlutterはそもそもそれだけでiOSAndroidを横断したフレームワークであるため、プラグインも含めるとかなり複雑な構成をとることとなります。そのため依存関係を正しく把握していないとあっという間に負債化してしまう可能性があるので注意が必要です。これについては以前ブログにまとめたのでそちらも見てみてください。

takamii.hatenablog.com

takamii.hatenablog.com

最近でいうと、長らくWebViewのプラグインとしてflutter communityのものがよく利用されてきましたが、ようやく公式のWebView Pluginが正式公開されましたね。

github.com

github.com

flutter communityの方のプラグインはもうメンテされないようなので新しい方に移行していく必要があります。

プロジェクトの状況にもよりますが、私が以前いたプロジェクトでは初期リリースはプラグインを積極的に活用して開発効率を重視し、追加開発フェーズである程度落ち着いてきたら pubspec.yamlを定期的に見直して少しずつ自力実装に移行していく、という戦略を取っていました。

まとめ

プラグインの利用によってその機能の実装を省略できる一方で、プラグイン自体のメンテナンスが放置されていて本体のバージョンアップの足かせになり開発スピードが落ちてしまった、という経験をWordPressやJenkinsなどで経験したことがある人もいるのではないでしょうか。

Flutterにおいてもそのようなことにならないように、プラグインの利用を検討するときはどのような観点で自力実装と使い分けているかをプロジェクト全体の方針として明確にし、利用しているプラグインを定期的に見直すようにしておくとよいでしょう。