==== Lecture ====
Section 2 Module 1 Part 4: Android IntentService (9:02)
通常のサービス
Service.onCreate(), Service.onStartCommand(), Service.handleMessage()
を実装する必要がある。
IntentServieは使うのが簡単。
onHandleIntent() hook methodをoverrideすれば良い。
Activator pattern
一度に一つのintentを一つのthreadで扱う事しか出来ない。
扱うintentが無くなったら自動的にstop()する。
Command Processor pattern
Section 2 Module 1 Part 5: Activity and Service Communication (13:26)
ActivetyとServiceを同じプロセスにするかはmanifest.xmlのservice定義。
defaultは同じ、だが分けた方が良い時もある。
複数のAppからshareされる時。
Appに影響を与えたくない時。
ServiceのGCでAppの性能を落としたくない時。
binder frameworkでIPCが実装されている。one-way or two-way, RPC(stub) or message
BoundService
BindService()で起動。messageをsendしてhanderで処理。HaMeR
Method call(RPC)も使える。AIDL compilerがstubを生成する。
sync, asyn, one-way, two-way色々出来る。
Replyにもmessageは使える。serviceのreferenceをmessageに入れる。
他にはMethod callbacksも使える。Activetyからcallback objectを予め送っておく。
two-wayであれば特別replyを気にする必要はないが、syncだとdead lock等の問題ある。
Activator pattern: 無駄ならリソースを使わないで複数のclientを扱える。
Activator MangerがServiceを新たに起動する必要があるかを判断して起動する。
Command pattern: 機能の断片をobject化して他のprocess,threadや後で実行する。
Intent Serviceでは処理を非同期で後で別のプロセスで実行するのに使っている。
Active Object pattern: 機能をobject化して他のprocess,threadで実行。HaMeR
Broker pattern: RPCを隠ぺいする。Bound Service。Proxy。
Section 2 Module 1 Part 6: Service to Activity Communication via Android Messenger (9:55)
Messenger: HaMeRをprocess間に拡張した様なもの。
Download Application
単純な場合はMessengerで充分。複雑な場合はAIDLのMethod call(RPC)を使う。
Activetyでは、Messageにはreplyのためのhandlerのreferenceを入れる。
これをIntentに入れてServiceに送る。startService()。Active Object pattern
Serviceでは、処理後にIntentからMessageを取り出す。
Messageの中のRelpy handlerを使って結果をActivetyに送り返す。Proxy
Section 2 Module 2 Part 7: Avoid Storing Sensitive Data in Public Locations (8:43)
SD Cardは全部のappから参照出来る。privateではなくてpublicになっている。
passwordはdiskに保存してはいけない。する場合はencrypt/hash/privateにすべき。
external storageにはsensitive dataは置くべきではない。
photoデータなどをstealされても構わないなら置いても良いかもしれない。
Section 2 Module 2 Part 8: Risks of Insecure File Permissions (5:46)
private領域のデータのでもpermissionは設定できる。
permissionを変えると他のAppでもアクセス出来るように出来る。
deviceのuserからはprivate設定でもApp内のデータアクセスできる可能性がある。
開発者自身のprivateデータをdiskに保存すべきではない。
?? Appのバイナリ内に埋め込まれている事自体も危険??
Section 2 Module 3 Part 0: The Challenge of Secure Coding (2:49)
どうやったら安全なコードが書けるか。
通常のApp開発者は上位レイヤーには詳しいが下位レイヤーは分からない。
開発者が間違わない様な抽象化(フレームワーク)を作ることが重要。
Section 2 Module 3 Part 1: Security Vulnerability Walkthrough (7:31)
privateとpublicを同じinterfaceで扱うような作りは間違いやすい。
privateとpublicを抽象化でまとめてパラメータで切り替えるような作りは危険。
プログラムとしては悪くないが、もっと開発者が間違い難い方法を考えるべき。
?? defaultを安全な方に振れば良い??
Section 2 Module 3 Part 2: Principles of Secure Abstractions (2:55)
開発者に分かりやすくする。
コンパイル時にセキュリティ的な問題を摘出する。
dataとsecurity sateの分離と保護。
Section 2 Module 3 Part 3: Avoid Coupling Data & Security State (5:01)
dataとsecurityを組にしたデータ構造はNG。
そのデータ構造でどの様な値でもsecurtiyを確保していることをテスト出来ない。
security sateの元ネタをユーザの入力に依存しているとそこを攻撃されやすい。
データ構造としてsecurity sateとdataを分離する。
更に改善の余地がある。
?? 今後のLectureで説明??
Section 2 Module 3 Part 4: Build Abstractions that are Hard to Use Insecurely (9:49)
開発者の労力が少ないとsecureに、insecureにするためには沢山の労力が掛かるようにする。
boolean isSecureだとdefalutはfalseなのでinsecure -> isPublicにする。
insecureならpublic、それ以外はprivateと言うようにdefaultをsecureにする。
privateなデータを保存していると明らかに分かるようにする。
enumで分かりやすい名前(SecurityLevel等)を使う。
Section 2 Module 3 Part 5: Bound & Strongly Type Security State (11:55)
enumの代わりにstatic final intのflagを使ったら何故問題あるのか?
intは範囲に制限がないので全ての値をtestする事が出来ないから。
定義値を後で増やした場合も増やした場合も分かり難い。
定義されていない値も使えてしまう。コンパイルエラーにならない。
値に意図しない演算が使えてしまう。コンパイルエラーにならない。
security stateとdata stateを型で分離できない。
security stateにそれ以外の間違った数値を設定してもcompilerエラーにならない。
開発者、テスト、コンパイラの視点からsecurity stateを制限、分離出来る様にする。
更に良くできる??
==== Quiz ====
1回目49/52
2回目満点!!
==== Assignment ====
[Week-6-Assignment-5]
imageをURLからdownloadするプログラム。だんだんアプリらしくなってきた。
単純にIntentServiceを使うパターンと同時に複数imageのdownload可能なThreadPoolExecutorを使うパターンの2通りを実装する。
TODOは3ファイル8カ所。
さらに提出不要でイメージをonlineで実際にネットから取るかofflineでローカルから取るかの設定もTODOになっている。(default offline)
This assignment is more difficult than previous assignments because the implementation is not clear as far as the lecture videos say.
Section 1: Module 3: Part 5: Sending and Handling Messages with Android Handler
Section 2: Module 1: Part 2: Programming Started Services (Part 1)
Section 2: Module 1: Part 3: Programming Started Services (Part 2)
Section 2: Module 1: Part 4: Android IntentService
Section 2: Module 1: Part 6: Service to Activity Communication via Android Mes
Section 2: Module 1: Part 3: Programming Started Services (Part 2)
Section 1: Module 3: Part 7: The AsyncTask Framework (Part 2)
http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html
null check of getString(),getData(),msg => may not
check msg.arg1 => must not.
https://class.coursera.org/posa-002/forum/thread?thread_id=1918
synchronized (this) {} on handleMessage() => probably not
try/finally, final, this, private, volatile, Lock, 初期化, fair, non-fair
static, join, interrupt, @Override, null check
constructorはlock不要。(W2-A1と同様)
volatileを使えばcacheの一貫性は保てる? => yes.
Uninterruptiblyでもtry/finallyするべき? => yes?
countのreturnでもlock必要? => no. volatileなら不要。
ローカル変数も初期化すべき? finalをつけるべき? => yes? 講師はfinal派?
thisはつけるべき? => 付けていない人の方が多い感じなのでつけないで命名規則で。
インスタンス変数にはmXxxxの名前にすべき? => yes.
importのunusedがある場合は親クラスとして使うかもしれない。
weekreferenceはgetで本体を取り出せる。
weekreferenceのnull check
ソースのコメントにも詳しい説明が書いてある。
とにかくLectureに大体は例がある。
さらにForumをみれば大体疑問点は出尽くしている。
VOHでは提出済のモノは詳しい説明あり。提出前のモノは簡単な説明ある。
Your work was submitted. Review your work to make sure everything looks OK.
のリンクから提出状況を確認できる。submit直後のみ。
[Evaluation]
S1
"import android.R.string;" is unused.
getApplicationContext() is used as context.
The return value of intent.getExtras().get() is casted with (Messenger).
S2
getApplicationContext() is used as context.
The return value of intent.getExtras().get() is casted with (Messenger).
S3
getBaseContext() is used as context.
The return value of intent.getExtras().get() is casted with (Messenger).
S4
The return value of intent.getExtras().get() is casted with (Messenger).
S5
getApplicationContext() is used as context.
The return value of intent.getExtras().get() is casted with (Messenger).
Self
"intent. getParcelableExtra()" is used.
I think it is better to use "intent.getParcelableExtra()" instead of "intent.getExtras().get()" because it is necessary to use cast.
getParcelableExtra() is added in API level 1, so I can use it to this course, which require API level 17.
[Results]
Perfect!
==== Etc ====
今週もLectureが11個80分ととても多い。大変そう。。。
Quizは13個。これも多い。
securityの視点からより良いコーディングを行うと言うのは面白そう。
どうやったら人が間違い難いコードを作れるかと言う事で、security以外でも通じる。
[Eclipse]
The Javadoc can be used when the code is seen.
The place where the word is used can be searched with "Reference".
==== log ====
2014/06/17 00:50 Lecture
2014/06/18 00:50 Lecture
2014/06/22 00:30 Quiz
2014/06/27 00:30 Assignments
2014/06/28 01:30 Assignments
2014/06/29 03:00 Assignments
2014/07/04 01:40 Evaluation
2014/07/09 00:10 Result
0 件のコメント:
コメントを投稿