2013年6月24日月曜日

[Tizen]Tizenネイティブアプリ開発でのUnitテストの実施

このエントリーをはてなブックマークに追加 はてなブックマーク - [Tizen]Tizenネイティブアプリ開発でのUnitテストの実施

Tizenネイティブアプリ開発時のUnitテストについて試してみたのでメモ。

Tizenのネイティブアプリ開発ではC++での開発となりますが、テストはどうするのかというと標準でGoogle C++ Testing Frameworkが同梱されており、公式ドキュメントでもこれを使うような記述があるのでこれを利用するのが一般的ではないかと思われます。

Unit Test Tool

上記リンクからTizen Native App Programing→IDE and Tools→Unit Test Toolと辿るとTizen公式ドキュメントが確認できます。

今回の例ではサンプルアプリにクラスを追加し、そのクラスに対してテストを行ってみます。 手順は以下の通りです。

  1. テスト対象プロジェクト作成(サンプルアプリ)
  2. テストプロジェクトの作成
  3. テストプロジェクトの編集
  4. テストプロジェクトの実行

なお、公式ドキュメントにテストの項目の欄で以下の記述があるため、注意が必要ではあります。

  • The unit test tool is designed to support only functional testing.
  • The unit test tool is not an OSP-based application. Therefore, certain methods related to the OSP application framework, such as the methods of the Tizen::Base::String class, can behave incorrectly.

超適当な意訳

  • functionテストのみがサポートですよー。
  • このUnit Test toolはTizen用のテストツールって訳じゃないよ。なので、Tizen::Base::Stringクラスとかいくつかのメソッドなどは誤った動作するかと思われます。

ま、まじでか。 とか思って試しにTizenのStringを利用したテストコード書いてみましたが、一応大丈夫でした。 保証はできないってことか、な。

確認環境など

  • MacOSX 10.8.4
  • TizenSDK2.1(IDEやSDKなどはインストール済み)

1.テスト対象プロジェクト作成(サンプルアプリ)

まずはテスト対象のHellWorldプロジェクトをTizenIDEを利用して作成します。

  • File→New→Others
  • Tizen→Tizen Native Project
  • Templateタブを選択→Tizen Native→Form-based Application→With SceneManagerを選択。Project Nameは任意の名前でOKですが、本例ではHelloWorldとします。

これでとりあえずプロジェクトができます。

次にUtilクラスを追加します。

とりあえずこんな感じでメソッドを2つ作ってみました。(C++初心者なので書き方がまずいかもしれませんが、とりあえず許して下さい。。。)

Util.h

#ifndef UTIL_H_
#define UTIL_H_
#include <FBase.h>

class Util {
public:
    int Sum(int x, int y) ;
    void AppendWorld(Tizen::Base::String& base);
};


#endif /* UTIL_H_ */

Util.cpp

#include "Util.h"

int Util::Sum(int x, int y) {
    return x + y;
}

void Util::AppendWorld(Tizen::Base::String& base) {
    base.Append("World!");
}

Sum関数では引数に渡した2つの引数の加算を行った結果を返却します。

AppendWorld関数では引数に渡したTizen::Base::Stringクラスの参照引数を利用してAppendメソッドを呼び出して、引数に渡された文字列の末尾に“World!”という文字列を追加します。

今回は上記2つのメソッドに対してそれぞれテストコードを書いてみます。

2.テストプロジェクトの作成

Tizenでテストを行う場合、テスト対象のプロジェクトとは別に新規にテスト用プロジェクトを作成する必要があるようです。 以下の方法で作成を行います。

  • File→New→Others
  • Tizen→Tizen Native Unit Test Project
  • Select the Tizen Project for testの箇所でHelloWorldを選択。

これでHelloWorldプロジェクのテストプロジェクトの完成です。 デフォルトで以下のようなテンプレートテストコードが作成されます。

HelloWorldTest.cpp

include "tizenx.h"
#include "Util.h"
#include "HelloWorldPanelFactory.h"
#include "HelloWorldMainForm.h"
#include "HelloWorldFrame.h"
#include "HelloWorldFormFactory.h"
#include "HelloWorld.h"
#include "AppResourceId.h"

#include <gtest/gtest.h>

class TestSuite : public testing::Test
{
    protected:
    // virtual void SetUp() will be called before each test is run.
    // You should define it if you need to initialize the variables.
    // Otherwise, you don't have to provide it.
    virtual void SetUp()
    {

    }
    // virtual void TearDown() will be called after each test is run.
    // You should define it if there is cleanup work to do.
    // Otherwise, you don't have to provide it.
    virtual void TearDown()
    {

    }
};

// When you have a test fixture, you define a test using TEST_F.
// Otherwise, you define a test using TEST.
TEST_F(TestSuite, test01)
{
    ASSERT_TRUE(true);
}

TEST_F(TestSuite, test02)
{
    ASSERT_TRUE(false);
}

先ほど作成したUtilクラスのヘッダファイルもincludeされているのでテストコードが追加できそうです。

3.テストプロジェクトの編集

HelloWorldTest.cppにSum関数、AppendWorld関数のテストコードに以下のように追加(編集)します。 なお、test02はデフォルトだと実行するとNGとなってしまうので、こちらも変更します。

TEST_F(TestSuite, test02)
{
    ASSERT_TRUE(true);
}
TEST_F(TestSuite, test03)
{
    Util *p = new Util();
    ASSERT_EQ(3, p->Sum(1, 2));
    delete p;
}

TEST_F(TestSuite, test04)
{
    Util *p = new Util();
    Tizen::Base::String hello = Tizen::Base::String("Hello");
    Tizen::Base::String helloworld = Tizen::Base::String("HelloWorld!");
    p->AppendWorld(hello);

    ASSERT_EQ(helloworld, hello);
    delete p;
}

test03ではSum関数の引数に1と2を渡し、結果で3がかえってくる事を確認しています。

test04ではHelloという文字列のTizen::Base::Stringクラスを作成し、AppendWorld関数を利用する事で“HelloWorld!”という文字列になる事を確認しています。

なお、利用しているGoogle C++ Testing Frameworkについては以下の翻訳サイトを参考にさせて頂きました。(まだ全然読めてないですが)

Google C++ Testing Frameworkをはじめよう

4.テストプロジェクトの実行

いよいよテストを実行します。 テストの実行及び結果の確認はTizenIDEで実施できます。

テスト対象のプロジェクトのビルドをしてからテストコードの存在するプロジェクトをビルドします。

  • HelloWorld→右クリック→Build Project
  • HelloWorldTest→右クリック→Build Project

なお、先にHelloWorldTestの方をビルドすると以下のような先にテストする方のプロジェクトしろよ的なメッセージが出ます。その場合、メッセージの通り先にテスト対象のビルドを実施し、その後再度テストプロジェクトのビルドをすればOKです。

次にエミュレーターを起動します。 個人的にはエミュレーターなしでやりたかったのですが、IDEから実行するときは必要だったのでやっておきます。

さてこれで準備がすべて終わったのでいよいよテストを実行します。

  • HelloWorldTest→右クリック→Run As→Tizen Native Unit Test Application

これで実行されるのでしばし待ちます。

結果はIDE上のTest Resultで確認できます。

また、上記左にあるTest Exploerを利用すると特定のテストコードのみの実行ということも可能です。

Tips

設定を行う事で以下が可能なようですが未確認。

  • HelloWorldTest→右クリック→Run As→Run Configurations

以下設定可能項目。
  • Run Disabled Tests
  • Shuffle Tests
  • Don’t Print Elapsed Time
  • Generate and XML Report

Jenkinsとかとも連携さたいので今後はCLIからの実施方法なども確認したい。

2013年6月17日月曜日

[Tizen]Tizenネイティブアプリのビルドでccacheを利用してみる

このエントリーをはてなブックマークに追加 はてなブックマーク - [Tizen]Tizenネイティブアプリのビルドでccacheを利用してみる

前エントリーでC++の平行ビルドのやり方について書きましたが、もう一つのコンパイラキャッシュを利用してビルド時間を短縮する方法を記載します。具体的にはccahceというツールを利用します。 なお、利用するのがキャッシュなので1回目のビルドは早くならないみたいです。ご了承下さい。

また作業実施にあたり、以下を参考にさせていただきました。

ビルドの待ち時間を減らす - ツール編

ccacheのインストール

ccacheをインストールします。 Macの場合にはhomebrewでインストールできます。Windowsの場合、ビルドするための環境(cygwinなど)が必要なようです。。。なお、こちらが公式サイトとなります。

$brew install ccache

Ubuntuなら以下でも大丈夫なようです。(確認はしてません)

$sudo apt-get install ccache

後で利用するのでパスも確認します。

$which ccache
/usr/local/bin/ccache

ccacheの利用

TizenのC++コンパイラはclang++というのを使っているみたいで、そのコマンドを利用する際にccacheも利用してね、という設定を行います。

  • 対象のプロジェクトで右クリック→Properties

  • C/C++ BuildでGenerate Makefilesにチェックが入っている事を確認

  • Settings→C++ Compiler

Commandの箇所を変更したいのですが、変更しても反映されないので(バグか?)ちょっと微妙な気もしますが、Command line patternの箇所を変更します。

  • 変更前→${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}
  • 変更後→/usr/local/bin/ccache clang++ ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}

また、上記だけでなくC++ Linkerも同じように変更します。

  • 変更前→${COMMAND} ${OUTPUT_FLAG}${OUTPUT_PREFIX}${OUTPUT} ${INPUTS} ${FLAGS}
  • 変更後→/usr/local/bin/ccache clang++ ${OUTPUT_FLAG}${OUTPUT_PREFIX}${OUTPUT} ${INPUTS} ${FLAGS}

ちょっと、いやかなりださい気もしますが、commandの箇所が変更できないので仕方ない。。。

ビルドしてみる

対象のプロジェクトを右クリックしてビルドしてみます。 で、Consoleで上記設定が反映されているかを確認します。

/usr/local/bin/ccache clang++ -I"pch" -D_DEBUG ...(以下略)

上記の通り、コンパイルの箇所でccacheを利用したコマンドへの変更ができているようです。

また、以下のコマンドを実行するとどれぐらいキャッシュが有効だったかなどを確認できます。

$ ccache -s
cache directory                     /Users/toshihirock/.ccache
cache hit (direct)                    54
cache hit (preprocessed)               0
cache miss                            19
called for link                        9
files in cache                        34
cache size                          14.7 Mbytes
max cache size                       1.0 Gbytes

こんな感じで結果がでます。私はHelloWorldプログラムでの確認なのであんまり効果がないっぽいですが、大きなプロジェクトであれば、効果があるかと思っております。 実際に早くなっているかについては計測していないので分かりませんが、時間とやる気があればどこかで。

2013年6月16日日曜日

[Tizen]Tizenのネイティブアプリで平行ビルドしてみる

このエントリーをはてなブックマークに追加 はてなブックマーク - [Tizen]Tizenのネイティブアプリで平行ビルドしてみる

Tizenのネイティブアプリ開発はC++で実施しますが、TizenIDEでビルドする際に平行ビルドを有効にする方法のメモ。

平行ビルドによってビルド時間が短縮できるかはソースの構成などに依存するっぽいですが、C++のビルド時間短縮の常套手段っぽいのでとりあえずやっておきます。

手順

  • 対象のプロジェクトを選択して右クリック→Properties。

  • C/C++ Build→Behaviourタブをクリック。

  • Use parallel buildにチェックを入れる。

  • Use optimal jobs numberもしくはUse parallel jobsと数字を入れる。

例えばUse parallel jobsにチェクをして、数字に2と入れるとビルドの際にmake -j 2 となっており、平行ビルドが実行されている事がTizenIDEのConsoleで確認できます。

/Users/toshihirock/tizen-sdk/tools/smart-build-interface/bin/sbi action tizen-emulator-2.1.native_llvm31.i386.cpp.app -- make -options="-j2 all" -cliprojpath="" -clisdkpath="" -cliunitprojpath="" -cliappid="" 
Checking prerequisite...
Checking make... ok
Building file: ../inc/tizenx.h

平行ビルド数はPCのCPU数コア数より少し多い(?)ぐらいらしいです。。よく分からんけど。

私の環境だとUse optimal jobs numberにすると並列ビルドになりませんでした。サンプルでビルドしているのがHelloWorldのサンプルアプリだからなのかもしれませんが。

2013年6月10日月曜日

[Tizen]Tizenアプリのログ出力方法とかについてドキュメント確認してみた

このエントリーをはてなブックマークに追加 はてなブックマーク - [Tizen]Tizenアプリのログ出力方法とかについてドキュメント確認してみた

TizenのドキュメントのDebugging Macros(ログとかデバッグに関する記述)について確認したのでメモ。 なお、PCのスペックが低くて、実際確認ほぼできず、ドキュメントを意訳した内容となります。

確認はTizenSDK2.1となります。

ドキュメントの詳細は公式サイトのDebugging Macrosを参照ください。

LogViewの表示

以下の操作でTizenIDEより表示出来ます。

Window→Show View→Log

ほとんどAndroidの奴と一緒っぽい感じ。

  • ログレベルによるフィルタリング
  • タグによるフィルタリング
  • ログのエクスポート
  • ログのクリア

とか出来るっぽいです。

ログの書き方

何やら大きく分けて4種類も有るみたい。

  1. Log Macros
  2. Try Macros
  3. Assert Macros
  4. Secure Log Macros

1.Log Macros

すごく普通のログ。

ログレベル指定

ログレベル(info,debug,error)を呼び出すメソッドによって切り替え、引数には表示するログメッセージを設定。

以下記述例。

AppLog("Initialization successful.");

また、以下に各ログレベルでの記述方法を記載します。

  • AppLog(message)
  • AppLogDebug(message)
  • AppLogException(message)

一番上のAppLogはInfoレベルで、AppLogDebugがDebugレベル、AppLogExceiptionがErrorレベルでの出力となります。

条件付きログ出力

第一引数(expression)の条件式がtrueの場合のみログ出力する事も出来る。

以下記述例。

int initVal;

// If initVal is greater than 0, print the info message to the console
AppLogIf(initVal > 0, "initVal is %d.", initVal);

上記のように記載すると変数initvalが0より大きい場合のみログを出力する事が出来ます。 また、以下に各ログレベルでの記述方法を記載します。

  • AppLogIf(expression, message)
  • AppLogDebugIf(expression, message)
  • AppLogExceptionIf(expression, message)

タグ付け

フィルタリングしやすいようにタグを付けてログ出力も出来る。

以下記述例。

AppLogTag("MyTag", "Initialization successful.");

また、以下に各ログレベルでの記述方法を記載します。

  • AppLogTag(tag, message)
  • AppLogDebugTag(tag, message)
  • AppLogExceptionTag(tag, message)

2.Try Macros

条件式結果によってhogeしてからログ出力…みたいな事が出来たりします。なお、ログレベルは一律でError

後述するAssert Macrosとの違いとしてこちらのTry MacrosではプロセスKillはしないみたいです。

TryCatch(condition, expressions, message)

実例を見た方が分かりやすいので、以下記述例。

const A*
MyClass::DoSomething(const wchar_t* pValue)
{
    result r = E_SUCCESS;
    // Do something

// If pValue is null, print "[E_INVALID_ARG] The pValue is null." to the console, 
// execute the expression "r = E_INVALID_ARG", and move to CATCH
TryCatch(pValue != null, r = E_INVALID_ARG, "[E_INVALID_ARG] The pValue is null."); 

SetLastResult(E_SUCCESS);

return _pValue;

CATCH:
  SetLastResult(r);

  return null;
}

英語で書いてある通りですが、

  1. pValueがnullか判断。(conditionの条件式)
  2. pValueがnullの場合、ログで[E_INVALID_ARG] The pValue is null.とErrorレベルのログを出力。
  3. 変数rに定数E_INVALID_ARGを代入。
  4. Catch構文に遷移。

という流れみたいです。

TryReturn(condition, returnValue, message)

条件式(condition)で結果がfalseの場合、messageを出力して、returnValueに記載された値を返却する。

TryReturnVoid(condition, message)

条件式(condition)で結果がfalseの場合、messageを出力して、returnするけど値は設定しない(void)と。

TryLog(condition, message)

条件式(condition)で結果がfalseの場合、messageを出力してその後の処理を継続。(returnしない)

タグ付け

上記それぞれのメソッドで引数が一つ増えてタグを付けるものがありますが、説明は省略。

3.Assert Macros

条件式(condition)の内容がfalseの場合、なんとプロセスkillするそうです!

リリースビルドではやめてね、って書いてあります。

AppAssert(condition)

条件式(condition)で結果がfalseの場合、現在のプロセスをkillする。(ログ出力なし)

AppAssert(condition, message)

条件式(condition, message)で結果がfalseの場合、messageの内容をエラーレベルのログとして出力し、現在のプロセスをkillする。

4.Secure Log Macros

基本的にLog Macros,Try Macrosと似たメソッドがあるが、以下の点が違うようです。

  • 「_SECURE_LOG」を定義していればログを出力するし、なければコンパイルタイミングで消す。
  • 出力ログ文字列の先頭にprefixとして[SECURE_LOG]を追加

一つの目の点が大きな違いですね。(すいません、C++があまり分からず、_SECURE_LOGを定義、というのが具体的に何をすれば良いのか分かってません。。値はいれず、単純に宣言すればよい?)

という事で以下はメソッドのみ記述。

  • AppSecureLog(message)
  • AppSecureLogDebug(message)
  • AppSecureLogException(message)
  • AppSecureLogTag(tag, message)
  • AppSecureLogDebugTag(tag, message)
  • AppSecureLogException(message)
  • AppSecureLogTag(tag, message)
  • AppSecureLogDebugTag(tag, message)
  • AppSecureLogExceptionTag(tag, message)
  • SecureTryCatch(condition, expressions, message)
  • SecureTryReturn(condition, returnValue, message)
  • SecureTryReturnVoid(condition, message)
  • SecureTryLog(condition, message)
  • SecureTryCatchTag(tag, condition, expressions, message)
  • SecureTryReturnTag(tag, condition, returnValue, message)
  • SecureTryReturnVoidTag(tag, condition, message)
  • SecureTryLogTag(tag, condition, message)

2013年6月8日土曜日

第1回 Build Insider OFFLINE勉強会のメモ

このエントリーをはてなブックマークに追加 はてなブックマーク - 第1回 Build Insider OFFLINE勉強会のメモ

Blogを書くまでが勉強会!

という事で第1回 Build Insider OFFLINEに参加して来たのでその際のメモ。(間違っているなどの箇所が有れば修正します!)

★JavaScripライブラリーを使い倒そう!(Wingsプロジェクト 安西さん)

1.手間を省こう系

  • jQuery,protorype.js
  • jQueryUIなどのUIライブラリ。Choosen,竹取JS,FullCalendar,jqPlot(グラフ)など
  • Twitter Bootstrap
  • jQueryMobile

使いまくると読み込むファイル数が多くなり、表示速度が遅くなるので注意。

高速化のポイント

  • ファイル数を少なく
  • CSSスプライト
  • JavaScriptの読み込みタイミング
  • ブラウザキャッシュ

2.言語特性補う系

  • CoffeeScript
  • TypeScritp

3.フレームワーク系

  • Backbone.js
  • Angular.js
  • Knockout.js
  • Ember.js
  • Spine.js

4.ゲーム系

新人教育にゲーム系フレームワーク利用させるのはオブジェクト指向の理解としても有効だった。

  • enchant.js
  • Unity

5.サーバー系

  • Node.js
  • Express.js

6.テスト系

テストフレームワーク

  • Qunit
  • Mocha
  • Jasmine

テストを書いてからメソッドを書く。→TDD形式。 ユーザーからの振る舞い→BDD形式。

  • JSTestDriver
  • sinon.js

静的解析

  • JSHint
  • Jscoverage

JSテストでLinux,Mac,WindowsをVMで立ててJenkinsとJsTestDriverを利用した。

★3つのMVC系人気フレームワーク、Backbone.js/AngularJS/Knockout.js

Backbone.js(LINE株式会 清水さん)

  • Angluar.jsはフルスタック
  • MVCモデル
  • BackboneにはPluginなどがある。Utilityも存在。
  • Plugin→backbone relational,backbone forms,marionettejs,backbone boilerplate
  • Angular.jsはPC,モバイルはBackbone.jsの方が使いやすい印象。(Angularはフルスタックだからでかい)
  • BackboneはREST使うとすごく短いコードで書ける。
  • テストはGruntを利用。jasmine,mochaなど。テストコードが書きやすい。
  • Gruntのwatchタスクでファイル変更を監視して、テストコード自動実行みたいなの便利。
  • Grunt notifyで実施したテストでエラーだった場合にMacのNotification(Growl)なども出来て便利。

Angular.js(金井さん)

得意

  • CRUDとか強力。
  • 管理ページ、マイページ作成など得意。

苦手

  • モバイル系は苦手。というかファイルサイズがかなり大きい。
  • ゲームなどのグラフィックの扱い。

テスト

  • Karma

モバイルについて

  • ngMobileというのが追加されてはいるが、現在はフルスタックのため、全ての機能がある。
  • 元からダウンロードするアプリとか(リソースにAngularJSを置く)であればモバイルでも有用。

UI

  • AngularUIなど、色々あるので外部のものを利用するのが良さげ。

Knockout.js(沢渡さん)

  • MVVMパターン
  • 単一のライブラリでjQueryにも依存しない。
  • 他のフレームワークと比べると軽量。
  • Observableとは?Knockout.jsの機能。機能の通り、値が変わったか、などを確認出来る。varで宣言した値が変わった場合などの監視も可能。
  • subscribeで変更された時に通知する先を指定可能。コールバック関数を宣言。
  • ko.computedはobservableと同様に値の監視が出来る。
  • もう一つの大きな機能。バインディングが存在する。

★スマホ向けWebアプリ開発で使えるフロントエンド高速化手法( 株式会社gloops 児玉さん)

基本

  • styleは上に、scriptは下に
  • 画像の形式。もしくは画像をCSSで代用。
  • minify化、キャッシュの利用。
  • CSSスプライトの利用。
  • DataURIスキームを使う。

CSSスプライト

  • HTTPリクエストが減る。一回に。
  • デメリットとしては画像の表示は遅くなる。

DataURIスキーム

  • HTTPリクエスト無し
  • CSSスプライトより表示処理は早い
  • デメリットとして画像ファイルの容量が大きくなるのでキャッシュが必須。

どの程度まで頑張る?

  • 1秒以内とか目標を。

ページサイズとHTTPリクエスト減らしても遅い場合は?

  • CSSセレクタは右から左へ解釈されるのでそこを考慮すべき。ただし、そこまで改善が見込めない場合も有るので、やりすぎは良くない。
  • 処理が重いCSS。border-image,background-size グラデーション、box-shadow,text-shadowなど。
  • Gooogle Chrome Canaryで設定するとCSSの描画を繰り返す事が出来るので、そこで処理のボトルネックを探す事が出来る。
  • JSでfor文のlengthは変数に入れて回すべき。処理速度の観点から。
  • dom操作するとブラウザ側でスタイルやレイアウトの再計算が行われるので、なるべく少なくすべき。

ユーザー体感速度の高速化

  • 操作出来る部分を先に表示する。例えば画像のレンダリング順番を変える。cssのbackground-imageよりimageタグの方が先にレンダリングされる。
  • touchイベントとmouseイベントは違う。PCはmouseイベントのみ。また、スマホではtouchイベントが早い。
  • touchstart→指が触れて発生。touchhend→ディスプレイから指を離すと発生。

[Tizen]TizenIDEからローカルでTizenドキュメントを参照する方法

このエントリーをはてなブックマークに追加 はてなブックマーク - [Tizen]TizenIDEからローカルでTizenドキュメントを参照する方法

TizenIDEからローカルでTizenドキュメントが参照出来るのでメモ。

TizenIDEを起動して、Help→Help Contentsでブラウザが起動してローカルで参照が出来る。

地味だけど便利っす。

また、TizenSDKのクラス、メソッドなどにhover(マウスを合わせる)するとドキュメントがIDE上で参照出来るのでこれも便利。

2013年6月2日日曜日

[Tizen]Tizen Nativeアプリ(C++)でDoxygen+Graphvizを使ってJavaDoc形式コメント書いてみたり、クラス図継承関係確認してみた話

このエントリーをはてなブックマークに追加 はてなブックマーク - [Tizen]Tizen Nativeアプリ(C++)でDoxygen+Graphvizを使ってJavaDoc形式コメント書いてみたり、クラス図継承関係確認してみた話

TizenのネイティブアプリはC++で書かなければいけなくて、C++でJavaDoc的にソースコードにコメントを書こうと思って、何か良いのないかなーと調べてたら何やらDoxygenでそれ出来るよと。

ちなみにDoxygenですが以下のような特徴が有ります。

  • 対応言語はC++だけでなく、Java、Objective-C、Pythonなどがある。
  • Windows、Mac OS X、Linuxで動く。
  • 出力形式としてHTML以外にXMLやLaTeX、RTFもある。

あとGraphvizも使うとクラス図とそれぞれの依存関係が分かるとかでやってみました。

というか最初に言ってしまうとTizen公式サイトのAPIリファレンスもDoxygen+Graphvizを利用しているっぽかったので、結構デファクトスタンダードなのかもとか思ったり。(C++は全く詳しくない)

参考

なお、実施に当たり、以下のサイトを参考にさせて頂きました。

ソースコードを読むのに Doxygen + Graphviz が便利な件

Doxygen+Graphvizでクラス図を自動生成する

確認方法

本例ではTizenIDEでサンプルテンプレートとして用意されているTizenネイティブアプリのFrom-based Application→With SceneManagerにJavaDocコメントを追記して確認しました。(HelloWorldアプリ)

コメント追加

まず、HelloWrold.cppにJavaDoc形式でコメントを記述します。 なお、詳細なコメント記述形式は以下の公式サイトコードのドキュメント付けが分かりやすいです。

Doxygen、Graphvizのインストール

次にDoxygenのインストールします。Homebrewを利用。

brew install doxygen

Graphvizもインストール。こちらもHomebrewを利用。

brew install graphviz

簡単!

なお、Windowsもそれぞれの公式HPにインストーラーがあって簡単にインストール出来ます。

設定ファイル作成

次にクラス図を作成したいディレクトリに移動し、doxygenコマンドで設定ファイルを作成。

cd tizen_workspace/HelloWorld/
doxgen -g

なお、Windowsの場合、doxygenのインストールが終わるとすべてのプログラムにdoxygen wizardというプログラムがあり、それでどのフォルダのドキュメント作成をするか指定していきます。

上記実行後、カレントディレクトリにDoxyfileというファイルが生成されますので、これを編集して出力するドキュメントの詳細を記述します。私の環境ではとりあえず以下を設定。 オプションの詳細はDoxygenを参照下さい。

# 文字エンコーディング。
DOXYFILE_ENCODING = UTF-8

# 出力するファイルの言語
OUTPUT_LANGUAGE = Japanese

# 再帰的にソースコードを捜索するか。
RECURSIVE = YES

# Graphvizを利用するか
HAVE_DOT = YES

# Graphvizのパス。Homebrewでインストールした場合、PATHが通っているので設定しなくても良い。Windowsの場合、Graphvizのbinフォルダを指定する。
DOT_PATH =  

# LaTexを出力するか。
GENERATE_LATEX = NO

実行

設定が終わったら以下のコマンドでドキュメント出力。

doxygen

見てみる

カレントディレクトリにhtmlフォルダが作成されます。その下にindex.htmlが有るので表示。

open html/index.html

しっかり日本語で表示出来てます。

試しにJavaDocコメントを記載したHelloWorld.cppを見てみます。

おお、良い感じ。しっかり日本語表記も出来てます。

クラス階層を見るとこんな感じ。継承関係が分かりやすく表示されています。

上記画面でクラスをクリックすると該当クラスの詳細に遷移するとかも便利。あと左上の検索バーでクラス検索が出来るのですが、サジェスト検索出来るのも結構嬉しい機能。

おまけ

結構感動してJavaのプログラムにも実行してみましたが、クラス継承関係が図式で表示する事が出来て非常に有用だと感じました。

[Tizen]Tizenエミュレーターを動かそうとしてActive secure profile is not set.Please check the signing configuratons at Preferenceとかエラーで出た場合の対応

このエントリーをはてなブックマークに追加 はてなブックマーク - [Tizen]Tizenエミュレーターを動かそうとしてActive secure profile is not set.Please check the signing configuratons at Preferenceとかエラーで出た場合の対応

TizenSDK2.1系でNativeアプリ、Webアプリ関わらずエミュレーターでTizenアプリを始めて動かそうとすると以下のエラーダイアログが表示される場合が有る。

Active secure profile is not set.Please check the signing configuratons at Preference > Secure Profiles.

エミュレーターにアプリをインストールする際に利用する証明書が設定されていないと表示されるエラーです。Profileで証明書を指定する必要があるので、以下の公式サイトCertificate Generatorの通り証明書を作成します。

TizenSDKをインストールしたディレクトリの配下に証明書作成用のディレクトリがあるので移動。<TIZEN_SDK_HOME>の箇所は自分がTizenSDKをインストールしたディレクトリに置き換えて下さい。

cd <TIZEN_SDK_HOME>/tools/certificate-generator 

Shellを実行(Windowsの場合、certificate-generator.batを実行)

./ certificate-generator.sh

質問が色々出てきますが、とりあえず動けば良いのでOptionalの箇所は何も指定せず(Enterを押すのみ)、それ以外の箇所も公式サイトの例の通り指定。

toshihiro308@Toshihirock-MacBook-Air:~/tizen-sdk/tools/certificate-generator$ ./certificate-generator.sh 
Please enter the country name(optional, two letters): (Enter)

Please enter the state or province name(optional): (Enter)

Please enter the city name(optional): (Enter)

Please enter your name(optional, default is 'author'): (Enter)

Please enter your organization name(optional): (Enter)

Please enter your department name(optional): (Enter)

Please enter your email id(optional): (Enter)

Please enter password for pkcs12 format key certificate: 
mypassword
Please enter alias for generated pkcs12 structure: 
ryan
Please enter file name for storing pkcs12 file (*.p12): 
ryan.p12

上記の通り、実行するとカレントディレクトリにryan.p12というファイルが生成されます。

次にTizenIDEに上記のファイルを利用してね、ということを設定します。 TizenIDEを起動し、

TizenIDE→Preferences→TinzenSDK→Secure Profiles

を選択。

ProfilesのAddを押して適当な名前のProfileを作成します。

Profile ItemsのCerificate pathに先ほど生成したp12ファイルのパスを指定し、PasswordにはPlease enter password for pkcs12 format key certificateで指定したパスワードを記載(上記例ではmypassword)を指定し、OKを選択。

その後はTizenエミュレーターで確認が出来ると思います。