みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
お世話になります。
開発環境
Windows7, FileMaker Pro 14 Advanced
動作環境
iPad(機種未定), FileMaker Go 14
実現したいこと：WebビューアでYouTube動画を再生させたい。
"動画"などのキーワードを入れると、思うような検索結果になかなかたどり着けず、こちらに投稿させていただきます。
言えば単純なことなんですが、WebビューアにカスタムHTMLを設定し、YouTubeの動画を再生させたいのです。
動画は、iframeタグを使用してURLを指定し、WebビューアのWebアドレスに指定しています。
以下のページを参考にして、Pro上でブラウズモードにしてみましたが、動画が数秒で停止し、動画上に「エラーが発生しました」と表示されてしまう状態です。
http://fmforums.com/topic/90563-framing … eb-viewer/
https://community.filemaker.com/message/255090
キャッシュなどが影響しているのでしょうか。
Webビューアの特性、動的なWebページの読み込みなど、何か足りないものがありますでしょうか。
ご存知の方がいらっしゃいましたら、ご教示お願い致します。
以下にWebビューアに設定しているhtmlソースを掲載します。
htmlソース以外のWebビューアの設定はデフォルトのままです。
data:text/html,
<!DOCUTYPE html>
<html lang="ja">
<head>
<meta http-equiv="content-type" content="text/html" charset="UTF-8">
</head>
<body>
<div id="movie">
<iframe width="600" height="370" frameborder="0" allowfullscreen="1" src="https://www.youtube.com/embed/XXXXXXXX"></iframe>
<!-- XXXXXXXXに動画IDが入ります -->
</div>
</body>
</html>シンプルにこれで行けませんか？
"data:text/html,<iframe width='560' height='315' src='https://www.youtube.com/embed/xxxxxxxxxx' frameborder='0' allowfullscreen></iframe>"
Offline
Windows7でテストする分には先の式でＯＫです。
また、Webビューアの枠に合わせて目一杯に表示するなら、
"data:text/html,<body style='margin:0;padding:0;border:0;overflow:hidden;'><iframe width='100%' height='100%' src='https://www.youtube.com/embed/xxxxxxxxxxxxx' frameborder='0' allowfullscreen></iframe></body>"
Offline
Hiroさん、早速のご回答ありがとうございます。
ご教示いただいたソースをWebビューアのWebアドレスにコピーし、ブラウズモードで再生させてみましたが、同じように数秒後にエラーとなってしまいました。
さすがにおかしいと思い、別方面で調べたところ、以下の結果にたどり着きました。
http://un-tech.jp/youtube-play-error-ie/
まさかです…。
社内PCであるため、音声デバイスは一切接続していませんでした。
イヤホンを接続したところ、あっさり再生されました…。なんとも情けない話です。
調べた結果、Windowsでは、FileMakerはWebビューアのコンポーネントとしてIEを使用しているとのことで、まんまとIEの埋め込みで発生する現象にはめられてしまいました。
ちなみに…できればの話ですが、Webビューアに表示するHTMLソースをJavaScriptで動的に作成(動画IDを変えるなど)し、リロードするということは可能でしょうか。
IFrame APIなどを利用して、動画の再生状況などを把握したいのですが、通常のブラウザで動作させるようなJavaScriptの記述だとうまくいかないようです。
そもそもこういった使い方は、Webビューアでは不向きでしょうか。
Webブラウザでは、内部的にJavaScriptを使って生成されたHTMLソースを動的に反映させてくれますが、
Webビューアで実現するためには、Webビューア内のHTMLソースを、生成されたHTMLソースで置き換えてからリロードしなければならない、ということでしょうか。
動作環境がGoなら、開発時と実行時でブラウザが違うことになるんで、Javascriptもそれなりの対応が必要です。
URLにdata:を使ってると、WindowsのFMPro上ではfile:で動きます。
開発時に動いてもGoで動くかどうかは全くわかりません（逆に開発環境で動かないものがGoでは問題なかったりする）ので、「不向き」といえなくもないかな。
JavaScript:スキームが通るのは Windows 環境だけなので、他のデバイス環境では無理でしょう。
Offline
すみません、、問題の切り分けをさせてください；
まず、今回Webビューア×JavaScriptを試みようと思ったのは、昨年のFileMakerカンファレンスの以下のセッションを視聴し、いろいろ試してみたいと思った次第です。
https://www.youtube.com/watch?v=7banO9p-SeU
このセッションには大変感銘を受けたのですが、実際に自分で作成してみて、Webビューアの機能制限、Goでの動作の違いがいまいちわかっていません。
Webビューアでできることはどの程度なのか
(静的HTML + ユーザイベントJavaScript(onclickなど)までなのか、動的にHTMLを書き換えることは不可能か)
例えば、通常のブラウザでも、ページ上で右クリックして取得することができるのは、JavaScriptが実行される前のHTMLソースであるように、Webビューア設定の「Webアドレス」に指定したHTMLソースの範囲でしか動作できないのか…。
また、外部APIを利用するには、URLを参照するのではなく、APIのJavaScriptソースを直接Webビューア内に記述しないといけないのか…。
そしてGoで動作させた時の違いなど；
リファレンスなどで読んでおくべき箇所などありましたらご教示願えますでしょうか。
少々迷宮に踏み入ってしまっておりますので、頭のなかを整理したいと思います；
結局、通常のブラウザでできるから、Webビューアでもできるだろうと考えていたことが、実際にやってみるとかなりの制限があることにどうしたらいいものかと悩んでいる次第です。
Goでだけ動作すればいいなら、WindowsでなくMacを使えば、それなりに開発作業ができるんでしょうかね。。。ブラウザのエンジンが同じだとしても、iOSとOSXじゃやっぱりかなり違うのかな。
JavaScriptの動作はブラウザと同じですが、レジストリをいじらないとIE9エミュレーション状態です。
data:で表示させたwebビューアのソースをファイルに保存して、それをIEで開いてIE9モードで動作するか確認してみれば、どういうものかわかるかな。
JavaScriptのマルチプラットフォーム対策は、昔から先人達の悩みの種です。
とりわけ、windows の ms JScript は独自拡張が多く注意です。
事象ごとケースバイケースでトライアンドエラーして行くしかないのかも！
Offline
scripterさん、Hiroさん、ご回答ありがとうございます。
まさかIE9エミュレーションとは…；
他の仕事でWebアプリケーションの開発を行うこともあり、そこでもブラウザ間の違い(これも往年の課題ですが)やバージョンの違いに悩まされていますが、やはりFileMakerでも似たような問題があるのですね(- -;)
しかし、WebビューアがWindowsでいうIE9に近い環境で動作していることがわかったことでもかなり助かりました。
あとはiOSでどうなるかもテストしてみます。
もう少し試行錯誤してみたいと思います。
もし、どなたかIFrame Player APIを利用した経験がある方がいらっしゃいましたら、対策などご教示願いたいです。
できたら頑張ってみたいところですが、ダメならダメで対策を練りたいと思います。
scripterさんから、Windows環境でのFileMaker Proのwebビューアは、IE9エミュレーションで動作していると教えて頂きました。
しかし、やはりFileMaker Goでの動作に違いがあり、手間取っています。
FileMaker GoのWebビューアは、ブラウザで言うどのバージョンのコンポーネントを使っているのでしょうか。
Safariであることはだいたい検討がつくのですが、バージョンやJavaScriptの互換性など、わかる方いらっしゃいますでしょうか。
モバイル系Webアプリの開発経験が無いので、何から調べていいものかわからない状態です。
UIWebViewなのかWebKit Frameworkは判別出来ませんが、
UserAgent見る限り、その端末のiOSのWebKitコンポーネント使ってるだけに見えますし、
iOSではそれが通常というか、Appleと特別な契約でもしない限り他の方法は無い筈です。
もちろんGoのために何らかのフックは色々入れてるでしょうし、
それが原因で端末標準のSafariとは異なる動作をする場合もあるでしょう。
バージョンや個々の機能の互換まで厳密に、ブラウザがどういった状態か確認したければ、
DOMやJSのAPI、CSSのプロパティなどの差を利用して判定していくしかないと思います。
そこまでの互換性を求められるWebアプリケーションは近頃無いので、
既存のそういったライブラリがあるかは確認していません。
-
> しかし、やはりFileMaker Goでの動作に違いがあり、手間取っています。
違いの内容次第ですが、経験上、その時点の端末標準のSafariと、
JavaScriptやDOMについてはほぼ同様に動いてくれます。
CanvasやWebGL辺りも同じように動いてました。
ただし、Web StorageのようにUIが絡み得る辺りは差異もあるかも知れません。
-
> また、外部APIを利用するには、URLを参照するのではなく、APIのJavaScriptソースを直接Webビューア内に記述しないといけないのか…。
これ気になったんですが、「URLを参照」「APIのJavaScriptソースを直接」が、
どういう形態を指しているのかよく分かりません。
とそもそも最近のAPIの多くは、URLの単純なGETではなく、
ヘッダに何らかのキーを要求されることが多いですが、
これはWebViewerだろうがスタンドアロンのブラウザだろうが事情は同じです。
JavaScriptからリクエストヘッダの設定は可能ですが、
当然ユーザーに閲覧可能な状態でキーを置くことになるため、用途は制限されます。
IFrame Player APIのようなAPI用のライブラリ（JSファイル）の読み込みの話であれば、
アドレスさえ解決できれば、WebViewerからの読み込み自体は問題ありませんし、
JavaScriptの動作そのものは、Safari同様の筈です。
-
余談です。
WebViewerを含めたFileMaker単独でWebを有効活用しようとすると、
URLから挿入等のスクリプトステップはあまりに機能が不足しており、
WebViewerを経由する場合はFileMakerとの中途半端な連携しかできません。
UIやレンダリングの面でも、WebViewerの操作にdataスキーム使わざるえなかったり、
GetLayoutObjectAttribute()の挙動がプラットフォームごとに異なったり、
Webへの窓口をその名の通りViewerとしか考えていないFileMakerの設計思想自体が、
Web技術へのまともなコネクションを提供する気がないように見えます。
私自身は使い捨てでない限り、FileMakerとWebを連動させたい場合には、
自分でブリッジとなるWebアプリケーションを書き、それを各ローカルホストで稼働させています。
リクエストもレスポンスもFileMaker側で扱いやすいよう、
シンプルなデリミタをWebアプリケーションにパースさせています。
動画だとか、チャートだとか、ドキュメントだとか、Webの表現力を使いたい場合でも、
FileMaker側で組み立てる手間を考えると、別途Webアプリケーションなり静的ファイルを用意し、
FileMakerからは単純にGETで取れるようにしておく、という方がすっきりします。
ブリッジ用のWebアプリケーションは何で書いても大差ないですが、
最近は、単一バイナリの配置で済んでしまうGolangを主に使用しています。
ローカルホストでの稼働が難しかったり、外部からの利用が必要になっても、
無料で使えるデプロイ先もありますし。
CSSを使ってブラウザを判別してるページ
http://browserstrangeness.bitbucket.org/css_hacks.html
iOSは殆どないみたい。
hondaさん、大変貴重なご意見をありがとうございます。
> また、外部APIを利用するには、URLを参照するのではなく、APIのJavaScriptソースを直接Webビューア内に記述しないといけないのか…。
これ気になったんですが、「URLを参照」「APIのJavaScriptソースを直接」が、
どういう形態を指しているのかよく分かりません。
とそもそも最近のAPIの多くは、URLの単純なGETではなく、
ヘッダに何らかのキーを要求されることが多いですが、
これはWebViewerだろうがスタンドアロンのブラウザだろうが事情は同じです。
JavaScriptからリクエストヘッダの設定は可能ですが、
当然ユーザーに閲覧可能な状態でキーを置くことになるため、用途は制限されます。IFrame Player APIのようなAPI用のライブラリ（JSファイル）の読み込みの話であれば、
アドレスさえ解決できれば、WebViewerからの読み込み自体は問題ありませんし、
JavaScriptの動作そのものは、Safari同様の筈です。
この件については、C3.jsとD3.jsを使用してグラフ表示するソリューションを紹介しているページにて、jsソースを<script></script>の間に直接挿入する、といった説明を見たことによりますが、
よくよく見ると、iPad上でオフラインでも使用できるように、と説明されていましたので、私の早とちりでした；
私自身は使い捨てでない限り、FileMakerとWebを連動させたい場合には、
自分でブリッジとなるWebアプリケーションを書き、それを各ローカルホストで稼働させています。
リクエストもレスポンスもFileMaker側で扱いやすいよう、
シンプルなデリミタをWebアプリケーションにパースさせています。動画だとか、チャートだとか、ドキュメントだとか、Webの表現力を使いたい場合でも、
FileMaker側で組み立てる手間を考えると、別途Webアプリケーションなり静的ファイルを用意し、
FileMakerからは単純にGETで取れるようにしておく、という方がすっきりします。
今回Webビューアを使用したWebとFileMakerのやりとりを実際に作成してみて、確かにシンプルなほうが分かりやすいですし、やりやすいと実感しています。
カスタムページを作成したうえで実現しようとしているので、WebビューアだけではなくWebアプリ開発における知識も十分とは言えないのが事実です(恥ずかしながら…)
スクリプトについては少しずつデバッグして動作を確認してみます。
そのうえで、実現できることとできないことの判別をつけていきたいと思います。
ネットで検索してもあまり深いとろこまでやられている例が見つかりませんでした(それこそシンプルなやりとりが求められている証拠なのかもしれません)ので、hondaさんの意見は大変参考になりました。
感謝致します。
CSSを使ってブラウザを判別してるページ
http://browserstrangeness.bitbucket.org/css_hacks.html
iOSは殆どないみたい。
scripterさん、ありがとうございます。
このページは今後の仕事においても大いに活用できそうです！
Webビューアでも表示して確認してみます。
ご意見や情報提供をしていただき、誠にありがとうございました。
途中経過ではありますがご報告です。
Webビューア上にて、IFrame Player APIを使用した動画の読み込みができました。
やはりhtml構文によるエラーや、API読み込み時のjavaScriptの構文エラーがありました。
html構文によるエラーは、生成したhtmlソースをIEなどのブラウザで表示した際に、デバッガでエラーが確認できましたが、javaScriptの構文エラーに関してはデバッガでも正常に処理できるものとして認識されてしまっていたため、原因特定に時間がかかりました。
(widthとheightの指定を'(シングルクォート)で囲っていなかっただけだったんですがorz)
今手元にiPadが無いのでそちらでの確認はまだですが、作業を進めることができそうです。
改めてHiroさん、scripterさん、hondaさんに感謝申し上げます。
参考になったようで良かったです。
scripterさんが挙げていたCSS Hackによるブラウザ判定ですが、
広範なCSSのプロパティ等とブラウザをサポートする http://caniuse.com/ があり、
そこで提供されているテストスイートを利用するのも良さそうです。
Caniuse test page
http://tests.caniuse.com/
今回は特に問題ではなかったようですが、
ブラウザの細かなバージョン把握は、いずれどこかで必要になるかも知れません。
hondaさん、情報を提供して頂きありがとうございます。
どちらのサイトも、FileMakerに限らずWebアプリの開発をする際に大いに役立ちそうです！
今までデスクトップ系の開発ばかりしてきましたので、これを機にモバイル・タブレット系の勉強にも力を入れたいと思います。
Pages: 1
[ Generated in 0.005 seconds, 7 queries executed - Memory usage: 579.41 KiB (Peak: 616.32 KiB) ]