R-Labs

こんにちは。モバイル事業部の佐野です。
今回はJSファイルの分割とコンテキストについて説明したいと思います。
TitaniumStudio等で新規にプロジェクトを作成すると、すべてapp.jsにコードが書かれていると思います。

ここからアプリを作っていく場合に全てをapp.jsに書くのはコードが読みづらいし、
機能別とか画面単位に分けたいと感じると思います。

解決策としては以下の方法があります。
①createWindowのurlプロパティに処理ファイルを指定する方法
②ファイルをincludeする方法

この2つの方法において以下のような違いがあります。
①ソース間の変数参照が出来ない(別コンテキストのため、変数スコープが別になっている)
②ソース間の変数参照出来る(同一コンテキストのため、変数スコープが同一になっている)

各機能間等で変数参照を行うことが多いので②の方法が推奨されています。
今回は②ファイルをincludeする方法についてソースを見ながら簡単に説明したいと思います。

今回使用するのはTitanium.includeメソッドになります。
Titanium.includeメソッド【API Reference】
http://developer.appcelerator.com/apidoc/mobile/latest/Titanium.include-method.html

パラメタに読み込みたいJSファイルを指定するだけです。
これを以下のソースからincludeメソッドを修正します。

【app.js】

//win1を生成し、ラベルを設定する部分を別ソースにしたい
var win1 = Titanium.UI.createWindow({
    title:'Win 1',
    backgroundColor:'#fff'
});
var label1 = Titanium.UI.createLabel({
    color:'#999',
    text:'I am Window',
    font:{fontSize:20,fontFamily:'Helvetica Neue'},
    textAlign:'center',
    width:'auto'
});
win1.add(label1);
win1.open();

上記のソースでUI部分を②の方法でファイル分割すると下記の通りになります。

【app.js】

//名前空間を定義
var test = {};
//別ソースを読み込む
Titanium.include('ui.js')
//別ソースで定義したWindowオブジェクト生成メソッドを呼び出す
var win1 = test.ui.createWindow();
win1.open();

【ui.js】

(function(){
    //UI用の名前空間を定義
    test.ui = {};
    //Windowオブジェクト生成メソッドを定義
    test.ui.createWindow = function(){
        //Windowsオブジェクトの生成
        var win = Titanium.UI.createWindow({
            title:'Win 1',
            backgroundColor:'#fff'
        });
        //Labelオブジェクトの生成
        var label = Titanium.UI.createLabel({
            color:'#999',
            text:'I am Window',
            font:{fontSize:20,fontFamily:'Helvetica Neue'},
            textAlign:'center',
            width:'auto'
        });
        //labelをwinに設定
        win.add(label);
        return win;
    };
})();

Titanium.includeでは指定したJSファイルをそのまま置換するのと同じです。
上記のように分割することが出来るので、UIだけでなく、ネットワーク処理、DB処理も同様に分割することで
読みやすく、メンテしやすいソースになると思います。

こんにちは。モバイル事業部の佐野です。


現在弊社ではマルチOS開発プラットフォーム、「Titanium Mobile」に関連する事業を展開しています。
http://www.r-learning.co.jp/titaniummobile/


今回はAndroid開発者視点で見たTitanium Mobile(以下Ti)について簡単に説明したいと思います。

・開発環境について

基本はAppcelerator社から提供されているEclipseベースのIDEであるTitaniumStudioを利用します。
Eclipseベースということもあり、Android開発をやってきている方にとっては扱いやすいと思います。
iPhone、iPad向けのアプリ開発をする場合はMacが必須となります。
https://my.appcelerator.com/auth/signup/offer/community


【画面イメージ】

・マルチOS対応のプラットフォームについて

iPhone、およびiPadについては基本的なUIやデバイス機能はもとよりアニメーション等にも対応されています。
AndroidについてはネイティブUI、デバイス機能についてはある程度対応していますが、
アニメーション等は一部対応しておらず、カメラ機能では、一部機種で例外が発生しアプリが
終了してしまう事があるので注意が必要です。
また、TiはネイティブのAPIを実行できるモジュールを作成して機能を拡張することができるので、
Android向けにリッチなアプリを作るのであればこの方法を利用して開発することが多くなります。

・コーティングについて

基本はWebエンジニアにおなじみのHTML+JavaScript(+CSS)でコーディングしていきます。
自分はTiの開発で初めてJavaScriptを使うことになり四苦八苦していますが、Web技術の基礎があればコーディングについては難しくないと思います。

・UIオブジェクトとイベントについて

基本は各Viewを生成し、そのViewに対してボタンや画像コントローラを配置し、
それらに対してクリック等のイベント処理を追加していく感じです。
このあたりは違和感は無いと思います。

・多機種対応について

iPhone、およびiPadについては問題ありませんが、Androidの多解像度の対応は
各機種ごとにUIのレイアウト調整が必要な場合があり、処理が煩雑になってしまうので、
対応範囲を予め明確にしておかないと後が大変になります。


次回以降は実際に開発をしていく際のTipsを簡単に紹介していきたいと思います。

こんばんは。システム部の佐々木です。

前回から少し日が空いてしまいましたが、本日はTaskQueueについて書きます。

読んで字の如く、Task(タスク)Queue(キュー)なのでできることはタスクのキューイングです。
簡単に説明すると非同期処理なのですが、前回説明したCronとは別の非同期処理になります。

Cron…実行タイミングがスケジューリングされている。
TaskQueue…キューイングはプログラムで行い、実行タイミングはGoogle App Engineが判断します。

Google App EngineではHttp(s)は30秒でタイムアウトする仕様になっています。
リクエスト時に大量データ登録などが発生してサーバの処理時間が30秒を超えた場合、
Google App Engineはエラーを返します。
極力重いアクセスを避けるのがよいのですが、そういう訳にはいかない場合もあるでしょう。

という訳なので重い処理を行う場合はTaskQueueを使用します。

使い方は至って簡単。

１．サーブレットを作る

前回のcronの時のようにサーブレットを一つ作ります。
ここではAsyncTaskControllerということにしましょう。(slim-genで自動生成)
Slim3の規約に従って<Slim3RootPackage>.queue.AsyncTaskControllerには”/queue/asyncTask”というURLでアクセスすることができます。
通例ですがcronと同様に”/queue/*”には管理者以外アクセスできないようにしましょう。

２．TaskQueueを呼びだす

最もシンプルなTaskQueueの呼び出しは次のようになります。

Queue queue = QueueFactory.getDefaultQueue();
queue.add(TaskOptions.Builder.withUrl("/queue/asyncTask"));

こうすることによってGoogle App Engineが/queue/asyncTaskに非同期でリクエストを送信してくれます。

上記は最も簡単な例ですが、GETまたはPOSTでTaskQueueにパラメータを渡すこともできます。

// GET
queue.add(TaskOptions.Builder.withUrl("/queue/asynkTask?p1=aaa&p2=bbb").method(Method.GET));
// POST
queue.add(TaskOptions.Builder.withUrl("/queue/asynkTask").param("p1", "aaa").param("p2", "bbb").method(Method.POST));
 
// オブジェクトも渡せる(未検証)
// Serializeインターフェースを実装してるオブジェクトかつPOSTである必要がある
List strList = Arrays.asList("1","2","3");
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(strList);
// サーブレット側ではバイト配列からオブジェクトをデシリアライズする
queue.add(TaskOptions.Builder.withUrl("/queue/asynkTask").param("p1", baos.toByteArray()).method(Method.POST));

・デフォルトキュー
デフォルトキューはWEB-INF/queue.xmlの存在を必要としません。
queue.xmlが存在しない場合のデフォルトキューは毎秒5件でキューに積まれた処理を実行します。
もしデフォルトキューの設定を変更する場合はqueue.xmlを作成してname要素を”default”にします。

・設定値の詳細
queue.xmlで設定できる内容です。
name…キューの名称。QueueFactoryからキューを取得するときのキー名を設定します。
rate…10/sの場合だと1秒間に10回タスクが実行されます。
bucket-size…タスクを溜めておける量です。bucket-sizeを超過したタスクは、bucketに空きが出るまで待ち状態になります。
retry-parameter…タスクが失敗した際のリトライ回数を設定できます。

下記のサイトにてとても親切に和訳されていました。
http://elekmole.blogspot.com/2011/02/java-task-queue-configuration.html

・Google App Engine SDK1.5から追加された機能

プルキュー…今まではGoogleAppEngineがキューの制御(タスクのレート制御)を行っていましたが、
プログラムで任意にキューの実行を制御できるようになりました。
http://code.google.com/intl/en/appengine/docs/java/taskqueue/overview-pull.html
REST-API…TaskQueueにRESTでアクセスできるようになりました。
http://code.google.com/intl/en/appengine/docs/java/taskqueue/rest.html#method_taskqueue_tasks_list
その他…Cronも含めたバックグランド処理は上限時間が24hになったそうです。

こんにちは。モバイル事業部の門別です。
androidタブレット比較の第２回目です。
今回はHDMI、ストレージの転送速度等の比較を行っていきたいと思います。

・HDMI接続
OptimusPad、XOOM共にHDMI接続に対応していますがケーブルの規格が違います。
OptimusPadはtypeC、XOOMはtypeDとなっています。
左がtypeC、右がtypeD

HDMI接続用に24インチのモニタを使用しています、720pなので1280*720の解像度で表示しています。
XOOMでHDMI接続
OptimusPadでHDMI接続
若干横表示が切れています、調整次第で直るとは思いますが設定は初期設定としています。

ちなみに横に傾けても双方とも表示は変わりません。
OptimusPadを横にしてみました
ケーブルが若干ジャマですがプレゼン等にも使えそうです。

・サウンド
OptimusPadはスピーカが横に有るため聞こえやすいです、XOOMはスピーカが後ろに有るため、膝などに置きながらだと音が小さくなってしまいます。
HDMI接続で双方ともモニタ側からちゃんと音も出ます。
会社の中のテストなので大音量でのテストは残念ながらできません。

・ストレージの転送速度
Overall perfomance Markというアプリで計測してみました
OptimusPadがリード 25.18MB/s　ライト 6.105MB/s、XOOMがリード 27.089MB/s　ライト 5.438MB/s
リード、ライト共に若干の差が出ていますが誤差の範囲です。
内部ではUSB2.0接続のはずなので妥当な数字なのかなと思います。

・カメラ機能(シャッターボタンの反応速度等)
OptimusPadの特徴に3Dカメラが有ります、写真で説明するのはちょっとつらいので割愛します。
カメラ機能としては差は感じられません、シャッター音はXOOMの方が小さく聞こえます。

・通信
OptimusPadはドコモ端末として購入するので単体での3G通信が可能です。
XOOMはauの店舗やオンラインショップで端末のみの購入が可能ですが通信機器は別途用意する必要があります。

２回に渡って比較をしてきましたが性能差は感じられなかったので画面の大きさと通信機能が付いているかの差になると思います。
モバイル用途としては単体で通信できるOptimusPad、WIFIの環境が整っていて家の中での利用が多い場合はXOOMがおすすめです。

こんにちは。モバイル事業部の門別です。
本日はandroid3.0搭載のタブレットであるドコモのOptimusPadとauのXOOMの２機種を
実際に使用してみて使用感等を２回に渡って比較していきたいと思います(写真はiPhone4で撮影)。

・外観
外観ですが、まず大きさが違いますOptimusPadは8.9インチに対してXOOMは10.1インチとXOOMの方が一回り大きくなっています。
一番上からOptimusPad、XOOM、MacBook Pro15インチ

・重さ
OptimusPadが620g、XOOMが730gと110gXOOMの方が重いです、
110gの重量差は、手に持って操作する時間が長いと実感できます。
私は手持ちで寝転がって映画を見たりしますが、そんな時は特に感じます。
手に持ったときの質感はOptimusPadはプラスチックマットな感じで手にフィットし、XOOMの方はアルミで少しつるつるします、歩きながらだとちょっと落としそうです。
重心については両方ともバランスが良く、上下左右どのように持っても違和感はありません。

・画面
OptimusPad、XOOMともにグレア加工の画面で映り込みは激しいです(モバイル端末はほとんどそうだとは思いますが)、気になる方は保護シートをつけた方が良いと思います。
左がXOOM、右がOptimusPad

・起動時間
最後に電源ONからロック画面までの速さを計測してみました、OptimusPadが30秒、XOOMが42秒となっています。
XOOMが結構時間かかってますね、アプリを結構入れていたのでその差かな？
ちなみに電源ボタンはOptimusPadが横側、XOOMが後ろに付いています。
XOOMの後ろ側丸い凹みが電源ボタン
OptimusPad横側の細長いボタンが電源ボタン

今回の比較では大きさ、重さと起動時間に差が出ましたが気になるのはやはり重さでしょうか。
画面が大きく見やすいXOOM、小さくて軽いOptimusPadと好みが分かれると思います。

後半はHDMI出力の使用感覚、音の聞こえ方等を書いていきます。

こんにちは！システム部の徳田です。

前回はDRYなコードを書くために、sendメソッドの紹介を・・・といったのですが、ちょっとその前にもっと基本的なメソッドの紹介をさせていただきます。

inject

これは、rubyの基本的なメソッドです。

１～５の合計を求めるコードを書くとしたら、

eachを用いることにより下記のように書けます。

result = 0
(1..5).each {|v| result += v }
p result

これでも十分DRYだと思っていたのですが、injectメソッドを用いることによりさらにDRYに書けます。

p (1..5).inject(0) {|result, item| result + item }

３行が１行になりましたね。すごく便利なメソッドです。

ちなみに、～.inject(0)の0は、result = 0と同じことを示しています。

0で初期化をするという意味です。

また上記のinjectメソッドはRubyのメソッドですが、Railsのsumメソッドを使用することもできます。

p (1..5).sum

すごいすっきりしますね～。用途によっては使い得ない場合もありますが、知っておいて損はないメソッドですね。

ここで、RubyとRailsでそれぞれメソッドを紹介させていただきましたが、先日上司にごっちゃにならないように！とアドバイスを頂きました。

便利なメソッドはどんどん覚えていったほうがいいのですが、使い方と同時にRailsのメソッドなのか、Rubyのメソッドなのか。。きちんと理解して使用することが大切のようです。

ご無沙汰してましたm(_ _)m

先月１児のパパになったシステム部の佐々木です。

本日はGoogle App EngineのCronサービスとメール配信についてつらつらと書いていきたいと思います。

Unix/Linuxをご存じの方には説明不要かと思われますが、そうです。あのCronです。

データベースの定期監視を行う場合など、非クラウド環境のJavaアプリケーションでは非同期スレッドを生成してsleepしながらデータベースを監視するというのが定石だったかと思いますが、GAEではそもそもスレッドの生成ができません。

これの代わりにGoogle App EngineではCronサービスを使用します。

それではCronサービスを使用して、定期的にメールを送信する方法を説明していきます。

１．ジョブの作成

まずは定時実行されるジョブを作ります。とはいっても作るのは単なるサーブレットです。
Google App EngineのCronサービスはURLに対してHttpGETリクエストを放ることでジョブの実行を行っているので「ジョブ＝サーブレット」ということになります。

Pureサーブレットでもよいのですが、筆者がSlim3を使用しているので、build.xmlの”gen-controller-without-view”からコントローラを生成します。
ここではURL”/cron/cronTest”としてCronTestController.javaを生成しました。

package com.sample.controller.cron;

import java.util.Date;
import java.util.Enumeration;
import java.util.logging.Logger;
 
import org.slim3.controller.Controller;
import org.slim3.controller.Navigation;
 
import com.google.appengine.api.mail.MailService;
import com.google.appengine.api.mail.MailServiceFactory;
import com.google.appengine.api.mail.MailService.Message;
 
public class CronTestController extends Controller {
 
    @Override
    public Navigation run() throws Exception {
 
        // MailService
        MailService service = MailServiceFactory.getMailService();
        // Message
        Message message = new Message();
        // 送信者は必ずアプリケーション管理者
        message.setSender("rl.ysasaki@gmail.com");
        // to
        message.setTo("y-sasaki@r-learning.co.jp");
        // タイトル
        message.setSubject("Cronテスト");
        // 本文
        message.setTextBody("メール送信テスト:" + new Date().toString());
        // 送信
        service.send(message);
        return null;
    }
}

処理中では低レベルのメールAPIを使用してメール送信を行っています。
ネット上で公開されているサンプルはjavax.mailを使用したサンプルが多いですが、低レベルAPIの方が簡単なのでこっちで書いてます。
http://code.google.com/intl/ja/appengine/docs/java/javadoc/com/google/appengine/api/mail/package-summary.html

２．ジョブのテスト

まずは作ったジョブが動くかどうかですね。メール送信はローカルでは確認できないのでGoogle App Engineにアプリケーションをデプロイします。
デプロイ後、ブラウザからhttp://アプリケーションホスト/cron/cronTestにアクセスし、メールが送信されればテストは完了・・・・・
とはいかないのです。
このままでは一般ユーザがURLにアクセスした場合に、不正なジョブの実行になってしまいます。
これを回避するために、adminユーザ以外のアクセスを禁止する必要があります。
一般ユーザのアクセスを禁止するにはwar/WEB-INF/web.xmlに以下の記述を追加します。

    <security-constraint>
        <web-resource-collection>
            <url-pattern>/cron/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>admin</role-name>
        </auth-constraint>
    </security-constraint>

これで管理者以外は”/cron/*”のURLにアクセスできなくなりました。

３．ジョブの登録

ジョブの登録はwar/WEB-INF/cron.xmlに以下の内容を記述し、デプロイしたら完了です。

<?xml version="1.0" encoding="UTF-8"?>
<cronentries>
	<cron>
		<url>/cron/cronTest</url>
		<description>CronTest And MailService</description>
		<schedule>every 1 minutes</schedule>
		<timezone>Asia/Tokyo</timezone>
	</cron>
</cronentries>

• url・・・実行するジョブのURL
• schedule・・・ジョブの起動タイミング(例は毎分)
• timezone・・・デフォルトはUTCなので日本時間でジョブ実行する場合は”Asia/Tokyo”を指定

Scheduleの書き方
http://code.google.com/intl/ja/appengine/docs/java/config/cron.html#The_Schedule_Format

Timezone
http://en.wikipedia.org/wiki/List_of_zoneinfo_time_zones

４．ジョブの解除

cron.xmlの<cron>要素を消してデプロイし直せばジョブは解除されます。
また、Google App Engineの管理コンソールから、登録されているCronの状態(Cron Jobs)を確認することもできます。

次回はTaskQueueについて書きます。

最近何かと名前を聞くようになってきたTitaniumという開発環境の資格を取ってきました！

↑その時にもらってきたシャツとUSBメモリ

とってきたのは”Titanium Certified Application Developer”というものなのでこの資格はモバイル(iPhone/Android)限定ですが、Titanium自体は他にもDesktopやWebのアプリケーションがJavascriptで作れたり作れるようになったりして、いいかんじです。

ということでほんの少しだけ、ほかのスマートフォン向けJavascriptフレームワークとTitanium Mobileの利点を紹介したいと思います。

・・・と、簡単ですがこんな感じです。

他になにか知りたければ@appcelerator_jaとか追いかけるといいと思うよ！

そいじゃ！

Don’t Repeat Yourself、つまり「重複を排除する」「同じ作業を繰り返さない」という意味です。