SQLDelight 1.0 使い方 #1

バージョン1.0アナウンスされています。

Announcing SQLDelight 1.0 – Alec Strong – Medium

神も。


データベース周りにRoom他のライブラリをご利用の方も試してみてはどうでしょうか。

square/sqldelight: Generates typesafe Kotlin APIs from SQL

SQLDelight は、以下のようなSQLステートメントからデータベース、テーブル、タイプセーフなAPIを作成できます。

HockeyPlayer.sq


CREATE TABLE hockeyPlayer (
  player_number INTEGER NOT NULL,
  full_name TEXT NOT NULL
);

CREATE INDEX hockeyPlayer_full_name ON hockeyPlayer(full_name);

INSERT INTO hockeyPlayer (player_number, full_name)
VALUES (15, 'Ryan Getzlaf');

selectAll:
SELECT *
FROM hockeyPlayer;

insert:
INSERT INTO hockeyPlayer(player_number, full_name)
VALUES (?, ?);

定義したAPIは以下のように利用できます。



val driver = AndroidSqliteDriver(Database.Schema, this, "test.db")
val database = Database(driver)
val playerQueries = database.hockeyPlayerQueries

// selectAll
println(playerQueries.selectAll().executeAsList())
// Prints [HockeyPlayer.Impl(15, "Ryan Getzlaf")]

// insert
playerQueries.insert(player_number = 10, full_name = "Corey Perry")
playerQueries.insert(player_number = 999, full_name = "フグ田 サザエ")

// selectAll
println(playerQueries.selectAll().executeAsList())
// Prints [HockeyPlayer.Impl(15, "Ryan Getzlaf"), HockeyPlayer.Impl(10, "Corey Perry")]

利用前の build で build/generated/ 以下に書き出されますが、gradle のバージョンが限定されるように見えました。何か設定が足りないのかもしれません。

gradle-wrapper.properties


distributionUrl=https\://services.gradle.org/distributions/gradle-4.10.3-all.zip

実際サンプルを動かす風景。



利用方法など今回バージョン1.0 で変わっているようなので、

数回に渡って実装に利用できるとこまでやってみたいと思います。

(つづく...)

SQDelight の データベースバージョン
Reddit: Announcing SQLDelight 1.0 – Alec Strong – Medium
SQLDelight 1.0 使い方 #2

新「元号」の西暦へ変換方法と「Build.VERSON_CODES」

今回もまた、和暦と西暦の変換の方法とか。

昭和：元号に25を足すと西暦。
平成：元号から12を引くと西暦。
？？ : 元号に18を足すと西暦。

面倒ですね。

一方、Android OS (API) バージョンの呼び方。


19 KITKAT                 4.4 - 4.4.4   KitKat
21 LOLLIPOP               5             Lollipop
22 LOLLIPOP_MR1           5.1           Lollipop
23 M                      6             Marshmallow
24 N                      7             Nougat
25 N_MR1                  7.1           Nougat
26 O                      8.0           Oreo
27 O_MR1                  8.1           Oreo
28 P	                  9.0           Pie

Android バージョンやコードネームなどからのシェアの一覧取得


同じ意味なのに別の呼称があることは、少し考えての変換が必要になる。

いらなくね? 元号とかコードネームとか。

まあ、コードネームを付けることで話題として取り上げやすくはなるわな。

キャバ嬢の「平成生まれ」をうれしがってた時もあったけどなあ。

Android OS バージョン確認方法 (platform versions)

The Unicode Blog: New Japanese Era

本物「Jake Wharthon」さん、偽物「Jake Whaarton」になりすます

jitpack で配布しているライブラリに不必要な怪しい通信処理を入れて

Bintray -> jcenter() 経由で同じアーティファクトidで配布してる「Jake Whaarton」さん。

これは、神と呼ばれるJakeWarthonさんの偽物です。

Jake Wharthon → 本物
Jake Whaarton → 偽物

少し話題になってましたね。

A Confusing Dependency

A Confusing Dependency : androiddev

すると、本物JakeさんのTwitterが!!

Jake Whaarton(@JakeWharton)さん | Twitter

なりすましてます、本物が偽物に。

この話を、解説しています。

アーティファクトの整合性の話は別にして、jcenter() を常に最後に置くだけでなく、mavenCentral() をそれらの前に置くことも必要です。
JCenter と Bintray は、信頼できるアーティファクトホストではありません。理想的なのはそれらから何も取得しないことです。

上から読んでいくリポジトリ群指定の最下位にオープンすぎる jcenter() を置くべし、と言っています。


repositories {

  //...
  mavenCentral()
  jcenter()
}

しかし、ワロタ。

android - Why does the Google maven repository exist and when should I use it? - Stack Overflow

Gradleが参照するリポジトリの優先順位について - Qiita

Firebase In-App Messaging は実装不要。

言い換えると、「コードの記述」が不要。

できることは、Firebase 管理画面からアプリ上にプッシュしてダイアログを出せるというもの。

アプリのリソースでの作業は、 build.gradle の以下の記述追加のみ。


dependencies {
  // ...
  implementation 'com.google.firebase:firebase-inappmessaging-display:17.0.0'
  implementation 'com.google.firebase:firebase-core:16.0.1'
}

Firebase アプリ内メッセージングを使ってみる  |  Firebase

あとは、Firebase のコンソールで設定する。

表示させた各ダイアログ(ボタン)をタップしたときのアクションはURLでセットしておく。

あとは表示させるタイミングを設定画面からアレコレやってみるといい。

なんせ、2行の追加だけだもの。

これで撒いといてもいいんじゃね?

ベータだけど。

YouTubeに縦長動画をどうアップするべきか?

スマホの画面動画を公開する場合にどのようにすると視聴者が見やすいか、という試行錯誤の話。

パソコンでなく、スマホ上でブラウザで見るのではなく、スマホ上でYouTubeアプリで見る場合。

その視聴方法が一番多いと思うので。

 

考え方

縦長動画に対応した今のYouTubeで公開される動画の縦横比は、

9:16 か 16:9。

今どきのスマホ画面は縦横比 2:1 程度が主流なので 2:1 で固定して考える。

【iPhone/Android】スマホ解像度早見表 - 2018年度版（2008～2018年） - marronブログ

これら、YouTubeの仕様とスマホ画面のサイズとアップする動画のキャンバスサイズを組み合わせて考えてみる。

 

そのまま縦長動画をアップ

縦長動画に対応したYouTubeにそのまま縦長動画をアップする。



スマホからYouTubeアプリで見る👉 縦長動画そのまま - YouTube
*スマホからYouTubeアプリ上の表示され方は、この「👉」リンクから確認できます。

パソコンやスマホブラウザで見ると9:16の枠入りだが、スマホYouTubeアプリで見ると縦長。

しかし、端末の画面サイズによっては、最初の表示で上下が隠れたりもする。

 

YouTubeの横長枠に入れる

YouTubeの横長9:16枠に縦長動画を入れた動画をアップする。




スマホからYouTubeアプリで見る👉 YouTube横長枠に縦長動画 - YouTube

フル画面にしたとしても90度回転させられるウザさもあるし、動画内のスマホ画面が相対的に小さくなり見づらい。

 

YouTubeの横長枠に90度回転して入れる




スマホからYouTubeアプリで見る👉 YouTubeの横長枠に90度回転して入れる - YouTube

スライダー操作などYouTubeアプリの認識が一致しない。

 

YouTubeの画面遷移を考慮する

ユーザーが縦長の動画でより多くのメッセージを見られるよう、動画の上部10％と下部25％には重要なメッセージを表示しないよう推奨されています。

上10%、下25%を避けて縦長動画を縦長16:9枠に入れた動画をアップ。




スマホからYouTubeアプリで見る👉 上10%下25%避けて縦長動画を縦長16:9枠に入れた動画 - YouTube

アップしてから実際スマホで見てみないと分からないことは多い。

これがベストか?

 

元画像を ffmpeg でパディングする

YouTube推奨する縦長サイズ 1080x1920 で考える。

元の動画サイズは縦長の16:9でなくともよい。

上下パディングを除く、1080x1248 のセンターに元動画を埋め込む。


ffmpeg -i input.mp4 \
-vf "scale=1080:1248:force_original_aspect_ratio=decrease,pad=1080:1248:(ow-iw)/2:(oh-ih)/2" \
1080x1248.mp4

それに、上下パディングを付けて、1080x1920のサイズにする。


ffmpeg -i 1080x1248.mp4 \
-vf "pad=width=1080:height=1920:x=0:y=192:color=black" \
1080x1920.mp4

しかし、パソコンやスマホブラウザで見ると無駄なパディングです。

 

まとめ

縦長動画の需要と供給が増えるのは間違いなさそうだけど、スマホ画面は横固定ベースの縦スクロール。

画面自体の拡大化と含めて、各動画サービスの対応とか、サムネ縦横比とか。

視聴側の多様化にプラットフォームや供給側がどう合わせていくべきか。

TwitterやFacebookに貼られたときのサムネ表示のされ方などもあるし。

👉 【吉報】Twitterアプリ 縦長画像 最大125% に対応 

👉 絵文字 (えもじ) パック - Google Play のアプリ



👉 dyn4j の実力を JetpackCompose wrapper Physics Layout で思い知る hatena-bookmark