FlutterでCI - ひげろぐ
Flutter手習いに作ってるタイマーアプリがある程度形になっていたのでCIを回したくなり、とりあえず無料でいけるGitHub ActionsでCIを回すことにした。 flutter-actionというイカしたモノがあるのでそれを使っていく。 .github/workflows/ci.yml を以下のように作ってpushドーン。 name: CI on: push: branches: [ master ] pull_request: branches: [ master ] workflow_dispatch: jobs: build: runs-on: ubuntu-latest # runs-on: macos-latest # runs-on: windows-latest steps: - uses: actions/checkout@v2 - uses: actions/set
Flutterの自動テストを俯瞰する - ひげろぐ
ある程度自動テストの心得があるFlutter初心者の理解/解釈。 Flutterは割と自動テストしやすい流れが整っている。 開始点 公式のTesting Flutter appsが開始点としてよくまとまっている。 概要をつかむには「flutter テスト」でググって出てきた日本語のページを適当に読むのもいい。 ただし情報の陳腐化に注意。 特にサンプルコードを動かすならまずは公式のものから当たったほうがいい。 テストの種類 Flutterの自動テストには以下の3種類がある。 ユニットテストウィジェットテストインテグレーションテスト 感触としてはウィジェットテストを主に書くことになりそう。 ユニットテスト 関数、メソッド、クラスの単体テスト。 ある程度複雑な処理を個別に切り出したものに対して書いていくかんじになるだろうか。 ウィジェットテスト ウィジェットの単体テスト。 UIの表示や操作のテス
テストやデバッグのために知っておきたいTitaniumのオブジェクトの特徴 - ひげろぐ
それは JavaScript側のオブジェクトはネイティブのオブジェクトの情報を全て持っているわけではない。 ということ。 以下のようにメソッド呼び出しをトリガーに必要に応じてとってくるかんじのようだ。 view = Ti.UI.createView(); Ti.API.debug(view.visible); // #=> <null> view.show(); Ti.API.debug(view.visible); // #=> true view.hide(); Ti.API.debug(view.visible); // #=> false この挙動はパフォーマンスも考えるとやむをえないのだろうか。 ともあれこういう事情のおかげでオブジェクトのダンプもままならないのでデバッグが少々やり難くなっている。 また自然な期待に反する挙動なので、知らないとバグなのかと戸惑う。 そしてどう考えて
Titanium MobileとRubyMotionの比較 - ひげろぐ
双方とも脱Objective-Cを実現してくれるプロダクトだけど性格はけっこう違う。 共通で興味を持っている人が多そうなので思うところをとりとめもなく書いてみる。 取っつきやすさ iOS SDK開発未経験者がとっつきやすいのはTitanium。おそらくRuby経験者でも。 逆にiOS SDK経験者ならばRubyMotionの方が入って行きやすいかもしれない。 RubyMotionはiOS SDKのAPIをタイトになぞっているためにiOS SDKのAPIに関する知識が必要だが、iOS SDKのAPIには直感的じゃない部分が多々あって、それに馴染むまでけっこう時間がかかる。その学習コストがけっこう高い。 TitaniumのAPIはTitanium独自のものだが整理されていて扱いやすい。学習コストは皆無ではないがiOS SDKに比べればずっと楽。 またObjective-Cよりマシとは言えRub
TitaniumのロジックとUIのプロパティ定義を分離する - ひげろぐ
UIの部品をたくさん追加するとコードの見通しが悪くなってくるので、なんとかしたいと思った。 そこでUIのプロパティを指定するオブジェクトを別の場所で定義して分離することにしてみた。 Ti.includeを使うとコードの分離は簡単なので、方法は至って単純。 styles.jsというファイルにプロパティの定義を追い出す。 2010/02/12追記 Titamium Mobile 1.5からJSSというものが使えるようになっていて、以下のstyles.jsでやっていることをCSSっぽく書ける。 ただ1.5の時点ではiOSで問題があり、JSSの更新が二度目以降のビルドに反映されず、更新を確認するためには都度build以下を削除しないといけないようなことになっているようだ。 元のコード まずは分離前。 hoge.js いたって普通に書いたコード。 UI部品が少ないうちは問題ないが、部品が増えてくると
Titaniumでアプリケーション定数の管理 - ひげろぐ
アプリケーション全体から利用する定数的なものをまとめるのに最近は以下のようにやってます。 激しく我流でアレですが。 config.js var Config, exports; Config = {}; Config.database = { name: "userdb" }; exports = Config; 独立したファイルにまとめておくと管理しやすい。 app.js Ti.App.Config = require("config"); var db = Ti.Database.open(Ti.App.Config.database.name); ... app.jsの先頭でTi.Appにくっつけとけばアプリ全体からアクセスできるようになる。 しかしTi.App.Configとか言う名前は恐れ知らずだよね。我ながら。
Titaniumでユニットテスト - ひげろぐ
公式のドキュメントには何の記述もないが、ユニットテストには好きなJavaScriptのテスティングフレームワークを利用できる。 ただしブラウザに依存しないもので、ログの出力をフックできるものに限る。 要はTitaniumのコンソールにログを出力するためにTitanium.API.infoやTitanium.API.errorなどにテストの出力を渡せればよいわけです。 今回はxUnit系で一番勢いがありそうなQUnitとBDD系でよいと言われているJasmineで試してみた。 QUnitを使う Titanium用のアダプターがGitHubで公開されている。 lukaso/qunit – GitHub 自分のプロジェクトで利用する場合はResources以下に次のファイルを設置すればOK。 * runner.js * qunit/qunit.js * qunit/titanium_adapto
TitaniumのWindowは再利用するべきか - ひげろぐ
何度も同じ内容のWindowをcreateしまくっていいのだろうかと言うこと。 例えば何かボタンを押すたびに以下のようなコードを実行するとする。 var newWin = Ti.UI.createWindow({ url: 'hogehoge.js', title: 'ほげほげ', }); Ti.UI.currentTab.open(newWin); これで新しい画面に遷移した後、元の画面に戻ってまたボタンを押したら同じ内容のWindowがまた作られて、リソースを圧迫していくのではないかということが心配になる。 都度createしないで再利用すべきなのだろうか。 再利用しないとWindowはどんどん増えていくのか？ この懸念に関してはWindowがフォーカスを失ったときにcloseされるので問題ないようだ。 hogehoge.jsに以下のようなコードでWindowオブジェクトが破棄される様
TitaniumのDBの作成と削除とスキーマの更新 - ひげろぐ
ちょっと整理。 作成する アプリ内で一から構築する方法と既存のDBをインストールする方法がある。 新しく作成する openでDBを開くことができる。 その際にDBが存在しなければ新しく作成される。 var db = Ti.Database.open('userdata'); テーブルの作成はdb.executeを使ってSQLで直接CREATE TABLEする。 既存のDBをインストールする SQLite3のDBをコピーしてデータベースを作成するinstallというメソッドがある。 マスタデータを入れたりするのに便利。 var db = Ti.Database.install('hoge_app_master.sqlite3', 'master'); この時dbはopenで開いたのと同じように操作できる。 すでにDBが存在する場合は上書きはされずopenと同じ挙動になるため、ユーザーデータを
Titaniumでバウンドするアニメーション - ひげろぐ
カーソルが上下にバウンドしているアニメーションはユーザーの注意を引く効果がある。 Titaniumではそういうアニメーションが簡単に実装できるので使わない手はないでありましょう。 サンプルコード Windowの中で対象のViewが上下にバウンドするという素朴なサンプル。 例によってiOSでしか動作確認していない。 app.js var win, view, upAnimation, downAnimation; win = Ti.UI.createWindow({backgroundColor: "#fff"}); view = Ti.UI.createView({ width: 100, height: 20, top: 100, left: 'auto', backgroundColor: "#00f" }); win.add(view); upAnimation = Ti.UI.cr
Titanium Mobileを二ヶ月くらいさわってみた感想。 - ひげろぐ
今年に入ってからほぼ毎日触ってました。でもほとんどiPhone開発しかしてない感想。 主観的なところをだらだらと書いてみましょう。 とりあえず気に入っているところイマイチと思うところを挙げてみたい。 合わせて総評など。 気に入っているところ さくさく開発できる Objective-Cとは段違いの開発効率。 冗長なメソッド名とメモリ管理の煩わしさからの解放がうれしい。 ちょっとしたモックアップ程度ならさくっと作れてしまう。 そこから開発者が作り込みに注力できる環境が見事にできあがっているのではないかと。 JavaScriptはくせもあるけどおおむね使いやすい言語。 CoffeeScriptとの組み合わせでさらにいいかんじ。 TDDできる Jasmineで気持ちよくTDD出来ている点が非常にポイント高い。 おかげでTitaniumラブですよ。 Objective-CでもTDD可能だけど、OCU
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
