2013年1月31日木曜日

【Java】コメント

前回はJavaの命名規則について書きましたが、今回はコメントについて。
Javaには主に3種類のコメントがあります。
それぞれ次のような役割です。

ドキュメンテーションコメント
(Javadocコメント)
/** ~ */ で囲み、クラス,インタフェース,コンストラクタ,メソッド,フィールドについて記述するコメント。
Javadocにより処理された外部ドキュメントを生成可能。
ブロックコメント /* ~ */ で囲み、ファイル,メソッド,データ構造,およびアルゴリズムについて記述するコメント。
Javadocコメントと誤認しやすいため、余り使用をお勧めしない。
単一行コメント コードの概要などを記述するコメント。
// で始まる1行をコメントアウトする。

それぞれのコメントの例も書いてみます。
まずはJavadocコメント。
/**
 * 設定されている画面消灯までの時間をミリ秒で返却する。
 * 取得できない場合は30000ミリ秒を返却する。
 *
 * @return 画面消灯までの時間
 */
public String getOffScreenSetting() {
 return Settings.System.getString(mContext.getContentResolver(), Settings.System.SCREEN_OFF_TIMEOUT);
}

/** 30000ミリ秒(デフォルトの時間として使用) */
private static final String DEFAULT_MS = "30000";

主にメソッドや定数名に使用します。
Javadocコメントの大きな特徴として、Javadocを生成できます。
上記のコメントだと次のように表示されます。
また、外部出力も可能ですのでプロジェクトでの管理等にも利用できます。
(詳細は本家Javadocを参照して下さいね)

ブロックコメントはsirocoは余り推奨しないので割愛。

単一行コメントは実際の開発で一番良く使う事になると思います。
次のような感じで使います。
if (android.os.Build.VERSION.SDK_INT == 17) {
 // Android4.2(API level17)の場合は"-1"が非表示の値でない??
    // "-1"の代わりにintの最大値を設定
 NOT_OFF_SCREEN = Integer.MAX_VALUE;
 NOT_OFF_SCREEN_STR = String.valueOf(Integer.MAX_VALUE);
} else {
 NOT_OFF_SCREEN = -1;
 NOT_OFF_SCREEN_STR = "-1";
}

上記の例は余り良い例ではないですが、コードを見ただけでは分かりづらい所に補足としてコメントを入れるのが良いでしょう。

本来であればコードだけで処理の内容が誰でも理解できるのが理想です。
ですが、実際はそうはいきません。
わかりづらいところには適当にコメントをいれて可読性を高めましょう。

コメントについては以上です。

2013年1月10日木曜日

【Java】命名規則

久々に技術的なことも書いてみます。
今回はJavaの命名規則について。

Androidアプリのように個人で開発をする場合では意識しなくても良いこともありますが(本当はよくないが)、規模が大きなWebアプリの開発などでは複数人のプログラマが1つの資産に対して手をつけることが多々あります。

皆が思いおもいにコーディングしていたら、可読性が低く、わかりずらいソース群が出来上がります。
そんなことがないようコーディング規約を設けて、一定のルールでコーディングが行われるよう制御したりします。
(実際の業務でお目にかかったことはないですが。。。)

さらに細かく言うと、クラス名・変数名・メソッド名を決定する際には、命名規則に沿った名前を付けることで、ソースの可読性を高め、より理解しやすいものとなります。


前置きが長くなりましたが、ルール通りに命名することで、自分にも他人にもやさしい、美しいソースが出来上がるって事です!

それでは行ってみましょう!

一般的なこと
フルスペルの英語記述を使用する(省略表記を避ける)
// 「高さ」だとすぐにわかる
int height; 

// わかりづらい
int hgt; int ht; int h; 

// ある意味わかりやすい。。。が論外
int 高さ; 
複数の単語で構成する場合は、2語目以降は先頭を大文字にする
String firstName;
長い名前を避ける(15文字以内)
// 長すぎる
String baseballOrSoccerOrRugbyOrTennis; 

// スッキリ
String ballSport; 
クラス
単語の先頭を大文字にする
class Hoge { ...
class HogeSample { ...
パッケージ
すべての単語を小文字にする
jp.gr.java_conf.siroco
変数
先頭の文字を小文字とし、2単語目以降の先頭を大文字にする
String name;
Stirng firstName;
メソッド
可能な限り先頭を能動態の動詞で始め、先頭の文字を小文字にする
private void addAccount() {};
private String changePassword() {};
定数
すべて大文字で表記し、単語間をアンダースコア"_"でつなぐ
static final String DEFAULT_PASSWORD = "hogehoge"

こんなところでしょうか。
その他にも細々したものもありますので、色々調べてみると面白いと思います。

2013年1月7日月曜日

【Android】Serviceの自動起動が上手くいかない件

「こんなときに画面消灯しないでよ」に対して、
自動起動をONにしているのにもかかわらず、
端末再起動時に自動起動しない、というお問い合わせを
数件頂いていました。

sirocoの端末でも確認しましたが、
OS4.2のNexus7では再現できず、
OS4.1のGalaxyNexusでは同様の現象が発生しました。

パーミッションを付与しないと、
ブロードキャストレシーバがACTION_BOOT_COMPLETEDを
受け取れない端末が存在するようで、
Manifestに


<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>

を追加することで解消しました。

Serviceの自動起動の実相を考えている方は参考にしてみて下さい。



【こんなときに画面消灯しないでよ】ver1.4.0 リリース



こんなときに画面消灯しないでよ
⇒マーケットはこちら



対応内容
一部端末で端末再起動時に自動起動しない不具合を改修しました。


メール、コメント等でご連絡頂いた皆さん、ありがとうございました。
対応が遅くなりすみません。
今後ともよろしくお願いします。

2013年1月3日木曜日

sirocoUI(仮)


sirocoUI(笑)というコメントを頂いたので、
少し詳細を書きたいと思います。

まず名称の「sirocoUI」というのは本当に仮です。
やりたいことの意味からすると「~(なんちゃら)HelperUI」って感じになる気がします。

さて本題。
皆さんはアプリをインストールして初めて使う際、
使い方がわからないって事ありますか?(突然ですが)

sirocoは良くあります。
さらに使い方の説明がなかったりすると
そのままアンインストールなんてことも。。。(汗)

アプリを作る側としては、アプリを長く使ってもらうために、
提供するアプリケーションに対する説明が必要だと考えています。
つまりヘルプ(画面・トースト・etc...)ってことですね。

更に言うと、ユーザが必要な時に、その場で、ヘルプが確認できるという事が重要です。
ヘルプページに遷移して、確認、戻って試す、
では余り親切ではありません。(あるだけましですが)

現在のsirocoのアプリはアプリの説明ページ(つまりこのblog)に遷移させています。
上記に書いた通り、この方法は余り親切ではありません。

これを解消するために、標準のUIにHelp機能をを付与させる形のUIを
作りたいと思っています。
フレームワークといった大掛りなものでなく、簡単なライブラリな感じで。

「あ~使い方わかんねぇな」⇒
右フリック(仮)⇒
「おぉ、そういうことねw」

みたいな感じ。
良いでしょう?

長くなりましたが、
今年はよりユーザにやさしいUIを実装したアプリを作りたいな~と、
ぼんやり考えています。