takathemaxの日記

自分の生活を便利にしてみたこととか、勉強したことの記録

マルチウィンドウ サポートの無効とtargetSdkVersion

ストアに出してるアプリの場合このようなことが起こらないと思うけど、 resizeableActivity=false で、targetSdkVersionが25以下だとAndroid 10以上の端末でレターボックスが表示される場合がある

targetSdkVersion=25 targetSdkVersion=26

なぜかというと、Android Developerの最大アスペクト比を宣言するによると、targetSdkVersionが25以下の場合、システムによって16:9で制限されちゃうから。

このままだと、一部端末でUIのタッチポジションがずれたりとかもあったので修正をしたほうがいい。 修正方法は今のところ以下の2つ。

  • targetSdkVersionを26以上にする
  • resizeableActivity=true にする
    • applicationじゃなくて特定のActivityだけに適用するのもありかも

ストアで公開するものじゃなくてもtargetSdkVersionはこまめに上げないとね(自戒)

参考リンク

Android Developer
Declare restricted screen support  |  Android Developers

今回作ったサンプルプロジェクト(本当たいしたことないけど)
https://github.com/takathemax/resizeable-activity-sample

新規でアプリを作るのでminSdkVersionをいくつにするか考えた

最近、個人で新規のAndroidアプリを作る際に「minSdkVersionをいくつにするか」を考えたので、備忘がてら残しておきます。

参考にしたもの

developer.android.com

smatabinfo.jp

はじめは公式の情報である Android Developers のみを参考にしようかと思いました。
しかし、作ろうと思っていたアプリは日本国内向けであるのと、情報が少々古い(2019年11月時点でAndroid 10のシェアの情報なし)ので、もう少し日本国内に限った情報が欲しいと感じ、スマタブさんもみてみることにしました。

スマタブさんのデータを見ると、Android Developersのデータと様子が違うなと思ったので、念のためどのようにこのシェア情報を入手しているのかと気になったので、こことかを読んでみました。
「情報系ダウンロードアプリ」というのが何を差しているのかはわかりませんでしたが、「データが新しいものであること」、「日本国内のデータ」であることからスマタブさんの方も参考(というかほぼこれ)にminSdkVersionを決めることにしました。

シェアの情報を見比べてみる

Android Developersで公表されている数値とスマタブさんのデータを見比べてみると、特徴が違うように見えます。

Android DevelopersのほうではLollipopやMarshmallow、Nougatで半分近くのシェアを誇っておりPieは1割ほどしかありません。
ですが、スマタブさんのデータではLollipopやMarshmallow、Nougatは3割ほどで、Pieは半分近くあります。

そもそもデータの取得期間の違いがありますし、2つのサイト間で、シェアの定義やどういうデータの場合にアクティブと見なしているのかなどの違いがあるかもしれないのですが、日本の場合スマホの買い替えが活発で新しいバージョンに移っていきやすいのではないかと思いました。

minSdkVersionを決定する

主にスマタブさんのデータをみて、23に決めました。 既存のアプリですと21や22というのも多いと思うのですが、

  • わずか数%のユーザになるかどうか分からない層に工数をかけるよりかは、できるだけminSdkVersionをあげて開発しやすい環境を整えたほうが結果的にユーザのためになる(と思う)

  • スマタブのデータでは93%ほどを占めているので、十分じゃないか(と思う)

という理由から思い切って23に設定してみました。

minSdkVersionを23にしているというのをあまり聞いたことがなく、何か見逃しているかもしれないので少し心配ですが、個人アプリだし失敗した場合は業務に生かせばいいやと思っております。

他にうちはこういう風にやってるよーというのがありましたら、教えていただければm(* )m

GoogleService-Info.plistをSchemeで切り替える

普段はAndroidアプリの開発が主だけど、最近iOSアプリの開発も兼任することになった。(初のiOSアプリの開発!)

GoogleService-Info.plistをSchemeで切り替えたいなと思って、いろいろ先人たちの知恵を調べてみると、Run Script で切り替える方法があるみたい。

自分の場合、以下のようなスクリプトでやってみた。

cp "${PROJECT_DIR}/${PROJECT_NAME}/Config/GoogleServiceInfoPlist/${CONFIGURATION}/GoogleService-Info.plist" "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/GoogleService-Info.plist”

ディレクトリをSchemeごとに作り、ディレクトリ名をScheme名と同じにして 配下にGoogleService-Info.plistを置く感じ。 条件分岐する必要がないからいいかなと思ったけど、もしかしてもっとスマートな方法があるのだろうか。

clasp小ネタ

VM(VirtualBox+Vagrant)上のUbuntuで遊んでいて「claspを入れたいなー」と思ったら手間取ったのでメモ。 ゲストOSではCUIしか使わないという時に役にたつかも。

claspを入れる

npm i @google/clasp -g

claspでログイン

ここでハマったのだけど、以下のコマンドを入れることで解決。

clasp login --no-localhost

すると↓のような長ーいURLが吐かれるので、コピペしてホストマシンのブラウザで開く

https://accounts.google.com/o/oauth2/v2/auth?access_type=offlinxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxほにゃららー

Success codeとやらをもらう

いつもどおりアカウントを選択して、、、とやって行くと、以下のようなページに遷移する f:id:maxtaka:20181030221930p:plain

「このコードをコピーして〜〜〜」と言われるので、コピーする。

Success codeとやらを入力

ターミナルに戻り、

Enter the code from that page here:

の所にさっきコピーしたSuccess codeを入力

~/.clasprc.jsonができる

あとはいつも通り。

Nature Remoをポチった

Nature Remoをポチった

Nature Remo

Nature Remo

まだよく調べてないけど、これでリビングの電気とTVとエアコンをGoogle Homeで管理してみようかと思う。

エアコンはスケジューラみたいなやつで勝手についたり、消したりしてるけど他のも自動で勝手にやっといて欲しいなーと思って買った。

仕組みができたらまた投稿しようかと思う。

いっぱいバグを出したので反省

今年一月よりAndroidエンジニアとして開発に携わっているが、いっぱいバグを出してしまった。

反省というか、今日上司に相談しアドバイスをもらったのでメモをのこそうかと思う。

バグの分類

自分がだしたバグがどういう種類のバグかを認識する。 人によりいろいろ意見があると思うけど、自分は今日上司の方からいただいたアドバイスをもとに以下の分類で、今後振り返っていこうと思う。

  • 仕様漏れバグ(あー忘れてたわーてやつ)

    • 仕様漏れ。自分の甘さを恥ずべし。
  • 実装バグ(ほーそーなんだーてやつ)

    • 「あーこれってNullになることあるんだ。。。」というライブラリや言語仕様への知識が足りないことも原因のバグ。ユニットテスト等のテストケースで排除できるかもしれない。
  • 勘違いバグ(うっかりしてたわーてやつ)

    • 仕様を勘違いしていたことによって発生したバグ。 仕様漏れバグと似ているが、仕様作成者とのコミュニケーション不足にも起因する。

     なにはともあれ、今のプロジェクトがひと段落したら具体的な策を練らねばいかんですな

はー正直結構落ち込んだ

積み本

ブログを書こうという「気持ち」はありながら、前回の記事から半年弱ほど経ってしまった。

もっと気軽に書いちゃおうかなーと思って、今読もうと思っている(途中まで読んでいる)けど、読むのが停滞している本をまとめてみた。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

はじめてのパターン認識

はじめてのパターン認識

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

Kotlinイン・アクション

Kotlinイン・アクション

Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版

Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版

30日でできる! OS自作入門

30日でできる! OS自作入門

ほかにもちょっとあるけど、以上の本は時間を見つけて最優先で消化していく予定。

社内でお昼に勉強会をしていて、そこで読んだ内容を定期的には発表するという方法で、消化しようかと思ってた。だけど、実際にやってみると発表資料作るのに時間がかかって気軽にアウトプットするにはちときつい。

さて、どのように定期的に積み本を消化していくべきか。。。。