Android Studio Beta v0.8の注意事項
出遅れた感がありますが、注意一秒ケガ一生の標語よろしく既存のAndroid Studioユーザ向けの注意事項をまとめてみました。v0.8からの新規ユーザは、まっさらな気持ちで臨めるので特に気にすること無いです。
#宗教上の理由で、Eclipse ADTユーザはよくわかりません。(´・ω・`)
地雷その1 アップデート版はありません
おそらく地雷その3の絡みから新規ダウンロードのみです。でもv0.8を起動すると速攻で「v0.8.1にしてね」って言われるので、素直にアップデートしておきましょう。
ご存じのとおり、Android StudioはAndroid SDKを内蔵しているので、不用意に既存のアプリを上書きすると、もれなくAndroid SDKも上書きされます。こんな風にバージョン分けてるなら平気ですが、特にインストールが簡単なMac版は注意してね。
地雷その2 付属しているAndroid SDKがミニマム構成になってる
簡単にいうとこれしか入ってない。足りないのは、あとで追加しときましょう。
でもって、既存のAndroid SDKを流用したい場合は、Android SDK ToolsとかBuild-toolsを最新にしときましょう。
地雷その3 設定フォルダ名が変わりました
gihyo.jpの連載んときにAS_HOME
とか言ってたヤツが $HOME/.AndroidStudioPreview
から$HOME/.AndroidStudioBeta
に変わりました。
→ 第2回 Android Studioの導入と設定:Android Studio最速入門~効率的にコーディングするための使い方|gihyo.jp … 技術評論社
「設定が飛んだ!!」とビックリした人もいると思いますが大丈夫、v0.6.xまでの設定は $HOME/.AndroidStudioPreview
に残ってます。たぶん、この次は $HOME/.AndroidStudio
になるんだと思うのだけど、問題は何時になるんでしょうかね?(順当にいって次回のGoogle I/Oかな。(・ω<)☆
地雷その4 プロジェクトウィザードが作るbuild.gradleが変わりました
ざっと上げると、こんな感じ。
- Gradle Wrapperのバージョンが 1.12 になった
- Androidプラグインのバージョンが 0.12.+ になった(最新は 0.12.0 だったかな
- Androidプラグインの名称が
'com.android.application'
になった buildscript{}
やサブプロジェクトのリポジトリがjcenter()
になった
既存のAndroid Studioで作ったプロジェクトを開けなくなったのは、Android SDK(地雷その2)のせいだから。
だいたいこんな感じ。AS_HOME
とAndroid SDKに注意してれば、既存のプロジェクトを活かすこともできると思います。あと、このヘンがまた役に立つかも(#ステマ
→ 第4回 Android Studio v0.1.2登場:Android Studio最速入門~効率的にコーディングするための使い方|gihyo.jp … 技術評論社
JSF2.2試してみた - メッセージまわり
バリデータと、ユーザプログラムで設定するメッセージについて。JSFが用意しているバリデータのメッセージが変更可能なのは知ってて、とりあえずどんな感じになるのか掴んでおきたかった。
ちなみに、バリデータの有無にかかわらず、Faceletがバインドしているオブジェクト(例えば Calc.setRight(long)
)の型に合わせた、型チェックは勝手にやってくれてた。デフォルトのメッセージはアレな感じだけど、ちょっとだけ感心した。
それはそれとして、バリデータではなく、管理ビーンの処理(アクション)で、いわゆるギョーム的なメッセージを付与して画面に返したいなんてのは良くある話で、かつエラーになった項目の背景色を赤にして目立たせたいなんてのもよくある話だよねと。
その辺は、こちらを参考に実装してみた。
→ JSFでエラーのある項目の背景色を変える - じゃばらの手記
その結果が、管理ビーンからフラッシュメッセージを使う事と、Faceletから component.clientid
でエラー(バリデータが invalid)かどうかを判定するアレなコード。
<table> <tr> <td> <h:inputText id="left" label="左辺" value="#{calcView.calc.left}" style="#{faceUtils.valid(component.clientId)}" required="true"> <f:validateLongRange maximum="99999"/> </h:inputText> </td> <td>+</td> <td> <h:inputText id="right" label="右辺" value="#{calcView.calc.right}" style="#{faceUtils.valid(component.clientId)}" required="true"> <f:validateLongRange maximum="99999"/> </h:inputText> </td> </tr> <tr> <td><h:message for="left"/>#{flash.left}</td> <td> </td> <td><h:message for="right"/>#{flash.right}</td> </tr> </table>
clientIdが自動発行されるので、messageタグとフラッシュメッセージを別々に用意したり、HTML要素のID知ってるのに、わざわざ component.clientid
とかやって面倒だなと思ってたら、単なる思い込みだったと、キクタローさんのサンプルで知った(実にありがたいw
#prependId属性ってのを false にするといいらしい。
実装のイケてなさはさておき、とりあえず、
- アクションの処理中に、特定の項目に紐づけたメッセージを出力できる
- エラーになった入力項目を目立たせる事ができる
あと知っておきたいのは、
- アクションの結果に応じて、特定の入力項目の属性(入力不可、非表示)を切り替えられるかどうか
- (できたら、動的に入力項目を増減・入れ替えできるかどうかも)
なんだけど、その前にちょっと寄り道した(つづく)。
JSF2.2試してみた - みんなの反応
説明が終わる前に、いろいろ反応があったので、ネットに埋もれる前に回収しとく。みなさま、ありがとうございました。こうして有識者からのコメントが釣れるのを期待してました。:-)
まずはキクタローさん。
平日の夜中なのにありがとうございました。スーパー力作!!
明け方に [twitter:@btnrouge]さんからも。
ELはやっぱりgetter/setterが要るんだと。JPAはいずれ試す。
王子([twitter:@yoshioterada])から、ありがたいコメントを頂く。
寺田さんからは、まだ説明してない部分も先回りしてコメントもらったので、その辺はあとでフォローします。
コメントもらっといて、こんな事いう不届き者がw
キクタローさん経由で [twitter:@megascus]さんも捕捉したった。
今回知った事はそのうちサンプルにフィードバックするとして、まずは今のサンプルの解説を続けよう。
#けど、力尽きたので今日はおしまい。:-)
Java7から中黒(U+30FB '・' KATAKANA MIDDLE DOT)が識別子に使えない
「何を今さら」 と言うなかれ、ようやく仕事でJava7使えるようになったので、今ごろ気づいた。ちょうど日本語テストメソッド名で中黒(・)使ってたんで。:-)
Java6でビルドすれば平気なんだけど、NetBeans8やIntelliJ IDEA13はプロジェクトのターゲットJavaバージョンがJava6でも、エディタ上では中黒(・)を不正な識別子と見なす(ちなみに、エディタ上エラーになってるだけで、コンパイラはJava6なのでビルドは通るよ)。
Eclipse(4.3)はターゲットがJava6ならエディタ上でもエラーにしない(偉いw
それ(Java7から中黒がダメ)がホントかどうか知りたくて、言語仕様を探ってみたけど、それっぽいところを見つけられなかった。(´・ω・`)
頑張ってググってみたけど、唯一見つけられたのは、java.netのatomのfeed。その元になったjava.netの掲示板はもう無いみたい。(´・ω・`)
ps.
AppCodeもアカンらしい。これは手抜きっていうかAppCodeのバグなんでないか?
んでもって、JavaじゃなくてUnicodeのせいなんだそうな。
JSF2.2試してみた - 基本編のつづき
管理ビーンのデータの持ち方については、何とでもできるんだけど、個人的にはこうするのはイヤだった。
public class CalcView { private long left; private long right; private long answer; : // あとはそれらの getter/setter が続く }
イヤな理由は管理ビーンがgetter/setterだらけになること。これに尽きる。
そうは言っても、管理ビーンが画面単位で用意するなら、そこに登場するgetter/setterも、その画面(xhtml)に必要な分だけなので、もしかしたら許容範囲なのかもしれない。まかり間違って、複数の画面を束ねる管理ビーンだったりしたら、その画面分のgetter/setterがわんさと集まって、目も当てられない。
そんなわけで、データはデータであることがわかるように独立したオブジェクトにしといた。おっさん風に言えばDTO(Data Transfer Object)とかVO(Value Object)の類い。
ついで言えば、それらも
public class CalcView { private Calc calc; private List<Calc> results; }
...とかしないで、CDIからインジェクションしてもらえば良いのかな?なんても思ったんだけど、
public class CalcView { @Inject // <- これはイケる private Calc calc; @Inject // <- こっちがあやしい private List<Calc> results; }
ListみたいなコンテナオブジェクトをCDIでインジェクションする方法がイマイチわからんかった。今思えば、Producerを用意すればいいのかな?とも思うのだけれど、なんか大げさだし、気軽にCDI管理ビーンを増やしたら、CDIの名前が枯れそうなので、控えてた。
よく考えたら、インジェクションするだけなら、CalcがCDI管理ビーンである必要もないのか...とも。
CDIインジェクションで貫くとしたら、
@Named @RequestScoped public class CalcView { @Inject private Calc calc; // <- これは @RequestScoped @Inject private List<Calc> results; // <- こっちは @ViewScoped }
...ってやりたかったんだけど、@RequestScopedの管理ビーンに@ViewScopedの管理ビーンを貼り付けられなかった(...ような覚えがある。この辺、うろ覚え。
何にしてもCDI管理ビーンがgetter/setterだらけになるのは、たとえlombokがあったとしても好きじゃ無い。これは単なる好みの話。
IntelliJ IDEA13でJavaEEプロジェクトを作る
「New Projectウィザード」で「Java Enterprise」を選んで、いろんなテクノロジを選択するんだけど「Application Server」にGlassfish4を選んでいると「Use library from 'GlassFish 4.0.0' installation」って項目が追加されて、大抵のライブラリをGlassfishから参照するようになる。
これはこれで便利なんだけど、なんでか一部のテクノロジ(たとえばJPA)はGlassfish内にある javax.persistence.jar
を参照せずにわざわざダウンロードしてくる。それに小刻みに参照ライブラリを区切るので、あぶれるものが出てきたり(javax.interceptor
パッケージが見当たらない、とか)と、手放しで喜ぶほどデキがよくない。(´・ω・`)
なにより、ローカルにあるGlassfish上のライブラリを参照するので、プロジェクトを共有するのに向かない。
だったら、New Projectでヘンに凝ったことせず、せいぜい「Web Application」か「JSF」それも「Set up library later」にして、プロジェクト作っておいて、
あとから「Project Structure」でMavenライブラリ(From Maven...)から「javax:javaee-api:7.0
」をダウンロードしたほうが数倍マシ。Scopeは「Provided」でね(Web Profileだと「javax:javaee-web-api:7.0
」と指定する)。
。
デプロイ先がGlassfish4だと、ほとんど揃っているので「javaee-api-7.0.jar
」はProvidedで済むんだけど、他のAPサーバだと必要に応じてJSFの実装とかWARファイルにバンドルしないとダメなんじゃないかな?
というか、このjavaee-api-7.0.jar
(または javaee-web-api-7.0.jar
)、NetBeansには入っているのにGlassfishやJavaEE 7 SDKに入ってないってのは、どうゆう了見だ!と思わなくもない。
#単に自分の探し方が下手なだけ?
ps.
このヘンはNetBeansのほうがマイルドなんだろか...。
JSF2.2試してみた - 基本編
わけあって JavaEE7(JSF2.2)を使う機会に恵まれたので、あれこれ触って思ったことを残しておく。よくよく考えたら、ここ数年、いわゆるモダンなWebフレームワークをちゃんと使ったことが無いので、ここで述べる不満がJSFに限った話ではないのかも知れない。
前置きはこれくらいにして、まずは基本として、JSFでどうやって画面を作るのか試してみた。ちなみに、きちんと整備する余力がなかったので、IntelliJのプロジェクトのままです。いずれは、GradleでJavaEEのプロジェクト作るの、どうするのかも興味あるので、Gradle化するかも。
作った画面は1つで、左辺と右辺に数字を入れて足し算した結果を書き出すというスーパー簡単なやつ。せっかくなので計算結果はずっと残す。で、いきなり躓いたのが用語。Facelet(xhtml)から呼び出す、オブジェクトはなんて呼べば良いんですかね?
ちなみに、JSF管理ではなくCDI管理にしてる。自分で試してる分には困らないんだけど、人に説明するとき用語がはっきりしないと困る。ここでは管理ビーンって言うことにする。(´・ω・`)
それはさておき、作ったプロジェクト全体はこいつ。
今回は、そのうち基本の基本だと思う、JSFのサンプルでよく見る普通っぽい(?)管理ビーン。
JSFのイヤなところって、これくらいの簡単なやつでも実装のバリエーションがたくさんあって、どれが正解(鉄板)なのかすらありそで無いってところ。
今回はこう(↑)したけど、これだって、こんくらいのツッコミどころがある。
- 左辺、右辺、答えをCalcに抜き出さず、CalcViewにインライン展開してても良いじゃない。
- CalcViewがgetter/setterだらけになるのがイヤ(Lombokは無しで)。
- CalcをなんでCDI管理にしてないの?
この時点で気に入らないのは、何においても名前・名前・名前。CalcViewがいわゆる「コントローラ」に当たるのだと思うのだけれど、ホントにそうなのか? faceletsに値を貼り付ける属性(getter/setter)と、commandButtonタグのaction属性に指定するメソッドは、それぞれなんて名前で呼べは良いの?と悩みは尽きないw
あと、個人的な好みでこうしたけど、それだって正解かどうかなんてわかんない。
- CalcViewがgetter/setterの塊になるのがイヤだったので、データはデータでCalcオブジェクトに抜き出した。これだって、なんて名前で呼べばいいんだ?ちょっと古いけどDTOとか言えばいい?
- CalcだってCDI管理にしても良かったけど、無駄にCDIの名前空間を消費する気になれなかったので、CalcViewのメンバ変数で済ました。
- CalcViewのアクションメソッドであることが分かるように、メソッドの接頭子に「do」って付けた。なんかオッサン臭いけど、オッサンだからいいや。:-P
- 計算結果を累積して持っておきたかったのでCalcViewのスコープをViewScopedにした。ホント言えば、List
だけがViewScopedであれば十分なのだけれど、どうしたらそうできるのかわからんかった。
たぶん、JSFに正解なんて無くて「お前がそう思ったら正解なんだろ。お前の中ではな」って事なんだろな。
あとバリデータの事を書いておきたいけど、力尽きたのでまた今度。