読書会(プログラミングAndroid)第6回議事録

============================================
Java読書会BOF 「プログラミングAndroid」を読む会第6回
============================================

.. csv-table:: 開催概要

"日時", "2012年12月15日 10:00 - 17:00"
"場所", "川崎市産業振興会館　第１会議室"
"出席者(敬称略)", "今井、岩室、遠藤、門脇、高橋(徹)、高橋(智)、中島、松永、水越、村山、山中、吉本(書記)"

議事
====

11.2 フラグメントのライフサイクルの視覚化
-----------------------------------------

11.3 Activityクラスと振る舞いのよいアプリケーション
---------------------------------------------------

11.3.1 Activityのライフサイクルとユーザー体験
---------------------------------------------

11.4 Applicationクラスのライフサイクルメソッド
----------------------------------------------

11.5 複数のアクティビティ間の流れと直観的なユーザーインターフェース
-------------------------------------------------------------------

11.5.1 小さな画面環境のマルチタスク
-----------------------------------

11.5.2 タスクとアプリケーション
-------------------------------

11.5.3 起動とタスクの振る舞いの設定
-----------------------------------

12 コンテンツプロバイダの使用
-----------------------------

12.1 コンテンツプロバイダの理解
-------------------------------

12.1.1 コンテンツプロバイダの実装
---------------------------------

* p.314　誤字　AndroidManifestxml　→　AndroidManifest.xml

12.1.2 Finchを使ったビデオの閲覧
--------------------------------

12.2 プロバイダのpublic APIの定義
---------------------------------

12.2.1 CONTENT_URIの定義
------------------------

* SimpleVideosの定義が違うが同じクラスなのか？

* 同じクラス名なのに、extendsとimplemrntsで違う。

* AUTHORITYとSIMPLE_AUTHORITYが使われているが、どちらなのか？

* 謎

* RESTぽい構文が使用されているので、RESTはまだ生き残っているように思われる。

* コンテンツプロバイダは、アプリケーションと一緒に入れるものなのか？　コンテンツプロバイダだけを入れるものなのか？

* ケースバイケースと思われる。

* 依存関係はどのように処理されるのか？

* 同じものなら先に入っているものが優先されるのでは？

* Manifestファイルを見るしかない。

* 被らないのが当然として作られているっぽいが・・・

12.2.2 列名の作成
-----------------

* p.319　誤字　派生的　→　は静的

12.2.3 列を指定するストリングの宣言
-----------------------------------

* IDを再利用させないというのは重要。

* Window IDやプロセスIDも再利用されて予期せぬ動きをしてしまう。

* IDは再利用しない方がいい。

* 定数はプロパティで持つものでは？

* Androidのライフサイクルの関係でメモリ上から消えてしまう可能性があり、動的なものは再度読み直す必要がある。

* Androidのstatic変数の状態はあやしい。

* AndroidのプロセスのライフサイクルがPCと違うので、予期しないタイミングで初期化されてしまうことがある。

* 永続化システムやシリアライザを使うべき。

* 外からオープンソースのライブラリを簡単に持ってくるのも危ないかも。

* 列名などを使用する方は、文字列で待つしかないのか？

* プロセスが違うので、文字列で持つしかないのでは？

* メタデータのように取得する術はないのか？

12.3 コンテンツプロバイダの記述と統合
-------------------------------------

12.3.1 コンテンツプロバイダの一般的な作業
-----------------------------------------

12.4 ファイル管理とバイナリデータ
---------------------------------

* pictureの属性は、なぜBLOBではなくTEXTなのか？

* 直接データを持たないで、データの場所を指すパスを持つため。

* userテーブルとuserPictureテーブルのリレーションはどのようにするのか？

* userテーブルのpictureが、userPictureテーブルを指すポインタなのか？

12.5 Android MVCとコンテンツの観察
----------------------------------

12.6 コンテンツプロバイダの完成：SimpleFinchVideoContentProviderのコード
------------------------------------------------------------------------

12.6.1 SimpleFinchVideoContentProviderクラスとインスタンス変数
--------------------------------------------------------------

12.6.2 onCreateメソッドの実装
-----------------------------

12.6.3 getTypeメソッドの実装
----------------------------

12.6.4 プロバイダAPIの実装
--------------------------

* 正常系の処理をif文で切り出すより、先に異常系の処理をした後、最後に正常系を処理する方がソースが読みやすい。

* SQLExceptionをthrowしているが、throws節は要らないのか？

* このSQLExceptionはAndroidで定義されたExceptionで、RuntimeExceptionなので必要無い。

12.6.5 オブザーバーへの通知頻度の決定
-------------------------------------

12.7 コンテンツプロバイダの宣言
-------------------------------

13 コンテンツプロバイダを探る
-----------------------------

13.1 RESTful Androidアプリケーションの開発
------------------------------------------

13.2 Network MVC
----------------

13.3 メリットのまとめ
---------------------

13.4 コードサンプル：動的なリスト表示とYouTubeビデオコンテンツのキャッシング
----------------------------------------------------------------------------

13.5 Finch YouTubeビデオサンプルソースコードの構造
--------------------------------------------------

13.6 検索アプリの動作段階
-------------------------

13.7 段階１：UIでユーザー入力を得る
-----------------------------------

13.8 段階２：コントローラがイベントを監視する
---------------------------------------------

13.9 段階３：コントローラがコンテンツプロバイダ／モデルに対しmanagedQueryでクエリを送る
---------------------------------------------------------------------------------------

13.10 段階４：RESTful要求の実装
-------------------------------

13.10.1 定数と初期化
--------------------

13.10.2 データベースの作成
--------------------------

13.10.3 ネットワーク対応のクエリメソッド
----------------------------------------

* p.350の①の記述の意味が分からない。

* Webサービスに渡す検索キーワードは、queryメソッドの引数では渡せないということ。

* 引数のwhereArgsは、別の目的に使用されるため。

* 引数のURIのパラメータに含める形で渡さないとならない。

.. note:: 次回は、p.354「13.10.3 ネットワーク対応のクエリメソッド　UriRequestTask」から。

[ 戻る ]