WebView の見分け方

アプリで適当に画面遷移する
遷移に時間がかかってるな? と思ったら,機内モードに設定して画面遷移し直す.
ネットワークエラーの表示があったらWebView
ネットワークエラーの表示はないがやっぱり真っ白な画面だったりしたらよくできたWebView

クリーン

業務でもAndroidアプリを書いているが,そちらはもともとあったプロダクトにジョインしたのもあって,設計とかはままならないことも多い.
新しいことを試すような場でもないし.
そういうことをやるために,個人的な手習いでもAndroidアプリを書いている.
まあまだほんのちょっとだけど.

クリーンアーキテクチャのおかげで思考もコードもめちゃくちゃ整理されて本当に最高.
外部との操作を入力と出力で分割,さらに2段階で抽象化して,抽象レイヤーで入出力を結合する.
現状はこんな感じ.

- view
- presenter (viewからのイベント・入力を提供する)
- controller (viewへの操作・出力を提供する)
- repository (外部記憶への入出力を提供する.本当はここもpresenter/controllerにわけるとよいかもだがまだ小さいので)
- service (サーバーとかセンサーへの入出力を提供する.本当はここも以下同文)
- domain (controllerとかrepositoryとかを束ねるところ)
- input (入力を抽象化する層)
- output (出力を抽象化する層)
- interaction (入力と出力を結合する)

流れ的には,例えばユーザーからの入力をもとにほにゃほにゃして画面に出力だったら

view -> presenter -> domain/input -> domain/interaction -> domain/output -> controller -> view

とか,センサーの値を画面に出力だったら

センサー類 -> service (-> domain/input) -> domain/interaction -> domain/output -> controller -> view

とか,センサーの値を保存だったら

センサー類 -> service (-> domain/input) -> domain/interaction (-> domain/output) -> repository -> 外部記憶

みたいな感じ.
すごくわかりやすい.

serviceとかrepositoryはちょっとどれくらいの抽象度が必要かわかっていないので,domain/input,outputは保留中.
viewは必要だと思う.
view の入出力を切り分けるのがpresenterとcontrollerの役目.
切り分けた入出力を(viewではなく)ビジネスロジックとしての入出力に変換するのがdomain/input,outputの役目.

こうしてきれいにかけるとモチベーションがあがってくる.
なんとか形にしたい.

on the Rail

Railsをしばらくやって思ったのは,これはRubyじゃなくてRailsなんだなってこと.
フレームワークの上で各機能(ファイル)がどう連携をとるのかってのに現状のほとんどの時間を費やしてる.
フレームワークはただでさえ初心者に厳しい高度な技術なのに,どうやら激しくバージョンアップを重ねていることが災いして,有力な情報が簡単に手に入らない.
図書館の最新の本数冊が春休み期間中何者かによって押さえられていたってのもある.
今はRailsでのAjaxをいかに成功させるかに四苦八苦している.
はやく何者かに本を返してもらわねば.

DB

Railsの勉強をしたいってことでいつもとは違うキャンパスまで行って本を借りてきた.
しかし,待っていたのはそれ以前の問題,ほとんど暗黙の前提知識が抜けているという現実だった.
DBのことを何も知らない.
いつもなら読み飛ばしているサンプルプログラムを手打ちしようかというほどのモチべであったのに,そもDBを導入できないようではお話になっていない.
さきにDBからやらないと……

手段と目的

目的へ向かうのに最適な手段はなんなのか.
それを探しているうちに手段を探すことが目的になってしまう.

春休み前はJavaでGUIプログラミングを試みていた.
それなりの量を書いたのだが,やがてモチベーションが低下.
コードがスパゲッティと化して手に負えなくなってしまったのが原因の1つ.
なぜスパゲッティ化したのか考えてみると,UI部分とロジックの部分の分離がうまくできなかったことだという理由を見出した.
(まあコード力の問題もあるだろうがそこを改善するのは難儀なので)

なにかうまく分離できるものはないかといろいろみてみるとC#はWPFとC#でUIとロジックをわけられるらしい.
そういうわけでC#の文法を勉強してみた.
基本的な部分はわかったのだが,クエリとかラムダ式とかデリゲートとかそういう新しい言葉がピンとこなかった.
その上,WPFまわりを学ぶのにそこまでよい教材がなさそうだということもあって,C#は挫折.

それでしばらくプログラミング熱は冷めていた.
だが最近になってRuby on Railsというものを知った.
GUIアプリケーションというよりはWebプログラミングだそうだが,目的にはむしろそちらのほうがあっている.
MVCモデルというのも自分が考えていたUIとロジックの分離をさらに高尚にしたものである.
ビューをHTMLで書けるというのも楽でよろしい.
というわけでRuby on Railsの勉強をしてみようと本を探している.
ネットでいろいろRails入門をみてみたけれどいまいちピンとこなかったし.
いつも使う図書館に本はなかったので,ちょっと遠い図書館まで足をのばそうと思う.
プログラミング書籍は高いからおいそれと買うわけにもいかないしね.
併せてRubyの文法も学ばなければならない.
{}を使わずendを使うスタイルは好みではないけれど,{}はブロックなるものを作り,他言語とは一線を画す機能を提供しているようだ.

Rubyはどれほどモチべを提供してくれるだろう.

Eclipse

EclipseってGUIでGUI作れるのかすげー! ちょー便利ー!
って思ったら,コードをちょっと勉強してからコードをぽちぽち書いたほうが思い通りになるんじゃないか感が.
冬休みにちょっとしたのを作りたいなと思ってる.
その前にレポートを書かなきゃいけないという現実からは目を背けてるけど.

P

Perlはてきとうに書いても動くけど,動いてしまうからわかりにくい.

my %hash;
$hash{"a"} = [0,1,2];
my @array = $hash{"a"};#A

としたときに,
$hash{"a"}[0];

$array[0];
の値が違うというね.

$array = $hash{"a"}ではエラーが返されたから,#Aでは配列が確かに格納されているはずなんだけど.
いったい#Aで何が起こっているというのか.
型があいまいだと面倒なことが起こる.
そもそも,こんなコーディングすんなという説もあるがね.
プロフィール

みやどはつか

Author:みやどはつか
【座右の銘】
明日は明日の風が吹く/明日やろうはばかやろう


カウンター

最新コメント
月別アーカイブ
カテゴリ