はてなブックマーク

去年、こんな記事を書いていました。 あれから1年、いまはどうなんでしょうか。 結論から言うと よほどの理由がない限り、Playwrightでしょう。 6月頃にはもうこの結論は出ていました。 Playwrightを使う理由 JavaScript, Python, C#, Java の言語を公式にサポートしている Goも公式入りするという話はあるが、半年以上経った今もまだされていない Auto waiting により、いちいちwaitForナントカを書かなくても、ある程度は安定した自動操作ができる 2021年8月ごろにリリースされたPlaywright 1.14で導入されたLocatorにより、さらにこの特性が利用しやすくなった。 ドキュメントの品質がとても良い マイクロソフトとは思えないクオリティ さすが元Googleの人が作ったOSS 他にもテストランナーなど便利な特徴はありますが、 とも

Playwright (TypeScript版)は microsoft/folio ベースのplaywright-testという独自フレームワークを使うが、playwright-pythonにはPyTest用のプラグインがある。 Pytest plugin for Playwright https://github.com/microsoft/playwright-pytest Getting Started! macOSであれば playwright-pythonのインストール

2020年は、突如Playwrightが現れ、Seleniumを置き換えるほどの勢いでいろいろなツールが現れました。 Puppeteerは、Playwrightが出てからもTypeScript化をしたりカスタムクエリハンドラ機能が実装されたりと、Chrome DevToolsプロトコルを利用するライブラリとして改善が続いています。 今年１年の Puppeteerのリリースページ https://github.com/puppeteer/puppeteer/releases Playwrightのリリースページ https://github.com/microsoft/playwright/releases を時系列にまとめてみます。 2020年1月。 PuppeteerとPlaywrightの15日間の演劇 https://speakerdeck.com/taminif/relation-

今年の1月に突如 microsoft/playwright が出て、「なに？puppeteerはオワコン？」と一瞬思いましたが、playwrightが出てからもpuppeteerはTypeScript化したりしていますし、いまのところどちらも活発に開発されています。 「puppeteerとplaywrightはどっち使えばいいの？」に対して、2020年12月現在の答えはおそらく「使いたいほうを使えばいい」です。 ただ、「使いたいほう」ってなんやねん？というところがググってもあまり情報が出てこないこともあり、今回の記事では、この選ぶ手がかりになる情報を少し投じておこうかなと思います。 PythonやC#でも使いたい？ puppeteerは現在のところJavaScriptのライブラリ一本です。 playwright はPythonとC#のバインディングがあります。 microsoft/play

Slackと違って、Microsoft Teamsは気軽にユーザとしてメッセージをPOSTすることはできなくて、管理者の承認が必要だ。 管理者権限なしでできるのは、特定のチャネルのメッセージを取得することだけ。使えね〜〜〜！！ (APIでPOSTするものは基本的にボットとしてIncoming Webhookとか使えっていうことなんだろうけど...) とりあえず ここまで権限がもらえたら、TeamsのチャネルのユーザーメッセージをAPIで操作することができる。 Authorize, Token 手っ取り早くトークンだけ欲しい場合には、手動で https://login.microsoftonline.com/テナントID/oauth2/v2.0/authorize?client_id=クライアントID&client_secret=シークレット&response_type=token&scop

いわゆる「ぐぐれかす」をPuppeteerで作って練習したときのメモ インストール済みのChrome for Macを使うには？ puppeteer標準でChromiumブラウザがくっついてくるが、Chromiumダウンロードめっちゃ時間がかかるので、とりあえず手元にChromeをインストール済みなら、それを使って自動操作をしたい。 puppeteer-core を使って、手持ちのChromeのゲストセッションを開くには？と調べたら、issueで質問 してる人がいて、「公式Docに書いてるでしょ」って書いてたｗ Macだったら const launchChrome = puppeteer.launch({ // MacにインストールされているChromeを使う。 executablePath: '/Applications/Google Chrome.app/Contents/MacOS/

puppeteer-rubyっていうライブラリを作っているときに、WebSocketのコールバック順序がぐちゃぐちゃになる事象に嫌気がさして、WebSocketの代替実装を探していたところ、 （ぜんぜんWebSocketではないがw）asyncという面白そうなライブラリを見つけたのでメモ。 複数のタスクを待ち合わせる require 'async' def do_task(name) Async do |task| puts "start task - #{name}" task.sleep(name.to_i) puts "end task - #{name}" name end end def all_task(*args) Async do |task| puts "start tasks - #{args}" values = args.map do |arg| do_task(a

まえおき 2019年10月、alwaysDRINK が突如として福岡にサービスインされたのですが、 当時のサービスは毎日使うにはしんどいUIだったので、自分が毎日使ってもしんどくない程度のAndroidアプリを勝手に作りました。 これは適当にAndroidのネイティブで実装していて、 ViewModelで保持している「選択されたお店」を変更時に地図の中心をanimateCameraで動かす（データバインディング） 縮尺によって、マーカーをまとめる（android-maps-utils の Marker Clustering） https://qiita.com/YusukeIwaki/items/d4979fc698d7f0998e30 のように、シンプルな技術要素で成り立っていました。 「この程度なら Flutterでサクッと書けるんじゃね？」と思ってやってみたら見事に撃沈したというお話

まえおき WebView使うと、ブラウザっぽいアプリはすぐに作れる！ とおもいきや、実際つくってみると結構ボイラープレートコードが多いんですよね。 （ http://arianrod-berry.hatenadiary.com/entry/2018/01/29/233841 あたりにいい感じにまとめられています） なんかいい感じのWebView-alternativeはないかなーと探していたところ、GeckoViewというものを見つけました。Firefox Focusなどで使われているGeckoベースのWebViewてきなものみたいです。 Qiitaで現時点では「使ってみた」レベルの記事もなかったので、とりあえず使ってみた感じを書いておきます。 セットアップ: build.gradleへの追記 implementationを１行ペロッと書くだけ・・・ではありません。 オフィシャルのWiki

まえおき iPhone Xに始まった↑のような欠陥デザインは、Android 9.0でも正式に対応されたようです。みんな「ノッチ」とか言っていますが、Androidでは display cutout と呼ぶようです。 display cutoutは全画面表示するようなアプリの動作にも影響が出るため、開発者向けリファレンスにも、 https://developer.android.com/guide/topics/display-cutout/ こんな感じのドキュメントが公式に公開されています。 display cutoutにはいろんな種類がある Android 9.0エミュレータで開発者オプションを見てみると corner double tall の3種類を選ぶことができるようになっています。 これってようするに、端末ベンダーが割と自由にdisplay cutoutできるようになってたりす

<?xml version="1.0" encoding="utf-8"?> <layout> <data> <variable name="viewModel" type="io.github.yusukeiwaki.twowaydatabindingpractice.SignupActivityiewModel"/> </data> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical" android:padding="16dp"> <android.support.design.widge

ViewModelとかLiveDataのサンプルってAPI通信とかのわりと複合的なのが多いけど、もっと単純に使っていけるんではないか、という話。 ほぼ自分用のメモ。 ViewModel ViewModelは、内部的にはRetained Fragmentをうまく利用して、Activityが"本当にDestroy"されるまで居残り続けられる土台みたいなもの。 これ、データバインディングを使うとだいぶありがたみがある。 たとえば、画像処理をやるアプリだと... これ、何も考えずにActivityとsavedInstanceStateでやろうとすると結構めんどくさい。 class ImageProcessingActivity .... { private int seekBarPosition; public void onCreate(Bundle savedInstanceState) {

これは何？ https://developer.android.com/about/versions/oreo/background.html?hl=ja#services Android 8.0では、バックグラウンド動作制限の一環として、 **裏でこっそりサービス起動しようとしてもできなくなります！**だって。 まじかよ！！！！！ でも、 リファレンスに書いてあるとおりの実装になっているとは限らないのがAndroidのいいところだ（違ｗ いちおうソースはちゃんと読んでおこう、ということで調査した自分用メモです。 （長くなったので、前編・後編に分けましたｗ　（が、後半は適当です 実際にアプリを動かすとどんな感じになっているか？ JobScheduler（とか、それをラップしているGcmNetworkManager）から起動されるジョブサービスはちゃんと裏でも動ける でもそこからstartS

この記事は CrowdWorks Advent Calendar 2017 の2日目の記事です。 CrowdWorksで公式Androidアプリの開発をやっている @YusukeIwaki がお送りします。 まえおき いまさらですが、Androidアプリって開発するの難しいですよね。何も考えずに機能を追加していくと、すぐにFatなActivity/Fragmentができてしまいます。 「じゃあFat Activity/Fragmentを回避するために、MVPアーキテクチャーを導入しよう！」ってなると今度は、ボイラープレートコードが増えます。 「こんな無駄なコードを書きたくない！！」という衝動が強くなり、カッとなってオレサマコードジェネレータが作られたり、オレサマアーキテクチャが生まれたりします。 「うーん、本質的に解決になってるのかこれ？」とある日考えます。 ・・・と、（やや極端ですが）ア

多くは語らないけど、DownloadProviderのアーキテクチャは単純明快で、いろいろ参考になることが多い。 そんなDownloadProviderが、Android 7.0 Nougatからしれっと実装が変わっていたので、かるくソースコード解読をしたメモです。 ※ちなみにこの記事は、DownloadProviderのもともとの作りを知ってる前提で書いてます。しらないかたはまずはAndroid 6.0までのソースを読んで下さい。 対象のコミット 消えたDownloadService DBに書かれたイベント契機で裏でいろいろゴニョゴニョ動いていたDownloadServiceがなくなりました。 代わりに、JobScheduler発動時に動くDownloadJobServiceというのが追加されています。 「ネットワーク状態が変わったら・・・」とか、「リトライ回数が・・・」みたいなロジック

この記事はCrowdWorksアドベントカレンダーの５日目の記事です。 ＃CrowdWorksのエンジニアが毎日なにかを書いています。 まえおき クラウドワークスでAndroidアプリやAPIの開発をやっています @YusukeIwaki です。 前職でAndroid OSのカスタマイズをいろいろやっていたので、いまだにAndroidのソースを眺めて「この設計いいな」と思っては、それをマネしてアプリをつくるスタイルでやっています。 今回は、Androidのファイルのダウンロード機能の根幹を担う、DownloadProviderのイケてる設計のことを書きます。 DownloadProvider自体は、５年以上前からあるし今更感はあるとはおもうのですが、クラウドワークスの公式Androidアプリは、DownloadProviderの設計を大いに参考にしているので、CrowdWorksアドベント

Android 7.0からはChromeがWebViewを提供する みたいのはあちこちでバズってる割に、中身の仕組みをちゃんと書いた記事は殆ど見ません。 個人的にはとても残念に思います。 ということで、中を見てみました。 まずは、Lollipopまでのおさらい WebViewのAPIを提供するのが、WebViewFactoryProviderで、 WebViewFactory::getProvider のなかで ネイティブ側の準備：libwebviewchromium.soの探索とロード パッケージ名はgetWebViewPackageName()で取得 Java API側の準備：WebviewProviderの生成と初期化 WebViewChromiumFactoryProviderが内部でWebViewDelegateを実装する みたいな流れの処理があります。 ソースレベルで見たければ

Gmailとかハングアウトとかって、複数端末で通知を受けても、１つの端末で消せばちゃんと全部の端末で通知消えるんですよね。 これがやりたい。 あれ、どうやるの？　という話です。 ざっくり プッシュを受け取った端末が「受け取ったよ！」って空プッシュを送って send-to-sync する、みたいなことをやらないといけないようです。 以下のリファレンスを見ると、Device Group Messagingというのをつかうだけで、GCMがいい感じにやってくれるようにも見えますが、実際に動かしてみると、プッシュ消去は同期されませんでした・・・・・・。 http://www.androiddocs.com/google/gcm/notifications.html https://firebase.google.com/docs/cloud-messaging/android/device-grou

昨晩のGoogle IO 2016で、Firebaseの大幅機能拡充が発表されました。 Railsのコードを書けないAndroidアプリ開発者がnifty cloud mobile backendを使ってチャットアプリを作る っていうのをやったときに、ニフティクラウド モバイルバックエンド最大の欠点であった、「リアルタイムDBが使えない！」っていうのがFirebaseではいけてるように見えたので、実際にどうなのかさわってみることにしました。 アプリケーションの作成 なんかイイ感じのページから「GET STARTED FOR FREE」で アプリケーションを新規作成。 アプリとFirebaseのひも付け Googleログインを利用してラクしたいので、SHA-1ハッシュを登録します。 まずは、Android StudioでKeyStoreをつくります。 $ keytool -exportcer

Android 6.0から、新たな隠し機能？としてSystem UI Tunerというものが現れました。 れいによって そのうち無くなるかもね、でも文句いわないでね、てきなことが書いてある Gitコミットの詳細を見てもわからない ソースのコメントもない = ソースをガリガリ読むしか無い！w という非常にてきとーなコンポーネントです。 ぐぐってもなかなか情報がでてこない、 けど、なんとなく使えそうな雰囲気を感じるものがある、のでちょっと触ってみました。 2015/10/30現在、Broadcast TileとDemo modeの説明が、なかなかぐぐっても出てこないので、この記事ではその２つの機能をいじって情報共有してみます。 IntentTile (Broadcast Tile) あまりにも利用方法が書かれていないので、「未実装だ」とか「機能を持たないものだ」とか言っている記事が世の中に数多

Android 6.0でChromium WebViewがソースビルドされなくなったので、自前でChromiumをビルドをする AndroidwebViewChromium あれ、external/chromium_org どこいった？ Android 6.0のソースが検索サービスに現れた。 さて、ブラウザやWebViewがどうなったか見てみるか、と思った次の瞬間・・・ なに？？？ https://android.googlesource.com/platform/external/chromium-webview/+/2773fff0a2927264eb37d9e532315aea0ba0ff20/README Building the Chromium-based WebView in AOSP is no longer supported. WebView can now be bu

こんなかんじのコードを書くわけですが、CursorやSQLiteDatabase のclose() を呼ぶのを忘れることがよくあります。 また、 内部のDBハンドルのライフサイクルの理解が浅いエンジニアが、closeを呼ぶタイミングを間違い、謎のエラーに悩まされる ということもよくあります。 「closeをしなきゃ」と思わなくてもいいコードへ やることは２つです。 １つは、（RailsでいうActiveRecordてきな）モデルを定義すること。 もう１つは、SQLiteDatabase のインスタンス取得/破棄をMyDatabaseHelper側に共通処理化してしまうこと。 モデル定義 Cursor のclose() を意識しなくてもいいようにやります。 SQLiteDatabase のopen/close の責務は持ちません public class User { private sta