Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Androidアプリ開発のいろは
Search
matsurihime
May 19, 2017
Technology
0
310
Androidアプリ開発のいろは
社内勉強会にて講演したスライドです。社名等が出ている部分は削除してあります。
matsurihime
May 19, 2017
Tweet
Share
Other Decks in Technology
See All in Technology
複数の LLM モデルを扱う上で直面した辛みまとめ
kazuyaseki
1
230
依存ライブラリはどこに?
takesection
0
110
継続的テストモデルを実現するためにスリーアミーゴスを用いた10Xでのシフトレフトの事例
nihonbuson
3
160
Elementaryを用いたデータ品質の可視化とデータ基盤の運用改善
10xinc
6
1.4k
関数型DDDの理論と実践:「決定を遅らせる」を先につくり、 ビジネスの機動力と価値をあげる
knih
2
470
Challenges - Open Farming Hackdays 2024
loleg
0
540
エンジニアブランディングチームの KPI / KPI's of engineer branding team
chaspy
1
140
技術広報経験0のEMがエンジニアブランディングをはじめてみた
coconala_engineer
1
130
Getting started with controlling LEGO using Swift
hcrane
0
130
オブジェクト指向宗教史
tanakahisateru
13
12k
Kubeflow Pipelines v2 で変わる機械学習パイプライン開発
asei
4
340
これまでのキャリアとこれからMLエンジニアとしてどう動くか
masatakashiwagi
0
300
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
266
39k
Infographics Made Easy
chrislema
237
18k
How STYLIGHT went responsive
nonsquared
92
4.7k
jQuery: Nuts, Bolts and Bling
dougneiner
57
7.1k
Practical Orchestrator
shlominoach
180
9.7k
The Illustrated Children's Guide to Kubernetes
chrisshort
28
46k
Rails Girls Zürich Keynote
gr2m
91
13k
Designing the Hi-DPI Web
ddemaree
275
33k
Being A Developer After 40
akosma
56
580k
Producing Creativity
orderedlist
PRO
335
39k
The Cost Of JavaScript in 2023
addyosmani
13
3.7k
Principles of Awesome APIs and How to Build Them.
keavy
119
16k
Transcript
Androidアプリ開発のいろは
こんな人向けに話をします ・Androidアプリを作ってみたいけどどうしたらいいのかわからない人。 ・Androidアプリを作ったことはあるけどいまいち仕組みはよく分からずに作っている人。 ・Androidアプリをバリバリ作っているけどJava+SQLite+HttpClientしか使ったことがない人。 ・暇だったので来た人。
Androidについて ・Googleが提供するモバイル向けOS ・最新バージョンは7.1 Nougat ・言語は基本的にJavaを使用する(後述) ・IDEとしては(Javaが書ければなんでもOKだが)Android Studioを用いるのが便利 ・様々なデバイスで動く(スマホ、TV、カーナビ、スマートウォッチ、・・・)
Androidの歴史 バージョン コードネーム リリース日 概要 Beta 2007/11/5 1.0 (Alpha) 2008/9/23
最初のAndroid端末「HTC Dream」 1.1 (Beta) 2009/2/9 1.5 Cupcake 2009/4/27 日本初のAndroid端末「HT-03A」 1.6 Donut 2009/9/15 iPhone3GS 発売 2.0/2.1 Eclair 2009/10/26 2.2 Froyo 2010/3/20 iPad発売 2.3 Gingerbread 2010/12/6 iPhone4発売 ガラスマの台頭 3.0/3.1/3.2 Honeycomb 2011/2/22 2.x系列と並行なタブレット向けOS
Androidの歴史 ・コードネームはお菓子の名前 ・近年はiPhoneの発売(iOSのメジャーアップデート)を意識? バージョン コードネーム リリース日 概要 4.0 Ice Cream
Sandwich 2011/10/18 iPhone4S発売 4.1/4.2/4.3 Jelly Bean 2012/7/9 iPhone5発売 4.4 KitKat 2013/10/31 iPhone5s発売 5.0/5.1 Lollipop 2014/11/12 iPhone6発売 64bit対応 6.0 Marshmallow 2015/10/5 iPhone6s発売 7.0/7.1 Nougat 2016/8/23 iPhone7発売 8.0 O (Oreo?) 2017/3/21(dev) 開発中
デバイスの進化 NTT docomo HT-03A FREETEL SAMURAI 極2 OS Android 1.5
Cupcake(updated to 2.2) Android 6.0 Marshmallow(will update to 7.0) CPU Qualcomm MSM7201A@528MHz (1Core) MediaTek Helio X20
[email protected]
(10Cores) RAM 192MB 4GB ROM 512MB 64GB ディスプレイ 3.2インチ液晶 ハーフVGA(320*480) 5.7インチ液晶 WQHD(1440*2560) カメラ 約320万画素CMOS 約1600万画素 4K対応 発売日 2009年7月10日 2016年12月22日
デバイスの進化がもたらしたこと ・CPU/GPU性能の向上→VRやAR、3DCGなどをより気軽に応用できるように ・メモリ容量増大→バックグラウンドプロセスが予期せずKillされることが減少 →高負荷時のクラスアンロード頻度減少=staticフィールドが比較的安全に
シェアの増加 2017年3月時点で Android 37.93% Windows 37.91% iOS 13% OSX 5%
→PC・モバイル合わせてのトップシェア
4つのコンポーネント ・アクティビティ ・サービス ・コンテンツプロバイダ ・ブロードキャストレシーバ
アクティビティ ・1UI(1画面)を束ねるコンポーネント ・他のアプリから任意のアクティビティを指定して開始することができる ・Activityクラスのサブクラスとして実装される
サービス ・長時間操作やリモート処理のためにバックグラウンドで動作するコンポーネント ・UIを提供しない ・Serviceクラスのサブクラスとして実装される
コンテンツプロバイダ ・共有アプリデータの管理に用いる ・ファイルシステム、やSQLiteなどの永続性ストレージにアクセス ・ContentProviderクラスのサブクラスとして実装される ・アプリがトランザクションを実行するためのAPI標準セットを実装する →外部DBとの通信で直接SQLを発行するのではなくWebAPI(REST)を経由するのと同じ
インテント ・プログラムが何をしたいかという「意図」や「目的」を渡すと システムがそれを解釈・判断し、適切な機能へ渡してくれる仕組み(非同期メッセージ) 例) 「画像を見たい!」 → ギャラリーアプリの選択肢を提示 ・明示的インテント(Explicit Intents)と暗黙的インテント(Implicit Intents)
呼び出したいコンポーネントの名前を明示的 or 暗黙的に指定する
ブロードキャストレシーバ ・ブロードキャストアナウンス(ブロードキャストされた暗黙的Intent)に応答するコンポーネント 例)画面オフ、バッテリ残量低下、・・・などのブロードキャストIntentを受け取れる ・最小限の処理で or 別スレッドで処理を実装すべき (UIスレッドで実行されるため) →実際BroadcastReceiverはインテント受信時にonReceive()メソッドを実行するだけである。 ・BroadcastReceiverクラスのサブクラスとして実装される
コンポーネントのアクティベート ・アクティビティ・サービス・ブロードキャストレシーバ →インテントによってアクティベートされる - アクティビティ:Intent.startActivity()、Intent.startActivityForResult() - サービス:Intent.startService()(開始)、Intent.bindService()(バインド) - ブロードキャスト:Intent.sendBroadcast()など コンテンツプロバイダ
→ContentResolverからの要求対象となったときにアクティベートされる - コンテンツプロバイダ:ContentResolver.query()
パーミッション ・ユーザーがアプリに対して、様々な機能や情報を利用する権限を与える仕組み 例)連絡先へのアクセス、カメラ機能へのアクセス、ネットワークアクセス、・・・ ・このような機能にアクセスしますよ、と事前に明記し、ユーザーの許可を得る必要がある ・Android6.0以降とそれ以前で大きく仕組みが異なっている
Android 5.x以前 「パーミッションはインストール時にすべて許可される」 ・利点 アプリに必要な権限が全て付与されていることを 前提にロジックを記述できる ・欠点 ルーチンとなってしまい、ユーザー側がちゃんと確認しない ・AndroidManifest.xmlに<uses-permission>タグで記述する
Android6.0以降 (Runtime Permission) 「Normal Permissionはインストール時に許可される」 「Dangerous Permissionは機能利用時に個別に許可される」 ・利点 ルーチンとなってしまった権限許可をユーザーに 意識させ、不要な権限を許可しないよう制御できる
・欠点 開発者は権限の有無を都度チェックする必要あり 権限が付与されなかった場合の処理も考える
まとめ ・Android6.0未満 →インストール時に一括許可 →ユーザも開発者もパーミッション 利用時に意識する必要がない ・Android6.0以降 →機能利用時に個別に許可 →ユーザーも開発者も煩わしさは あるが、権限を詳細に制御できる
ライフサイクル アクティビティとサービス ・Running 実行中の状態 ・Paused 他のアクティビティが起動したときなど、 一時停止している状態 ・Killed 文字通り「Kill」された状態
ライフサイクル管理の難しい所 ・高負荷時にシステムメモリが不足するとonPauseなActivityが自動でKillされてしまう →特にバックグラウンド処理が必要なアプリケーションは試行錯誤が必要 ・Activity単位ではなくApplication単位でも同様にOSによるメモリ管理が働く →アプリケーションがフォアグラウンドに無いといつプロセスがKillされるかわからない ・画面回転や画面消灯で簡単にActivityはKillされる →アプリを閉じたわけでもないのにKillされてしまうので非常に厄介 ・クラスアンロードによりstaticなフィールドが破棄されてしまう →Singletonパターンの利用に問題あり、そうでなくてもstaticな変数を使うの怖い
How to ライフサイクル管理? ・高負荷時にシステムメモリが不足するとActivityが自動でKill、クラスもUnloadされてしまう →各アクティビティがどの状態にいるのかを常に考えた設計 ・Acitivity単位ではなくApplication単位でも同様にOSによるメモリ管理が働く →フォアグラウンド以外で動かしたい場合はServiceを別スレッドで生成し実行する ・画面回転や画面消灯で簡単にActivityはKillされる →Fragment#setRetainInstanceの利用や、再利用したいオブジェクトをBundleに保存するなど ・クラスのアンロードによりstaticなフィールドが破棄されてしまう
→Dependency Injectionでオブジェクトの実装と生成を分離
AndroidManifest.xml ・コンポーネントの宣言(使用するアクティビティやサービス等の宣言) ・コンポーネントの機能の宣言(たとえば最初に起動されるアクティビティである、など) ・アプリの要件の宣言 ・アプリのリソースの定義 ・パーミッションの要求(インターネットアクセス、ストレージアクセスなど) ・最小APIレベルの宣言 ・必要なハードウェア・ソフトウェア機能の宣言(カメラ、GPS、Bluetooth、・・・) ・外部APIライブラリの参照 ・その他・・・
動作確認の難しさ もちろんすべての実機でテストができれば理想だが・・・ ・iOSの場合は端末がiPhoneシリーズのみ。OSのカスタマイズも無い ・Androidの場合は端末が多数存在(使用しているCPUや画面解像度、メモリ搭載量等様々) ・ベンダーによるOSカスタマイズも盛んなため、すべての端末の動作を保証するのは不可能 ではどうする? ・エミュレータを用いたテスト → 様々な仕様のデバイスに対応したエミュレータを用意 ・画面表示はレスポンシブデザインを基本とする(複数解像度対応)
・アルファ版・ベータ版を経た段階的リリースによる修正
AndroidとJava ・Android開発では主にJavaを利用する (厳密にはJava7をAndroid向けにカスタマイズした言語、とでもいうべきか?) ・AndroidのJavaはJVMではなくDalvik VM(5.0以前)やART(5.0以降)で実行される Javaクラスファイルをdex形式に変換して使用する。 Dalvik VM: JVMに比べて低メモリシステムに最適された仮想マシン(32bit) アプリ起動の度に中間コードからネイティブコードへのコンパイルが
行われていたため動作速度や電力消費に悪影響。 ART: Dalvik VMと異なり、予めネイティブコードにコンパイルしておく。(64bit)
Kotlin ・Kotlin - IntelliJ IDEAなどで有名なJetBrainsにより開発されているJVM言語 - 同じJVM言語のScalaやGroovyを強く意識した造り - Javaよりも簡潔で安全な記述を可能とする -
既存資産を活用できる (Javaのソースコードと併用可能、コンバートもある程度自動化) 他にも色々と利点が盛り沢山!
Kotlinは簡潔 ・他のモダンな言語が備えている機能を備える(型推論、関数リテラル、ラムダ式など) →Javaで書くと冗長になりがちなコードもすっきりとし、生産性や可読性が向上する ・高階関数をサポート(関数自体を第一級オブジェクトとして扱える) 【Java】 【Kotlin】
Kotlinは安全 ・(当然ですが)コンパイラ言語なのでコンパイル段階でエラーチェックが可能 ・NULL安全 - Javaの場合はすべての参照型変数がnullを持つことができる → NullPointerException - Kotlinの場合は変数の宣言時にNULL許容型とNULL非許容型を明確に区別し、 適切でない扱いをするとコンパイルエラーとなる
- ?演算子と!!演算子とelvis演算子 → ? 演算子はnullならその後の処理を行なわずnullを返す obj?.getString(“abc”) → !! 演算子は強制的にnullでないとみなして処理をする obj!!.getString(“abc”) → ?: 演算子はnullの場合のデフォルト値を定義する obj?.getString(“abc”) ?: “”
Kotlinは便利 ・トップレベル関数とローカル関数 トップレベル関数: ファイルのトップレベルで宣言された関数 ローカル関数: 関数の中で宣言された関数(外側の変数にアクセス可能) ・スマートキャスト 一度不変な値へのisチェックを行った後は必要に応じて自動的にキャストを挿入してくれる 一度!!演算子を使用した値は、その後もnullでないものとしてnullチェックを省略できる
でもKotlinって本当に使えるの? こんな疑問がありませんか? ・Kotlinがすごいのはわかったけど、本当に最前線の開発で使えるの? ・Java以外でもScalaとかで書けるんならわざわざKotlinでなくてもいいんじゃない? ・プラグイン入れないとAndroid Studio上でまともに書けないんじゃ業務に使えないよ・・・
Google I/O 2017 ・ちょうど日本時間の昨日(5/18)から開催されているGoogleの年次イベント → 色々な発表がありましたが、その中でもAndroidに関する大きな発表が! - なんと、KotlinがAndroidの正式な開発言語になりました!! → Androidの第一級言語はこれまでJavaのみだった
= 初の第一級言語追加 - Android Studio 3.0リリース(開発版: Android Studio 3.0 Canary 1)でKotlinサポート追加!! - Android O のpublic beta配布、及びAndroid O搭載低スペック端末「Android Go」の発表など
実際に作ってみる ・最近業務でバイナリをいじることが多い →2進数・10進数・16進数変換が簡単にできるアプリが欲しい →入力値を変換して出力するだけなのですぐにできそう 既に大量のn進数変換アプリがマーケットに存在しているが、そこは気にしない
開発環境構築(JDK) ・Java Development Kitの導入 →JDK7以上を利用可能ですが、素直に最新版を入れてしまってOKです。 Oracleの公式サイトからOSのバージョンやbit数に合わせてインストーラをダウンロード インストーラを実行し、インストールするだけ ※環境変数の話をすると厄介なので、基本的にはデフォルトのままインストールしましょう
開発環境構築 (Android Studio) ・これも適当にググればでてきます (https://developer.android.com/studi o/index.html?hl=ja#downloads) ・デフォルトでは最新のSDKしか入っ ていないので、Android Studio から
「Configure」「SDK Manager」を選択し、 必要に応じてインストールしてくださ い。
開発環境構築(エミュレータ) ・実機を用いた開発をする場合は関係ありませんが、 エミュレータでアプリを動かしたい場合はこの設定が必要です。 ・Intel x86 Emulator Accelerator(HAXM) Intel virtualization Technology
(VT-x)を用いたエミュレータの高速化 →SDK Managerから選択してインストール (うまくいかない場合はCPUが対応しているかどうか、そしてBIOSの設定見直しを行う) ※だいたいみんなここで詰まるのでネットに大量に情報があります。
ランチャー画面 Start a new Android Studio Project クリックで次へ
プロジェクトの作成 アプリの名称とカンパニードメイン、 作業ディレクトリの設定 アプリ名: NumberCalc カンパニードメイン: io.github.matsurihime (matsurihime.github.ioを逆順に) →パッケージ名が生成される matsurihime.github.io.numbercalc
ターゲット設定 対応するデバイスの種類やOSの バージョンを設定する でもどのバージョンをターゲットに すればいい・・・? →Help me chooseをクリック!
バージョン情報 OSバージョン現在のシェアや各 バージョンのデバイス最低要件が 確認できる Android4.4に対応させれば74%の シェアをカバーできる事がわかる やや情報が古いのと、世界中の データを合算したものなので国内 向けであればAndroid5.0でも十分
テンプレート選択 色々なActivityのテンプレートがデ フォルトで用意されている 今回はEmpty Activityを利用
アクティビティ作成 Activityの名称とLayoutの名称 ActivityはXxxxYyyyActivityとする のが一般的 Layoutはactivity_xxxx_yyyyとする のが一般的
コーディング 今回はKotlinとJavaの2通りで まずはKotlinのコード 行数はコメント等込で65行
コーディング Javaのコード 行数は96行 Kotlinの場合の約1.5倍
UIデザイン XML形式でレイアウトを作成する Android Studioの場合は 左記のようにGUIツールを利用可 少し前までは融通が聞かない作り でAndroid開発者の悩みの種だった →ConstraintLayoutの登場 (iOSのStoryBoardに類似)
実行!の前に・・・ ・実行ボタンを押すとターゲットデ バイスの選択画面が表示される。 ・実機を繋いでいれば「Connected Devices」に表示されるので選択し てOKすると実機デバッグできる。 ・そうでない場合はエミュレータの 設定が必要 (Create New
Virtual Deviceボタン)
デバイス定義選択 ・Nexusシリーズのデバイス定義 が既に入っているので、これを元 にセットアップするのが簡単 ・Android Phone以外にもTabletや TV, Wearなども選択可能 ・今回はNexus 5Xを利用します
イメージ選択 ・ここが難しい! ・最近のintel CPUを積んだマシン ならABIがx86_64でかつTargetに with Google APIsを選んでおけば 良い ・AMD
CPU等の場合はarmeabiな どを利用する必要があるが windowsだと高速なエミュレータが 利用できません(Mac / Linuxでは 可)
個別設定 ・特に弄らなくても動くはず ・解像度を変更できるので、テスト したい用途に応じて変更する ・Show Advanced Settingsボタンか ら更に詳細な設定画面へ
詳細設定 ・ネットワークやカメラのエミュレー ト設定、CPUのコア数やRAM容量 などを詳細に決められる。 ・基本的には実機と同等にしてお けばいいはずです ・今回は何も弄らずCPU 4Cores, RAM 1.5GBとしました
エミュレータでテスト とりあえず動いてくれました。
エミュレータの実用性 ・最近のミドルスペック以上のIntel CPUと8GB程度のRAMを積んだWindowsマシンであれば ほぼストレスフリー(というか、実機よりもぬるぬる動く)で使える時代になりました。 ・先述の通りAMDのCPUでWindowsを使っている人は、悪いことは言わないので PCを買い換え、実機デバッグ、あるいはLinuxを用意しましょう。 ・Macも最近の端末ならぬるぬる動くはずです。
アプリの署名 付きビルド AndroidStudioのメニューから Generate Signed APKを選択
アプリの署名 付きビルド ・最初は鍵がないのでCreate New から作成します
キーストアの 作成 Key store path: 鍵ファイルの保管場所 Validity: 25years(25years以上が推奨) Certificate: 名前や所属組織など
次へ 初回は自動で入力されるのでこ のまま次へ進んでOK 今後、ビルドの際は今回作成した keyとパスワードを用いてNextする だけでOK
APK作成! Signature Versions →V1とV2があり、V2のほうが セキュリティ面等で優れているが、 別途設定が必要なので ここではV1を選ぶ Release.apk がAPK Destination
Folderに作られます
Developer登録 http://play.google.com/apps/publish /signup/ 約款への同意やアカウント情報の登 録・登録料の支払いなどを行います。 登録料は初回のみ・$25(良心的!)
Developer Console 登録が完了するとDeveloper Consoleへログインできるように 今回はアプリを追加するので、 右上の「アプリの作成」をクリック
アプリの作成 デフォルトの言語とアプリの タイトルを入力する。 特に公開するわけではないので 適当につけました。
ストアの掲載情報 ・タイトル ・簡単な説明(関連アプリなどで用 いられる) ・詳しい説明(アプリページで用い られる) ・その他、アプリ制作者のプロ フィールやアプリのカテゴリなども
画像登録 ・アプリページに用いられる画像 の登録 基本的には - ヘッダ画像 (1024*500px JPG or 24bit
PNG) - 高解像度アイコン (512*512px 32bit 透過PNG) - スクリーンショット(2枚以上)
アプリページ(例) ・ヘッダ画像 ・アイコン画像 ・説明文 ・詳細説明文へのリンク ・スクリーンショット
その他設定 ・掲載情報を登録後は・・・ ・アプリのリリース (apkのアップロード) ・コンテンツのレーティング (アンケートに答えるだけ) ・価格と販売・配布地域の設定 以上を完了すると公開可能に!
Androidアプリを自作する意義 ・最近はマーケットもかなり充実し、もはや必要なものは大体揃っているが・・・ →有料アプリを無料で使いたいから似たようなものを自作してしまう!(公開するのは注意) →高機能すぎて重い既存アプリから不要な機能を除いて自作!(同上) →広告収入や販売収入で一儲けしたい!(就業規則的なことは割愛) →そもそも・・・新しい技術を習得するのって面白い!
ここからはちょっとだけ細かい話・・・ ・Java + SQLite + HttpClientで大体のことはできます。できますが・・・・。 → 表現が冗長。ソースコードが長くなって見づらい。(特に非同期処理や無名クラス) → null安全でないせいで至る所でぬるぽが起きる。
→ 非同期処理や並列処理を書くのが面倒。面倒なくせにしょっちゅう出てくる。 → 誰が何に依存しているのかよくわからなくなってpublic staticだらけになる。 → SQLiteがとにかく遅い。 → オブジェクト指向なのにオブジェクトをまるごとDBに保存しておけない。 とにかくイケてない!!
リアクティブプログラミング ・データが流れるようにやってくる(ストリーム)ことに着目し、データを受け取るたびに関連した プログラムが反応(リアクション)して処理を行うものとする考え方。 ・データが時間とともに連続的に変化するものと捉えて扱う。 ・データの生産側はデータを渡すところまでが自身の責任範囲となる →非同期処理が容易に実現できる ・関数型プログラミングと近い性質を持つ →関数の組み合わせで様々な処理を組み立てられる。
リアクティブプログラミング ・RxJava / RxJava2 - リアクティブプログラミングをJavaで実装するためのライブラリ - Observable(観測対象)とObserver(観測者) → Observerパターン
オブジェクトの状態変化を、それに依存する他のオブジェクトたちが監視。 観測対象から通知があったら各自が自動的に適切な振る舞いをしてくれる。 (実はjava.utilパッケージにもObserverインターフェースとObservableクラスはある) - Observableは登録されているすべてのObserverに対しupdateメソッドで通知を行える。 ※update時もObservableはその通知の中身については何も知らない。あくまで通知するだけ。 →通知の際にObservableをまるごと引数として渡すことで状態に関する情報も受け渡せる。
依存性注入(DI: Dependency Injection) ・コンポーネント間の依存性解決を、振る舞いのためのソースコードから分離し、 外部から注入できるようにすること → 結合度の低下によるコンポーネント化の促進 → 特定のフレームワークへの依存度低下 →
単体テストの効率化(モック使いたいよね) すごく簡単に言えば… 「AをコンパイルするのにBが完成していないとだめ」が「AはBに依存している」という意味
Singletonパターンじゃだめなの? ・現在一般的なSingletonパターンはprivate static finalな変数としてインスタンスを保持し コンストラクタもprivateにして秘匿しつつ、getInstance()などの公開メソッドで取得する方法 →グローバル変数として利用できてしまう →そもそもAndroidでSingletonパターンって本当に安全?
じゃあどうしたら? ・全く外部に依存しないのはほぼ不可能 → 緩い依存は必要になる →インターフェースに依存させる(抽象への依存) = Interface Injection ・Singletonパターンの代替としてDIコンテナの利用 -
Singletonパターンはsingletonオブジェクトが1つしか生成できないようにする実装 - DIコンテナによるSingletonの実現では、オブジェクト自体は複数生成できるが、 DIコンテナの制御により1つだけインスタンスを生成するようにしている
非同期通信 ・スマホアプリは基本的にオンラインを前提にした作りとなることが多い。 ・UIスレッドとネットワークスレッドの分離が大前提(意外と忘れやすい) ・標準のHttpClientもあるが、痒いところに手が届かない。実装が美しくない。 →便利な型安全HttpクライアントとしてRetrofit / Retrofit2がある (現状はほぼこの2択) →Retrofitの利点の一つとして前述のRxに良く適合していることが挙げられる
データベース ・Realm - とにかく高速。SQLiteの2〜10倍高速と言われる。(特にデータ量が大きくなると顕著) - マルチプラットフォーム対応。iOSでも使われています。 ・Orma - Android向けのORM(Object relational
mapping) →関係データベースにはスカラー値しか保存できない = オブジェクト指向と相性が悪い - SchemaDiffMigrationによる自動マイグレーション(SQLのDDLをパースし、差分を検出してSQLを発行) - 補完に優しく型安全なインターフェイス
クロスプラットフォーム 名称 特徴 Unity javascript/C# ゲーム開発では最強の機能と知名度 Cocos2d-x 2Dゲーム作成ツール。これも知名度は高い。 Adobe AIR
いわゆるFlash。昔からありますが、今更これで作る?感はあります。 Apache Cordova HTML5でハイブリッドなアプリを作成可能 Xamarin C#でクロスプラットフォーム開発 以前は高価だったがMSに買収されて無料化! 結局どれがいいの???
Xamarin vs Cordova Xamarin Cordova 言語 C# HTML5 / CSS
/ javascript UI 各プラットフォームに合わせた実装 が必要(XAMLである程度はできる) HTMLとCSSを用いて統一的なレイアウト を記述できる(全てではない) ビジネスロジック C#で共通化できる Javascriptで共通化できる 速度・安定性 XAMLプリコンパイル、C#コードもコン パイル済みなので比較的高速 Webページのレンダリングがあるのでパ フォーマンス面では劣る
なぜクロスプラットフォーム? ・モバイル向けOSのシェアがデスクトップ向けOSのシェアを遥かに凌ぐように! → iOS / Android / Windows 10 Mobileなどそれぞれが一定のシェアを得ている現状
→それぞれのアプリの開発者を揃えて 予算と工数を確保して 実際に開発してみたらあるプラットフォームだけ遅れてしまって 結局、全体のリリースが遅れて・・・
万能ではない ・結局各プラットフォームそれぞれに対応したコードを全く書かなくていいわけではない →共通化できるところは共通化して、なるべく楽にしようよ!という考え方 ・HTMLやjavascriptも分からない、C#も分からないでは何も書けないことに変わりない →特にHTML等はどんな方面でも使うことになるので継続的な学習が必要 ・というか各OSへの理解がないのに本当にそのアプリで大丈夫?最適化は?メモリリークは? →いきなりクロスプラットフォームで開発しようとしない! →iOSでもAndroidでもWinでもいいので、どれか一つ、モバイル開発を試してみること
参考・引用 ・Activity のライフサイクル再確認 - http://qiita.com/calciolife/items/39b2696a9a03e8591d40 ・プログラミング言語Kotlin解説 - https://sites.google.com/site/tarokotlin/chap1
ご清聴ありがとうございました