MIT App Inventorで遊ぶ (New York Timesアプリ２）

MIT APP Inventorには、SpeechRecognizer というcomponentがあり、例えば「次」と言えば、次のページに進むようなアプリができるようだ。もちろん、「戻る」と言えば、前のページに戻ることができる。

このような面白そうな、遊べるcomponentもいくつか用意されているようだ。

また、一覧リスト(ListView)の記事をタップしたら、該当のNYT記事のサイトを見ることができるようにした。サブスクしていないと、数回しか無料で見ることはできないと思う。

実行画面：

スクリーンのデザイン：

Screen1に「<<」（戻る）と「>>」（次）ボタンの代わりに、「Speak」ボタンを設定した。

また、追加したスクリーン(webScreen)にWebViewer componentを設定した。「X」は戻るボタン。

　　　　　　　　           

プログラム（ブロック）：

「Speak」ボタン（speechRecognizerButton）をタップしたらSpeechRecognizerが起動し、話すのを促す。

話した内容をSpeechRecognizerが取得したら、もし、「次」と話したのなら、ページを１つ進める。「戻る」と話したのなら、ページを１つ戻す。というとても簡単なブロック・コードを追加するだけ。もちろん、「戻る」の場合は現在のページ数が１超の場合のみ。

「media」という分類があるが、そこには、SpeechRecognizerのほかに、Camcorder、SoundRecorder、TextToSpeech、Translator、VideoPlayerのような興味をそそるcomonentsが用意されている。

Translatorなんか面白そう。アルファベット2文字言語コード（多分、ISO 639 コードかな？）で指定。どれだけ翻訳、通訳（SpeechRecognizerやTextToSpeechと組み合わせて）ができるか、いつか試したい。YouTubeのTutorialもいくつかあるし。

******************************************************************************:::::

webScreenへの遷移部分のブロックは以下。

＜Screen1での追加部分＞

procedure "makeWebURLList "を実行する部分

procedure "makeWebURLList"により各見出し記事に紐ついたウエッブサイトのURLのリストを作成

すなわち、サーバーより取得したデータは以下のような内容なので、response => docs => we_urlと辿ってURLを取得している。

response（キー）と対になっているdocs（値）をゲット＝＞docsはリスト形式で７日間のお天気データを持っているので順番にゲットしていく＝＞ゲットした1日分のデータ（Dictionary型）の中で、web_urlをキーにしている値（URL）をゲット。

一覧表(ListView)のタップした記事にURLがあれば、webScreenに遷移し当該URLを渡す。URLがなければ、「No websites」と表示。

webScreen側のブロッックは以下の通りシンプル。

受け取ったURLをWebViewerで表示。backButton(X)をタップすれば、元のScreen1へ戻る。

 

MIT App Inventorで遊ぶ (素人は簡単なことを必要以上に難しくする）

私のような駆け出しの素人がやると、アプリが動けば万々歳。その結果、必要以上に複雑なブロックを組んでしまう（力づくでアプリを動かそうとする）みたいだ。もう少し勉強が必要かな？

1. その１＞Journalアプリでは、更新と削除の部分に引っかかって苦労したが。。。

今、あるPublic APIを使ったアプリを作成中だが、その過程で気が付いたのだが、あんなに悩むことはなかったようだ。ListViewをタップすれば、自動的にindexを取得できるので、そのindexでIDを特定すれば非常に簡単だったようだ。

２. その２＞ListViewの使い方

ListViewでは画像（天気アイコン）を表示するのは無理だろうと、勝手に思い込んで画像と天気情報を連結して７つ縦に並べて表示した。でも、実際は、ListViewで画像を表示することも可能であり、また、うまくデータを連結すれば、ListViewで多くのデータを表示することが可能だとわかった。

もちろん、画像のサイズの変更はできないようなので（いや、できるかもしれない。思い込みは禁物。）、体裁を整えるという点ではListViewではなかなか難しいところがあるのも事実だが。

以上、まだまだ勉強することが多いなあ〜とため息をつきながら、次のアプリ作成に取り組みたいと思う。でも、MIT App Inventorは面白い！！そのフットワークの軽快さは最高！！

 

 

MIT App Inventorで遊ぶ (New York Timesアプリ１）

New York Times誌は、 The New York Times Developer Network というウエッブサイトを持っている。同誌のAPI（Archive）を利用すれば、1851年まで遡って記事を検索できるって〜

"The Archive API returns an array of NYT articles for a given month, going back to 1851."

え〜そんなことができるの！

NYT誌の記事検索アプリを作って1981年の記事を見てみたい、と思った。ただ、NYT誌をサブスクしていないので、記事自体を見ることができるかどうかは？？？？？でも見出し記事くらいは読むことができるだろう。

実行画面：

なお、1851年の記事に出てくる見出しを興味本位にいくつかググってみて、古い歴史上の出来事に関する記事をこんなに簡単に検索できることに感心した。（追記あり）

スクリーンのデザイン：

今回は、いたって簡単デザイン。データを取得する「Get 1851 Articles」と次のページ「>>」ボタンとページを戻るボタン「<<」

   

データを表示する ListView の Behavior（挙動？）を設定する欄に、「ShowFilterBar」がある。今回は、これにチェックを入れた。上記画面のスクリーンショットにも「Search list...」が表示されている。

プログラム（ブロック）：

1. データ取得ボタンをタップした時の処理

page => 対象ページを格納。最初は１ページ目。

対象期間として18510101（1851年1月1日）から18511231（1851年12月31日）の期間を設定

sort =oldest => データ表示は昇順（古いものから新しいもの）

2. 変数の設定

JSONData => 取得したデータを格納

tempHeadlineList => 見出し記事を格納

tempDateList => 日付を格納

combinedData => 見出し記事と日付を連結したデータ

allDataList => 見出し記事と日付を連結した全てのデータを格納

2. procedure "makeHeadlineList" 及び "makeDateList"を実行し、見出し記事と日付のリストを作成。

見出し記事と日付を連結したデータのリストを作成。

作成したリストをListViewに表示させる。

3. １ページの中の記事数を取得

4. 見出し記事のリストを取得

5. 発行日のデータを取得

6. 見出し記事と発行日を連結する

7. 「次のページ」ボタンと「前ページ」ボタンをそれぞれタップしたときの処理

変数pageに１加算、又は１減算し上で、再度データを取得する（procedure "getWeb" 実行）

追記：例えばこれ。「1851 Lancaster Riot」でググってみると、かなり多数の記事があった。

 

MIT App Inventorで遊ぶ (Journal アプリ４ D / REST API）

まだ、ユーザーフレンドリーに欠ける点があるが、一応、CRUD（新規データ保存、データ取得、データ更新、データ削除）が出来るアプリとなった。「Save」「Update」「Delete」ボタンをタップした後、最新のデータがリアルタイムで表示されるようになった。しかし、タイミングが合わない場合は、「NOT FOUND」と表示されることがたまにある。

例えば、データ保存の場合、「保存」=> 「Tag(ID)リストの取得」=> 「データの取得」と3回データベースとの間にやりとり（セッションと言った方がいいのかな）があるが、データベース側で保存の処理が終了しないのに、データ取得をしようとしたりするのが原因ではないかと思う。確かなことは分からない。

ネットワークでは、多分こんなことはよく起こることだと思うので、このような場合のエラー処理を検討したい。そう言えば、今まで、まともにエラー処理は考えたことがない。（response codeが200の場合-成功-を除いて。これはチュートリアルに記述してあったので、そのまま使っているだけ）

実行画面（これは、たまたま上手く行った時のキャプチャー）：

スクリーンのデザイン：

「Delete」ボタンと「Reset」ボタンを追加した。

                                     

プログラム（ブロック）：

「Delete」ボタンに関係のある部分のみ

1. ボタンのオリジナルカラーである薄緑色を返してくれる procedure "originalGreenColor" を定義。procedureには2種類ある。「return」があるprocedureは、procedure の結果を返してくれる。「do」はprocedureを実行するだけ。

procedure "updateData" はボタンを初期の状態に戻すもの。

2. データを削除

    Web4 componentのターゲットとするURLにIDをセットする。

    HTTP DELETEリクエストにより同IDも持つデータを削除。

    その後、再度削除後のTagリスト（callGetTag）、そして削除後のデータ（getData）を取得しListViewに表示することになる。

    Clockを使って、800ミリ秒の余裕を設け、タイミングを調節している。

まだまだ課題はありそう。

 

MIT App Inventorで遊ぶ (Journal アプリ３ U / REST API）

Journalアプリのデータ更新については、試行錯誤の結果、

1. ListViewで選択されたデータの中から日付データを抽出し、全体の日付データリストの中での同データのindexを取得

2. 一方、すべてのIDを格納しているtag list より上記indexに該当するIDを取得

3. 同IDをキーにして、更新したデータと共にPUTリクエスト（上書き）を行う

試行錯誤の途中ですべてのデータを削除してしまったりと時間がかかったが、どうにか解決策が見つかった。

実行画面：

今回は、最終のアプリという形ではなく、実験する過程をキャプチャーした。

実験を画面（静止画）で見ていくと。。。（上記実行画面では、円山公園を大友古墳に変更）

アプリを立ち上げた時　　　　　　　　　　　　Fetchボタンをタップしてデータを取得

　　　　

ListViewより更新したいデータを選択　　　　　Articleの内容を変更。「どこかに。。。」を「円山公園に。。。」に変更し

　　　　　　　　　　　　　　　　　　　　　　Updateボタン（更新ボタン）をタップ

　　　　

再度、Fetchボタンをタップし、更新後の

最新のデータを取得

スクリーンのデザイン：

Updateボタンと確認用のLabel３つを追加しただけ。

　　　　　

プログラム（ブロック）：

更新の部分のみ。

1. keyDate => 更新対象データ（ListViewでタップしたデータ）の日付

dateIndex => 更新対象データの日付の日付リストの中でのindex（このindexをキーにして更新対象データのIDを取得）

2. 更新対象のデータをListViewでタップして選択。=> Save及びFetchボタンを無効にする。（後述のprocedure "selectListView"を実行）=> 更新対象データは、split ブロックにより日付(date)、タイトル(title)、記事内容(todo)の３つに分解。=> タイトルはtitelTextBox、記事内容はtodoTextBoxに表示。

dateList（取得したデータの日付のリスト）の中での日付(date)のindexを取得。=> 同indexに該当するtagList（取得したデータのIDのリスト）のIDを取得（これが更新対象データのID)

testLabel1及びtestLabel2への表示は確認のためのもの。

3. 上記で取得したID (updateKeyTag)をターゲットにして、date, title, journal(記事内容)を上書きする（PUTリクエスト）。

4. testLabel3に確認のために更新後のデータを表示する。ちょっとネーミングが悪いが、procedure "updateData" によりSave及びFetchボタンを有効にして、Updateボタンは無効にする。

*****************************

update（更新）ができると、delete（削除）も当然可能と思う。

いくつか問題は残っているが、次回は画面の体裁を整え、その他微調整なども行いたい。