21個のコレクションの獲得ロジックを実装。
まだ持ってないものの中から一定の確率で1つ選ばれるというシンプルなもの。
サーバーサイドは新しい実装のものからサービスとモデルをしっかり書いてやっていく。
実際に自分で書くことでperlでのオブジェクト指向プログラミングも腹に落ちてきました。
上手な実装をもっとみてみたいところ。
これでやっとモックアップで記録を続けてもかなり当初の構想通りの動きをするようになりました。
けっこう長かったなぁ。。と反省も多々ありますが、MockUpコンテストに出すことも決めたのであとは企画を練り練りしてブラッシュアップを続けていこうと思います。
ひっさしぶりにガッツり進んだ二日。
といろいろやりました。
1.ログイン画面遷移
ちょうどそろそろログイン周りつくらなきゃな、とおもいつつ実装先延ばしだったのですが、先日のTitanium2.0イベントにいき、Tiの新しいサンプルがあると聞いたので見てみると、ログインまわりの実装が！
すかさず参考につくりました。ソースはこちら。
2.ログインAPI,セッション管理
Facebookでログインすることを前提に、Ti.Facebook.loggedinであればログインAPIをたたいてアプリを起動します。その再にセッションが残っているかの確認もします。
セッション管理については不安が残りますが、人ます一度ログインしたユーザーはセッションが続くかぎりユーザーでーたをサーバーで保持しているようになりました。
3.コレクション獲得API
記録をつけたとき、その日初めてであればご褒美のスターをあげるといういわゆるアチーブメントの一種なのですが、もってないstarIdをランダムに選択するような仕様にして作成。
4.リファクタしてよりMVCモデルに。
ここが大きな変更点。いままでは、dispacherですべての必要な関数をApp::Func::Hoge::Functionというふうに読んでいて、ロジック実装とデータ周りがぐちゃぐちゃになっていたのと、可読性がひくかったこと、再利用性にかけていたことなどからきちんとMVC、今回だとServiceもいれてMVCSになるように変更を加えた。
use base qw(App::Hoge)といった具合にModel,Serviceそれぞれ親クラスを継承して、newをして使用。
こんばんわ。
最近異常に作業時間がとれずスケジュールがのびまくりのびまくりでやばいのですが、1つ大ハマリしていた問題が解決しました。
実機に転送した後、起動直後に落ちる問題で、可能性として
・OSのバージョンが間違っていた？
・includeからrequireスタイルに変えたのが原因？
・うちのwifiで発生していたリクエストが遅延する問題が影響してる？
とか思っていろいろ調べたのですが、どれも違いけっきょく
「ファイル名の大文字小文字がまちがっていた」
というなんともなさけない結果に終わりました。
たしかに最初のころからファイルの命名規則が曖昧で進めていたので。。
不幸中の唯一の幸いとして、titaniumで実機確認したときのデバッグ方法を学びました。
xcodeをつかって実機転送することで、xcode上で実機のログが見れます。自分の今回のケースもこのログを見てやっと発見できました。
方法は簡単で
・titanium Studioから実機転送を実行（正常に完了）
・build/iphone/プロジェクト名.xcodeproj というファイルをダブルクリック
・xcodeが開くのでbuild→runボタンを押して実機転送開始
・しばらくするとファイルの読み込みやTi.API.infoで吐いているログがでてくる。
という具合です。意外ととこの集団を紹介している場所がすくなく探すまでに苦戦しましたが（他にもっとよい方法ある？それとも周知の事実だった？）、ログにしっかり「読み込みたいファイルが見つからないよ！」と教えてくれたのでその後はすぐに解決しました。
requireスタイルにしても全然うごいて一安心。来週からはやっと新しい実装に移れそうです。
題名だけそれらしくしてみました。
プロジェクトの進捗の管理が非常になあなあでさすがに一人でやるにもこのままだと無駄が多いように感じてきたので一度たてなおし。
・仕様のfixを明示的に（一人でやっててもドキュメントにしたほうがいい）
・マイルストーンをきって、進捗を数字と表で管理
もっともやってよかった点は、画面をみてパッと見大丈夫、と思っていたところの抜け漏れが見えるようになったことと、あいまいだった進捗が見える化したことです。
ある程度現実的なスケジュールを切って、リリースへ向けて再スタート！
提題とおり、マルチコンテキストからシングルコンテキストでのコーディングへの移行作業中です。
というのも最近のtitanium系のカンファレンス？でそういう話題があったとのことで実際に本家のWikiにも
These multiple execution contexts cause problem because no scope has visibility of any other, meaning that sharing data between contexts is not possible without the ungainly use of application-level custom events (using Titanium.App addEventListener and fireEvent). They can also lead to circular references and likely memory leaks. There are lifecycle issues too, where it becomes unclear when the code for a given JavaScript file has been evaluated.
とあり、オススメしないとのこと。
マルチコンテキストでのコーディングはスコープがwindowごとで切れるのでけっこう好き勝手そのなかでやっても他に影がでないのがよかったのですが、たしかに値の渡し方は初めての人にはとっつきにくいし、なんかいろいろリスクもあるようですね。
最初titaniumでアプリをつくり始めてたときに Tweetaniumのサンプルがいまいち理解できずマルチコンテキストに逃げたたのですが再度チャレンジすることに。
またincludeスタイルでなくrequireスタイルをオススメするよ！includeは非推奨になるよ！みたいな流れもあるのでこちらも全てrequireで書き換えることに。これがけっこう大変。
まずincludeではそのファイルからの相対パスで外部ファイルを読み込んでいたので、場所ごとにパスが違ったのですが、今回はすべてapp.jsからの相対パス？なのでひと通りパスを書き換える必要がありました。
またAPIを叩いてViewを変更するときにviewはほぼグローバルな状態で展開されていたため簡単にアクセスできていたが、そのあたりの管理もしっかりする必要がでてきました。
自分はcoffeescriptでコードを書いているのですが、これをつかうとクラスっぽくかけて（実際はプロトタイプにメソッドを追加してNewしてる）継承もできたりとかなりいい感じに再開発が進みました。ひと通りスクラッチで勢いで書いたをかげでいろいろとムダも見えてきたのでこの機会にすっきり保守性も考えたコードに変身したいものです。
を行った。
UIについては、前回の試考錯誤のすえ、結局前のUIがよかったのではという結果になりまたまた変更した。かなり今はしっくり来ている。
Likeボタンの実装はいがいとスムーズに進み、一旦押してサーバー側のしょりもスルところまで完成。内容としては
・like_logテーブルにどのレポートにだれがlikeをしたか記録
・like_contテーブルにそのレポートにいくつlike がついたかを記録。
・like時に両方のテーブルを更新
・likeがゼロの場合/likeがあり、自分はlikeしてないとき/自分がlikeしているときの三つの場合においてインターフェースを変更。
これら判定のためにtimelineの情報に、isLike(自分がlikeしているか）、likeCount（何個likeされているか）を追加した。
ありきたりな機能だが、取り消しの処理、反映タイミングなどいろいろと極め細やかに対応するとやることが多い。
最初の変更。メインカラーをwineredにして、赤、グレーをベースのデザインに。
色合いはよかったが、なぜその色なのかちょっと弱かったのと、要素の優先順位づけ、レイアウトがいまいち。
試考錯誤の上でレイアウト変更。
そもそもTLの目的はユーザーに
・自分以外も学習をしているという存在感を感じてもらう
という大前提の上で、
・このアプリの最重要指標である「今週勉強した日が何日か」を目立たせる
・「他の人がんばってるなー」と感じさせる
・スターがもらえること＝目立つ、褒められることと印象付ける
・意味の弱いデザインはそぎ落とす
などを軸に再設計。よりミニマルなデザインも意識した。
具体的な変更点
・何日やったかを左のラベルの上にのせて強調。
・アイコンをより小さく（これは検討中）
・定型文を設定。最短だと名前と定型文が乗る。
・コメント枠を設置。より数字の情報とコメントを明確に分けるようにして単なる羅列を避けた。
・GETしたスターをより大きくして重要度を上げた。
・機能ボタンや情報を並べるfooterをつけた。
でもういっちょブラッシュアップしたのがこちら。
変更点とポイントとしては
・スターとリボンの色を統一
→より目立たせること、リンクしている情報であることを表現。
・like やコメントのアイコンがあるfooterのheightを44 -> 33に下げた。
→目立ちすぎだったため縮小。押しやすいようにボタンに幅をとるなど対策必要。
・リボンをfooterでなく、上の一番左に。
→左上からユーザーはものを認知していく傾向が強いので、最初に見える位置にして、独立させて優先度をあげたことも表現。
・アイコンを左に独立させずに真ん中にもってきて優先度を下げた。
→日数をより強調するため。
・rowの背景を設置。footerを目立ちすぎなくした。テイストも無機質なものからすこし質感のあるものに戻した。
→白とグレーのコントラストにあまり注意をもっていきたくなかったため。
となった。barColorを黒にして色合いに少し締りをもたせて一旦fix。でもfooterがちょっといらなかったかなという気もする。
というか、１っ個目のUIのように１つのボタンに集約（Facebookのように）して、押したらfooterが出てくるデザインがいいかなと。
あとはスターのクオリティとかあげてもっと「うれしい」「すごーい」って感じを出したいけど、ひとまず今日はこんな感じ。
ホーム画面でのweekly情報も表示できるようにした！それっぽくなってきました！
こんな感じのUIを考えて、さっそく実装してみました。
個別の毎日の学習レコードに加え、別のテーブルにトータルの統計デーブルを前回つくったが、そのデータを使って可視化した。
狙いとしては
・今まで見えることのなかった個人での学習を他者と比較できるようにすること
・それによりモチベーション、続ける楽しさや、記録するたのしさを生み出すこと
・がんばっている人が、同じようにやっている人を見つけられること
がある。なのでここはとても大事な要素。
ランキングよりも優先して作成した。追加の内容としては、自分の位置をアイコンで出したり、友達の記録をひっぱってきて、アイコンを並べるなどさまざまある。
UIの参考はPath。連続性を持たせることと、likeなどのアイコンを極力シンプルにしたかった。
アイコンの下に「7days」など何日目かを表示しようかと考えたが、バランスの悪さと、そこまで必要なのか（次の画面では表示している）ということでいったん外した。
あ、でもやっぱ数字のカウントくらい表示してもいい気がしてきた。笑
コメントを入れたときはこのようになる予定。
週ごとのデータのAPIも１つ追加。
userdataをクライアントでcacheするようにしたので、それと合わせて比較グラフをクライアントで実装する。
http://wppluginsj.sourceforge.jp/syntax-highlighter/ のsyntax hilighterをインストール。
こんな感じで表示してくれる。
#------------------------------------------------
# get total weekly data
#------------------------------------------------
sub get {
my ( $c, $week_id) = @_;
my $users = $c->dbh->selectrow_hashref(
"select
week_id
start_date,
num_all,
count_1,
count_2,
count_3,
count_4,
count_5,
count_6,
count_7
from
weekly_total_data
where
week_id = ?",
{ Slice => {} },
($week_id)
);
return ($users) ? $users : 0;
}
進んだこと
ゲーミフィケーション要素の大事な1つとして、ポイント設計があります。
ひとまずベーシックなものを、よりユーザーにアクションしてもらいたい順に相対的な点数差をみてつくりました。ここはもうすこし全体ができてから調整が入りそうです。
ポイントロジックとしては、
などをチェックするために以下のような実装をしてみました。
#
# today yesterday || 5days before
# ---------------|---------------|----------||----------|---------------
# ↑ ↑ ↑ || ↑
# now midnight (midnight - 1day) (midnight - 5days)
#------------------------------------------------
#isRestartBonus
#------------------------------------------------
sub isReruntBonus {
my ( $now, $lastUpdateDate ) = @_;
my $midnightTime = pm::Common::getMidnightByUnixTime($now);
if ( $lastUpdateDate < $midnightTime - $ONE_DAY * $RESTART_DAY ) {
return 1;
}
else {
return 0;
}
}
#------------------------------------------------
#isSerialCheckIn
#------------------------------------------------
sub isSerialCheckIn {
my ( $now, $lastUpdateDate ) = @_;
my $midnightTime = pm::Common::getMidnightByUnixTime($now);
if ( $midnightTime > $lastUpdateDate
&& $lastUpdateDate > $midnightTime - $ONE_DAY )
{
return 1;
}
else {
return 0;
}
}
#-------------------------------------------------
#isTodaysCheckIn
#------------------------------------------------
sub isTodaysFirstCheckIn {
my ( $now, $lastUpdateDate ) = @_;
my $midnightTime = pm::Common::getMidnightByUnixTime($now);
if ( $midnightTime > $lastUpdateDate ) {
return 1;
}
else {
return 0;
}
}
(WPのcodeタグってハイライトしてくれないのか・・・）
なんかもっとすっきりできそうな気もするのですが、ひとまずこれで。