サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
体力トレーニング
eaglesakura.hatenablog.com
もうすぐAndroid 12がリリースされるので、最低限対応した内容をメモする。 Android Studio AF対応 新AndroidStudioにビルドツールを切り替えた UnitTestをRobolectricからInstrumentation Testをメインに変更 Android Studio AFから、Robolectricが実行しづらくなった(できなくはないが、使いにくい) なので、Instrumentation Testのみを行う方向に切り替えた それに合わせてCIも変更した CIでエミュレータを作成&起動してInstrumentation Test Lint対応 Android 12でLint系が更新されたので、チクチクと変更 Activity.exported 属性の対応 AndroidManifest.xmlのActivityタグで、exported属性設定が必須に
BREWとは 最近ではSnapdragonで有名なクアルコムがかつて開発していたOS 日本人的には auの KCP/KCP+ だ ガラケー全盛のauを支えようとしていた、かつての クソ OSだ 2010年代が終わり、記憶が消えてしまう前に、彼について記録と記憶を留めておこうと思う BREWとの出会い 新卒で入社し、手取り17万円で働いていた会社で、 Javaに似たへんな言語 で作られたゲームを、BREWへ移植する仕事が降ってきた ゲームの内容自体は面白かったが、ソレは別な話だ 当時docomoユーザーだった俺は、BREWやKCP/KCP+なんて全く知らない なので、手探りで開発をスタートすることとなった 会社的には、前任者のコードがサンプルとして存在していた 2010年前後の、お話である BREWのざっくりとした開発環境 Windowsで開発環境が構築できる Windowsでは x86環境
こんな状況は危ない 昔は自社でアプリ開発してたけど、もうメンテしなくなって久しい とりあえずアップしておいて、使う人がいるならソレでいいや 何が起きるか Google Playは年1〜2回くらいはConsoleのアップデートがある アップデートにより、一部のアプリは修正が必須となる場合がある アプリ内容だけでなく、プライバシーポリシーとかが必須となったり 放置すると何が起きるか アプリがBANされる BANされるとメールが飛んでくるが、見逃しがち BANされたものは復帰できるか 開発リソースがあるのなら、BAN理由に対して対応を行う 基本的にノーコストでBAN解除はしてもらえない Google is GOD. 開発リソースがないとどうなるか とりあえず放置しがち BANが増えていくとどうなるか(都市伝説) これは都市伝説だが、3BANでGoogle アカウントBANとなる 都市伝説だが。
セットアップ Ubuntuを基本にしつつ、Windows 10 Proを併用するつもりだったので、購入してすぐにいろいろ弄り倒す。 失敗1 初期セットアップ時にMicrosoftログインをしてしまった Users/<メアド>/Home ディレクトリになってしまう 任意のディレクトリ名にするためには、初期セットアップ時にMicrosoftアカウントを使わずにオフラインアカウントを作る必要がある 再セットアップ 失敗2 Ubuntuインストールに失敗 1TBストレージの半分をUbuntuのために明け渡した 19.04をインストールした Windows側のBootloaderが破壊された 再セットアップ Biosセットアップ Fn <--> Ctrlスワップ Secure Boot [Disable] UEFI / Legacy Mode [Legacy Only] コレは設定しなくてもThin
なぜコレが必要か? Firebase SDKを組み込んだ処理は、通常 Google Services Plugin と google-services.json をアプリに組み込むことで動作する このPluginはApplicationビルド用のプロジェクトでしか動作しない ライブラリプロジェクトにFirebase SDKを組み込んだ場合、上記の前提だとUnitTestをするためのApplicationプロジェクトが必要になってしまう 明示的な初期化を行うことで、ライブラリプロジェクトだけでUnitTestが行える 方法 @RunWith(AndroidJUnit4::class) class HogeTest { @Before fun before() { FirebaseApp.initializeApp(context, FirebaseOptions.Builder().also
謝罪 ごめんなさいごめんなさいごめんなさいごめんなさいごめんなさいごめんなさいごめんなさいごめんなさい。 本番環境のFirestoreをONにしてしまったのは僕です。 何が起こったのか アプリから利用されるサーバーをGAE/Goで開発していた GCPプロジェクトは、アプリ側とサーバー側が同一プロジェクトを使用していた Service Account使ったり、そっちのほうが都合が良かったから Datastoreを利用してデータを保存していた サーバーはGoogle App Engine / Go(1.9系)を使用していた データは goon ライブラリを通してDatastoreに保存していた Firestoreの扱い 開発当初から使用実績のあるDatastoreを使う予定で、必要な複数のGCPプロジェクトで Datastore を選択し、なおかつ Firestore / Datastore
Flutter を使う機会があったので、所管をざっくりと。 個人的に思うFlutterを使う際に留意すべき点 Flutterのレンダリングは Skia ベースの独自エンジンで動いている Android的に言えば、どんな画面もView1枚である Plugin実装を読むと、 TextureId を取得してカスタムレンダリングしているものも多い マルチプラットフォーム対応 でありながら、 よく使われる WebView とのかみ合わせが悪い WebViewの上にFlutterのViewを置くことが難しい Pluginをforkして頑張るか? これが 何 を示すかは、人それぞれである レンダリングが OpenGLベースとは限らない ので、iOS/Android両対応と言いつつ気軽に「おっしゃーごりっとOpenGLで書くかー」みたいなことはできない iOSはDeprecatedである Metal Na
経緯 JetpackにRobolectricが統合されたことにより、 @RunWith(AndroidJUnit4::class) にJUnit Runnerが統一された うまいこと実行できれば、CIで検証しやすくなる(Instrumentation TestをCIでやるのは金か手間か実行時間が必要) 駄目だった箇所 こういうExtensionを作って試した github.com // build.gradle android { sourceSets { androidTest.java.srcDirs += ["src/test/java"] } } @RunWith(AndroidJUnit4::class) class HogeTest { @Test fun fugaTestCase() = compatibleTest { // 両方で実行 } @Test fun barTes
coroutines 0.26.1の変更点 多くのクラスやトップレベルfunctionやプロパティがdeprecatedになった 変更から見える方針 トップレベルの関数やプロパティを、いずれかのobject等に所属させることが主な目的に見える 主なDeprecated UI, CommonPool 等の標準Dispatcherが非推奨 Dispatchers.Main, Dispatchers.Default が追加された launch{}, async{} 等のトップレベル関数が非推奨 GlobalScope.launch, GlobalScope.async が追加された isActive が拡張関数になった ビルドが通らないので、ガイドに従って書き換える 互換性 Deprecated属性になっただけで、0.24のときのような内部の破壊的仕様変更はされていない 様子見しつつ、移行して行
変更されたこと runBlockingがUIスレッドからの呼び出しで例外を投げるようになった UnitTestの内部とかで使ったり、無理矢理coroutinesのChannelとかを待ち合わせる用途に使えなくなった 特にJVMでのUnitTestで使ってたので、全部死んだ // この呼び出しはすべて例外となる // 23.x系列までは使える // 24.x系列からは駄目 @Test fun testHogeFuga() = runBlocking { /* do something */ } runBlockingの仕様変更に関するissue issue Support runBlocking for UI Tests コレは意図した変更なので、多分不可逆じゃないかな、とは思う coroutineの処理実装から考えると、特定のシングルスレッドをブロックするのは好ましくない 待機しているco
今日社内で情報が公開されましたが、2010年から勤めていた TOPGATE社 を8月末で退職することとなりました。 トップゲートにいた7年10ヶ月 IT業界としては、かなり長く居たかと思います。 入社時点からAndroidがやりたくて転職して、基本的にはずっとAndroidをやらせてもらえていました。 案件をこなすうちに登壇を経験したり、炎上を経験したり、執筆を経験したり、炎上を経験したり、 Google Cloud Platform に関する知識を身につけたりして、有意義に過ごさせてもらったかと思います。 受託中心の会社だからか、Android界隈に優しい人が多いからか、開発に関わる知人が増えたのも良かったです。 なお、入社時点〜退職時点で年収は2倍以上にアップしました。 初めて彼女ができて、その彼女と結婚して、マンション買って、子供2人生まれて育てているのもTG社に所属している間に経験
Experimental設定が追加 Navigation Editorが標準で無効化された 新たに Settings > Experimental が追加された そこで有効化できる 旧バージョンからアップデートしてビルドが通らない ~/.gradle/ を削除することで復旧できる ASの場合は Invalidate Caches / Restart Windows版でビルドが通らなかった問題 今回から改善された cygwinから assemble が行えるようになった 2バージョンぶりの成功 ASでビルドが通らない問題が発生した Settings > Compiler でgradleオプションを変更した parallel にチェックと -PdevBuild -Dorg.gradle.caching=true を追加してリビルド Emulator フリーズする問題が発生した 久々に起動したか
複数スレッドでGLの処理が可能なGLSurfaceView作りました Githubで配布しています https://github.com/eaglesakura/multicontextglsurfaceview 何が出来るのか GLSurfaceViewを継承したクラスです。動作には互換性があり、GLSurfaceViewをMultiContextGLSurfaceViewに切り替えるだけで使えます。 GLSurfaceViewとの違いは、標準で複数スレッドでのOpenGL ESコマンドの利用を可能にしている点です。GLSurfaceViewでテクスチャ等のリソースを非同期で読み込もうと思っても、最終的には GLSurfaceView#queueEvent にキューイングして、描画スレッドを止める必要があります。 GLSurfaceViewは後述のMaster & Slaveの仕組みを利
Android NDKのデバッグは容易になった・・・はずなのに Androidアプリは基本的にSDKを利用し、Java言語で記述します。ですが、Android NDKを利用することでC/C++言語でもアプリを記述できるのは周知のとおりです。 最初は「できるやつだけついてこい」的にほとんど整備されていなかったNDKの開発環境ですが、最近ではEclipseとの連携が可能になり、更にはコマンドラインベースだったデバッグもEclipseを使ってGUI上でできるようになっています。 Add Native Supportを設定する Debug As -> Native Application エディタ上でブレークポイントを設定 あとはステップ実行なり変数のウォッチなりが簡単にできる そのおかげで、あんどろいどたん(Google Play)を始めとして最近の案件はAndroid NDKを多く利用していた
SurfaceTextureによるテクスチャへのマルチメディアレンダリング Android 3.xからSurfaceTextureクラスが導入されて、OpenGLとカメラ・ビデオ等のマルチメディア連携が楽になりました。 具体的には、テクスチャとしてビデオやカメラの映像を取り込めるようになり、リアルタイムでシェーダーによる映像加工したり揺らしたりができるようになりました。 AndroidのコードをみてみるとVideoSurfaceView.javaというクラスでその実装を行なっているらしいですが、その他の情報が殆ど無いので実際に使ってみた結果のハマリどころメモです。 前提として、OpenGL ES 2.0を利用しています。 AndroidのSurfaceTextureは2Dテクスチャではない 正確には、GL_TEXTURE_2D定数を使ってはいけません。GL_TEXTURE_2Dは殆どの場合
Android NDKとProguardは相性が悪い Proguardとは 今更説明することも無いかと思いますが、ProguardといえばAndroiderにとっては欠かせないお友達です。 Javaのコードは容易に逆コンパイルされて、簡単に内容を解析されてしまいます。 逆コンパイル自体を防ぐことはできませんが、コードの解析を難しくしてくれるツールがProguardの大きな役割です。 Proguardを使う目的は、次の点が大きいでしょう。 コードを難読化して第三者による解析を困難にする 不要なコードを削除してコード全体を小さくする どちらがメインになるかは開発者毎に違うでしょうが、そのどちらかが当てはまるのでは無いでしょうか。 Proguradの問題点 Android SDKを一般的(あなたが思う範囲が一般的です。他人の同意を得られるとは限りません)に使っている限り、Proguardはとても
Android 4.0(API Level 14)からTextureViewというViewが登場し、OpenGL ESの応用範囲が格段に広くなりましたが、GLSurfaceViewに相当する補助クラスが未だに登場していません。 Google的には必要ないという考えかもしれませんが、SurfaceViewよりもTextureViewでOpenGL ESを扱ったほうが非常に楽なため、俺俺GLTextureViewクラスを公開しました。 GLTextureView(github) 詳細はREADME.mdにも記述されています。 GLSurfaceViewとの相違点 使い方はGLSurfaceViewとほぼ変わりありません。 ですが、おおまかに次の点が異なります。 リソース解放用にonSurfaceDestroy()を追加した requestRender()の設計が異なる GLSurfaceVie
「TextureViewで作ろう!」という記事が掲載されました 日経ソフトウエア 2013年 4月号に私が執筆したTextureViewを使った記事が掲載されました。 記事内容 Android 4.0(ICS)から追加された"TextureView"というViewの簡単な解説記事です。 API自体は一年以上前に公開されたため多少古いですが、現在までほとんど日本語の情報がないため、少しでも参考になればと思います。 TextureViewはSurfaceViewの強化版という認識で問題ありませんが、内部処理は全く違います。 今回の記事はその違いを説明するために、カメラを使った簡単なアプリを作成しました。 アプリ内容 端末のシステムレイヤー上に常にカメラ映像をオーバーレイします。 アプリを起動するとServiceを立ちあげ、Activity自体はすぐにfinish()します。 Serviceから
弊社Jenkinsビルド開始時にFF5の戦闘音楽 -> ビルド成功でファンファーレという流れをつけた— 川峠さん (@eaglesakura) 2013年2月13日 Jenkinsを使った開発を楽しくしようとして、BGMをつけたら案外話題になったからそのまとめ。 事の始まり iOSアプリの開発のために、余っていたMac Book AirにJenkinsを導入することに せっかくMBAだから、サーバー側のJenkinsには出来ないことをやろうと思った 導入方法 導入というほど大仰なことは実は行ってなくて、かなり適当な方法を取っています。 Macのターミナルには"afplay"という音源再生のコマンドがあるので、それを組み合わせるだけです。 鳴らしたい音をmp3でJenkinsを導入したMBAに保存 もともとJenkinsのビルドはシェルを実行する形式だったので、シェルに直接サウンドを鳴らすコ
このページを最初にブックマークしてみませんか?
『eaglesakuraの技術ブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く