==== Lecture ====
Section 2: Introduction to Android Services and Security (1:56)
Activity(UI)とは別にbackgroundでサービスを実行するprocessがある。
これとUIはIPCで通信する。
セキュリティモデルとセキュリティを確保する方法についても学ぶ。
Section 2 Module: Introduction to Android Services and IPC (1:55)
binder OORPCで Activity と Service の間のmessage passing を行う。
HaMeRをプロセス間通信に拡張。Android Interface Definition Language も説明。
Section 2 Module 1 Part 1: Overview of Android Services (9:52)
[StartedService]
clientから発行されたら実行して勝手に終わる。
結果がclientに返されない場合もある。
onStartCommand()
[BoundedService]
clientからbindされたらunbindされるまで実行される。
IPCでclientと通信する。
onBind()
onUnbind()
[共通]
clientと同じプロセス、違うプロセスどちらにするかはManifest.xmlで選択。
onCreate()
onDestory()
[pattern]
activator, command process, active object, proxy, broker, publish describer
[canonical framework techniques]
Service classを拡張してtemplete methodでlife cycleに必要なmethodを実装する。
Androidにも色々なServiceが元々実装されている。
Section 2 Module 1 Part 2: Programming Started Services (Part 1) (9:06)
[StartedService]
Download Applicationを例にする。
このMOOCでは一番複雑な例。色々な要素を使っているので色々学べる。
clientがstartService()を実行する。clientはblockされない。
ActivityManagerがサービスを起動する。
onCreate(),onStartCommand()がActivityManagerから実行される。
onStartCommand()の結果はclientには返されない。非同期実行。
Androidにprocessがkillされた場合にどう扱うべきかを伝える。
sticky: 同じintent(パラメータ)で実行されることはない
no_sticky: 明示的に再開されるまでstopped状態で待機する。
redeliver_intent: 再開されたときに同じintent(パラメータ)が使われる。
処理はHaMeRを使って実行される。
終了後はclientに結果を直接知らせずにonDestroy()する。
この時に他の部分から確実に使われていない状態でDestory()するのが重要。
Command processor patternになっている。
同時に複数のrequestを処理しない場合に適している。
Inversion of Control (IoC)(制御の反転)
Javaではそこそこ一般的な用語の様子。
ハリウッドの原則 (Hollywood Principle) とも呼ばれる。
何時どのように応答するかを呼ばれた側が制御する設計。
制御をmainではなくてsubのmoduleに任せるやり方。
全体を疎結合で構成する事が出来るが、各部分間の協調は難しくなる。
Section 2 Module 1 Part 3: Programming Started Services (Part 2) (8:58)
[StartedService]
Download ActivetyでurlからDownload ServiceのIntentをFactory methodで作成。
その後startServiceを起動。結果はDownloadHandlerで受け取る。
Download ServiceでmakeIntent()を実装。これをActivetyから呼び出す。
結果をActivetyに伝えるためのDownloadHandlerの登録も行う。
Looper, ServiceHandlerはvolatile宣言する。
onCreate()でThreadを起動。LooperとServiceHandlerを取得。
onStartCommand()でServiceHandlerに送るMessageを作成、送信。HaMeR。
not_stickyでプロセスkill時に自動再スタートしない旨を通知。
ServiceHandlerでMessageを処理。
stopSelf()で完了後に自動的にDestory()する。
次のMessageの処理中にonDestory()しない様に、完了したMessageのID(arg1)を渡す。
最後のrequestのIDとmatchした場合だけServiceをstopする。
DefaultではServiceはUIのThreadを使うが、処理が長いとANRエラーになってしまう。
なので、Serviceを別processで実行する。
I/O主体のServiceはHaMeRの様なframeworkを使う。
バグを防ぐためにCommand Processor patternを使ったIntentServiceのframeworkを使う。
Section 2 Module 2 Part 1: Traditional App Accounts
[Traditional App Accounts]
講師が変わった。
普通のDesktopなどのAppは起動したuser accountの権限で実行される。
全てのAppが同じ権限で実行される。
あるAppから他のAppが保存したデータや情報を見たり、書き換えたり出来てしまう。
Section 2 Module 2 Part 2: Mobile vs. Traditional App Accounts
[Movile App Accounts]
個々のAppがそれぞれ独立したuser accountを持っている。
App毎に権限が異なる。起動したuser accoutの権限よりさらに制限される。
??権限がuser accountより増えることはあるのか??
App毎にアクセス出来るデータ領域が異なる。
Section 2 Module 2 Part 3: App Account Mapping to Linux Users
[Mapping to Linux Users]
ManifestにAppの権限を記載。
ユーザにこれを提示して許可を求める。
App毎にLinuxの別々のuserになっている。
Linuxのgroupも設定されている。Appのgroupも設定されている。
Section 2 Module 2 Part 4: The Apps are People Analogy for Malware Attacks
[Malware]
Malwareについて通常の人間社会での悪人と被害者の比喩で説明。
Malware自体には権限などがなくてもMalwareを信用しているgood appに悪さをさせる。
lie, steal, manipulateの三つが主な不法操作。
Section 2 Module 2 Part 5: How Android Protects Apps
AndroidのAppはlinux上の別々のprocessで実行される。
memory空間は分離されているので他のAppから直接memoryを書き換えられ打事はない。
storageも分離されている。apkやdbやApp privateのstorage。
Section 2 Module 2 Part 6: What Android Doesn't Protect
process間で何らかのinteractionがある場合は注意が必要。
IPCを使う場合はその結果が自Appのメモリを書き換えることになるかもしれない。
sd cardを経由してデータをやり取りする場合は共有資源になる。
strorageでもpermissionを変更することで他のAppと共有して読み書き可能に出来る。
GUIを使って他のAppに入力されるべきデータをmalwareに入力させようとするかも。
==== Quiz ====
講義に合わせてQuizも11個ある。
今回はmpeg4形式でダウンロードしたものを見ていたので、Quizはぶっつけに近い。
Quizを見てからその内容だけは聞き逃さないように視聴した方が良いかも。
1回目41/47、2回目45/47、3回目47/47
??Quiz 7 だけは回答が説明と合わない気がするが。。。
Forumを見ても特に話題に上がっていないので単なる勘違いか??
==== Assignment ====
[Week-5-Assignment-4]
今週もping-pongプログラムだが、遂にAndroid上で動かす事に!
最新のSDKはtarget=android-19で手持ちもこれ。project.properties内で定義。
課題は少し古くてandroid-17を使うようになっている。
下記によると手元でandroid-19で作成してsubmit時に17に戻すのでも良いらしい。
https://class.coursera.org/posa-002/forum/thread?thread_id=1332#post-4670
とりあえずandroid-17をinstallしたら動かせた。
TODOはAndroidPlatformStrategy.javaファイルの４カ所を埋めるだけ。
ConsolePlatformStrategy.javaとprint()以外は同じで良さそう??
print()はrunnableをlooperに渡すとかでLectureを見直す必要あり。
更にLectureを見直してframeworkの動きを押えるべきだが。。。
S1M2P10にそのままの例があった。。。Lectureをちゃんと見直すべき。
また、5th VOHでも多少言及はあり。
runOnUiThread(new Runnable () {
public void run () {
mTextView.append(outputString);
}}};
UI Threadからコールしたら単にrun()が関数実行される。
UN Thread以外からコールしたらUI ThreadにrunnableがmessageとしてHander.postされるto。
javaにはclousureが無いのでinner classでは自動変数はfinal以外は使えない。
@Overrideを書くか? Lectureでは書いていない。
done()もrunnableをUIに送るように書かれている。
http://developer.android.com/reference/android/app/Activity.html#runOnUiThread(java.lang.Runnable)
http://developer.android.com/reference/android/widget/TextView.html
setText(char[] text, int start, int len), setText(CharSequence text)
を使えば文字は出せる?
Toastを使えば簡単にポップアップの様なものを出せる。
try/finally, final, this, private, volatile, Lock, 初期化, fair, non-fair
static, join, interrupt, @Override
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で本体を取り出せる。
とにかくLectureに大体は例がある。
さらにForumをみれば大体疑問点は出尽くしている。
VOHでは提出済のモノは詳しい説明あり。提出前のモノは簡単な説明ある。
Your work was submitted. Review your work to make sure everything looks OK.
のリンクから提出状況を確認できる。submit直後のみ。
[Evaluation]
S1
@Override is used
Latch is not sent to UI on done().
TODO is replaced to DONE
S2
@Override is used
S3
@Override is used
Latch is not sent to UI on done().
Text is sent to Looper instead of Activity on print().
S4
Latch is not sent to UI on done().
S5
Latch is not sent to UI on done().
Text is sent to Looper instead of Activity on print().
mLatch is recreated redundantly.
Self
It may be better to use @Override.
It may be better no to send Latch to UI on done().
The major difference is to send text to UI or Looper.
The instructor said UI is better.
[Results]
無事満点で完了。下記コメントあり。
peer 5 → Well done. IMO, no need to do the mLatch.countDown() in a Runnable...
==== Etc ====
今週はLectureが11個ととても多い。大変そう。。。
Quizも11個。Lecture毎に一つという事かな?
javaではvolatileへのアクセスもatomicになっている。
java.util.concurrent.atomicを使うべき?
[Eclipse]
Java Applicationを動かすためにはRun configのclass pathからAndroid 4.2.2を消す。
何故かAndroidのEmulatorのAPI leveを17にすると起動しなかった。
EmulatorのAPI levelを19にして、プログラムの方は17にしても動いた。
その後API level17でもARMのEmulatorは起動してJUnitも通せた。
上手く行った理由は不明。またx86では起動しない。
==== log ====
2014/06/08 00:20 準備
2014/06/12 00:44 Lecture
2014/06/13 00:50 Lecture
2014/06/16 00:50 Lecture & Quiz
2014/06/18 01:00 Assignment
2014/06/19 00:30 Assignment
2014/06/21 02:00 Assignment
2014/06/27 01:00 Evaluation
2014/07/01 00:10 Result
0 件のコメント:
コメントを投稿