http://sophiacradle.noblog.net/blog/index.html Sophia　Cradle, Inc.　株式会社ソフィア・クレイドル sophiacradle http://sophiacradle.noblog.net/blog/f/10032471.html ソフィア・クレイドル社長日記 この日記に頻繁に登場する『ＢＲＥＷ（Binary Runtime Environment for Wireless）』について、携帯電話の動向も交えてまとめてみよう。 プロモーション活動があまり推進されていないので、ＫＤＤＩの『ＥＺアプリ（ＢＲＥＷ）... BREWとは 2005-03-19T15:22:59+09:00 ソフィア・クレイドル社長日記

この日記に頻繁に登場する『ＢＲＥＷ（Binary Runtime Environment for Wireless）』について、携帯電話の動向も交えてまとめてみよう。

プロモーション活動があまり推進されていないので、ＫＤＤＩの『ＥＺアプリ（ＢＲＥＷ）』が利用できる携帯電話のユーザーでもない限り、『ＢＲＥＷ』と聴いてもピンとこない人が多いような気がする。ＮＴＴドコモの『iアプリ』なら携帯電話でゲームができるプラットフォームとして、きっと大半の方がご存知だろう。

『iアプリ』と同じように、『ＢＲＥＷ』はインターネットのサーバーに置かれたアプリケーション（ソフトウェア）を携帯電話にダウンロードして利用するシステムだ。現在はゲームなどのアプリケーションが中心だが、将来的には電話帳やメーラー、ブラウザといった携帯電話に組み込まれるようなソフトウェアまでもがダウンロードして入れ替え可能になる。『iアプリ』は『Ｊａｖａ』、『ＢＲＥＷ』は『Ｃ』や『Ｃ＋＋』というプログラミング言語をベースにしている点が構造上の目立った違いである。（『ＢＲＥＷ』上で『Ｊａｖａ』も利用可能なので、『ＢＲＥＷ』と『Ｊａｖａ』を単純には比較することはできないのだが…。）

『日本語』、『英語』、『スペイン語』・・・、世界にはいろんな言語が存在し、日常生活で使っている言語によって生活や仕事の環境が影響され言うまでもなく言語は重要な位置付けにある。それと同じようにコンピューターの世界においても、どのプログラミング言語によってソフトウェアを開発し運用するかはとても重要な要素だ。

ソフトウェアの致命的な弱点は、それが人手によってしか開発できない点にある。携帯電話はiモードが発表された1999年を境にして、コンピューターとしての側面から急激にハードウェア機能が進歩している。コンピューターの場合、ハードウェアとソフトウェアは車の両輪もいえるくらい両者のバランスは大切だ。ハードウェアが進歩すればそれにあわせてソフトウェアも進歩しなければトータルとしての携帯電話の価値が損なわれてしまう。

だから、ハードウェア機能がハイエンドなものになれば、それだけソフトウェアも大規模化し複雑化する。機械的な仕組みによって「ソフトウェア」が開発されるのならば何ら問題ないのだが、現実は科学技術が発達した今でも、ソフトウェアは高度であればあるほど職人技を駆使して開発される傾向にある。

そんな風にして携帯電話のソフトウェアが開発されるとするならば、それが大規模化し複雑化すればするほどソフトウェア開発費が膨らむことになる。現在では携帯電話の総開発コストの８０％はソフトウェアが占めるようになってきているという。でも開発費が高くなったからといって、製品価格を高くして利用者にしわ寄せすれば今度は売れなくなってしまう。

『Ｊａｖａ』や『ＢＲＥＷ』以前は、携帯電話のソフトウェアというものは、携帯電話のメーカーごと機種ごとに個別に開発されてきた。膨大な費用をかけて開発されたソフトウェアがその機種だけでしか動かないとすれば非常に効率が悪い。しかし、この問題も携帯電話の機種やメーカーによらず、ソフトウェアのプラットフォームを統一すれば、多種多様なたくさんの携帯電話でそのソフトウェアが利用可能になる。従って、たとえソフトウェアの開発費が膨大になったとしても、それだけ多くの携帯電話で利用可能になれば１台あたりのソフトウェアの費用を妥当なレベルにまで逓減できるのだ。

そのような背景から生まれたのが、『ＢＲＥＷ』であり『Ｊａｖａ』という次世代携帯電話向けの統一されたソフトウェアプラットフォームである。基本的な思想としては、『ＢＲＥＷ』や『Ｊａｖａ』というプラットフォームの標準に準拠して開発されたソフトウェアは、世界中の携帯電話で同じように利用できる、というのが大きなメリットだ。

『Ｊａｖａ』は１０年ほど前に登場した比較的新しい高機能なプラットフォームであるが、『ＢＲＥＷ』の要素技術となっている『Ｃ／Ｃ＋＋』は３０年ほど前に登場したプログラミング言語である。『Ｃ／Ｃ＋＋』はコンピューターのＣＰＵやメモリーに速度的、容量的な制約があったとしてもハードウェアを直接制御することで、『Ｊａｖａ』に比べて小さくて速いソフトウェアを開発できる。（同じ処理内容のプログラムでもＪａｖａとＣを比較すれば速度的に数倍、場合によっては１０倍くらいの開きがでるという。）

２００１年１月にＢＲＥＷは米国クアルコム社によって発表された。ＫＤＤＩでＢＲＥＷのサービスが始まったのは２００３年２月末なので、国内では今年がＢＲＥＷの３年目の年となる。２００５年２月時点で、世界的には２４ヶ国４１の通信事業者が『ＢＲＥＷ』を採用している。

ＮＴＴドコモの『ＦＯＭＡ』でも利用されている『ＣＤＭＡ』という次世代携帯電話の基本的な特許の大半を米国クアルコム社が抑えているだけに、次世代携帯電話の普及と共に『ＢＲＥＷ』が搭載された携帯電話は世界中で急増する見通しだ。最近ではヨーロッパ、アジアで普及している『ＧＳＭ』という技術に基づく携帯電話でも『ＢＲＥＷ』は利用可能になっているし、米国Ｉｎｔｅｌ社の携帯電話用チップである『ＸＳｃａｌｅ』でも『ＢＲＥＷ』は稼動する。

携帯電話用ソフトウェアのプラットフォームとして、『ＢＲＥＷ』、『Ｊａｖａ』以外にも『Ｓｙｍｂｉａｎ』、『Ｌｉｎｕｘ』といったＯＳも存在するのだが、時間の経過と共にパソコンと同様に一つに『収斂（コンバージェンス）』してゆくだろう。

『ＢＲＥＷ』以外の『Ｊａｖａ』や『Ｓｙｍｂｉａｎ』、『Ｌｉｎｕｘ』は高性能なハードウェアが前提になっているだけに、ハイエンドの携帯電話にしか搭載できない点が懸案事項ではないかと思う。世界の携帯電話市場では一年の７億台以上もの携帯電話が出荷されている。その大半が50ドル前後の携帯電話らしい。『ネットワーク外部性』でもお話したようにインターネットの時代ではテクノロジーそのものよりもそれに関わる『数』そのものに大きな価値がある。『ＢＲＥＷ』であれば、50ドル前後の携帯電話でも搭載することが可能だ。

携帯電話が次世代へと移り変わる中にあって、世界の携帯電話市場に激変が訪れるだろう。それがどのように推移していくかは興味深いし、ベンチャーにとって絶好の参入の機会ではないだろうか。


追記：

たまにQualcomm社のＢＲＥＷのロゴの下に"Customize, Personalize, Realize"という３つのキーワードを見かけることがある。

最近、着せ替え可能な携帯電話が発売されて、利用者から支持されているようだ。

Qualcomm社の"Customize, Personalize, Realize"は『着せ替え』を電話帳、メーラー、ブラウザなど携帯電話の内部に組み込まれたソフトウェアをもネットからダウンロード＆インストールし、利用者の好みや必要に応じてカスタマイズできるようにしようというビジョンだ。

パソコンのようにインストールされたソフトウェアの種類によって、携帯電話自体が全く異なる働きをするツールになる日がまもなくやってくる。]]> http://sophiacradle.noblog.net/blog/g/10030884.html The Architecture of SophiaFramework Sophia Cradle developed SophiaFramework, an application framework for C++ programming language, to make the development of applets that run on QUALCOMM's BREW platform more efficient. SophiaFramework is ... 2005-03-07T17:15:59+09:00 SophiaFramework

Sophia Cradle developed SophiaFramework, an application framework for C++ programming language, to make the development of applets that run on QUALCOMM's BREW platform more efficient. SophiaFramework is not simply a framework, but it is also offered as a library that contains extendable graphical user interface (GUI) objects and data processing classes.
With SophiaFramework you can improve your development productivity by 300 per cent compared to standard BREW development method. SophiaFramework is therefore most useful when you need to mass-produce applets or develop in a short period of time.

When you want to process events in C programming language, you will have to enumerate conditions and use traditional working method with buffers. Moreover, you will need to take care of releasing objects because management of objects in BREW APIs is left to programmer. This kind of developmental environment is good when making small applets which require speed, like games, but not when making large-scale applets such as those of business purposes or information distribution. In such case, it is time-consuming because the first thing you need to do before processing data of the applet is to fix bugs at a lower level. On the other hand, SophiaFramework gives benefits to development of BREW applications, much more than the standard development method. It provides the following features.

1.Interface Management

Most BREW APIs are offered in the form of interface objects, and object's lifecycle is controlled by incrementing and decrementing a reference counter. Inadequate object management will lead to a memory leak, which is a crucial bug on mobile phone platform. As a solution, SophiaFramework equips with C++ wrapper classes for all BREW APIs and smart pointers that control the reference counters making instant calls for APIs and automatic management of objects.

2.Event Handling

Event handling mechanism of the standard BREW tends to be complex and the source codes become difficult to be maintained as the size of an application gets bigger. Complexity of event handlers is common in most applications that use user interface components. SophiaFramework uses simple object-oriented event handlers so that the source codes are easily read and highly maintained. It therefore helps a programmer to develop applets that have high-level and complicated user interface functions.

3.Strings

When using string with standard BREW APIs which is written only in C programming language, you need to handle pointers direcly. Handling pointers can cause problems of bugs putting a heavy burden for a programmer. In addition, there are two types of characters for BREW - ANSI and AECHAR, and an engineer often needs to convert them in BREW programming. SophiaFramework offers string classes for each character type so that a programmer can handle strings and convert the character type easily with a simple construction.

4.Collections

There is no collection class in BREW SDK, which makes a huge barrier to an engineer to develop a high-functioning applet. SophiaFramework enables easier data management by providing a number of collection classes.

5.Streams

BREW stream input and output uses non-blocking model. Controlling input and output of non-blocking model in C programming language requires many complicated procedures such as buffer management. SophiaFramework solves the problem because these complicated procedures are implemented on its C++ classes, therefore an engineer can easily use stream input and output to make an application that has strong network function of BREW.

In addition, it is no easy matter to encode drawing timing and design to make user interface (UI) that has active and elaborate design, with the standard BREW APIs. SophiaFramework will help you in such case as explained in the following.

1.Flexible and Good-looking UI:

Engineers find it difficult to extend the standard BREW components because APIs themselves have no multi-window support. The design is not attractive enough either. However, with SophiaFramework, an engineer can easily use well-designed UI components and customize actions as he wants. Moreover, UI components that are developed with SophiaFramework automatically have multi-window support.

2.Graphics Operation:

The standard BREW APIs include two drawing interfaces - IDisplay for drawing strings or simple graphics and IGraphics for drawing polygons or complex graphics. There are advantages of having separate interfaces, but for most applets it is not so useful because you need to go through a number of processes even to make a simple operation. For example, you need to set colors and offsets for each interface to adjust text and image. SophiaFramework offers a drawing class which is an abstraction of IDisplay and IGraphics making it easy to operate graphics.

3.Graphics and Colors Calculations:

Since the standard BREW programming is based on C programming language, operating graphics and colors requires you to calculate member variables of the structures. These operations are common and can become a hotbed of bugs. Therefore, SophiaFramework provides graphics class and color class that help an engineer to calculate easily and correctly.
In conclusion, adoption of SophiaFramework and C++ in the development substantially saves time, resource and cost of maintaining applets.

We offer SophiaFramework Application Wizard for easier development of applets with SophiaFramework.

]]> http://sophiacradle.noblog.net/blog/a/10025228.html ◆BREW ラッパー クラス ○参照カウントの自動管理 【問題点】 BREW インターフェイスは、参照カウントの管理を自分で行わなければならず、開発者の負担が増え、不具合の発ｶにつながりやすい。 【解決】 SophiaFramework では、BREW インターフェイスの参照... 2004-12-30T21:39:59+09:00 BREW ラッパー クラス

○参照カウントの自動管理

【問題点】
BREW インターフェイスは、参照カウントの管理を自分で行わなければならず、開発者の負担が増え、不具合の発ｶにつながりやすい。

【解決】
SophiaFramework では、BREW インターフェイスの参照カウントを自動管理することで、開発者の負担を軽減し、不具合の発生を抑える。

【事例】
−BREW API だけを使う場合のプログラミング例

void MyFunc() {
IHash* pHash
ISHELL_CreateInstance(pShell, AEECLSID_MD5, (void**) &pHash);
/* ... pHash の関数呼び出し */
pHash->Release(); /* インターフェイスの使用後に必ず解放する必要がある */
}

−SophiaFramework を使ったインターフェイスの扱い方
Void MyFunc() {
SFUBrewPtr hash = SFBHash::Instance(AEECLSID_MD5);
/* hash の関数呼び出し */
/* インターフェイスは自動的に解放されるので、気にしなくてよい */
}


◆文字列

○文字列バッファの自動管理
メモリを使用する場合、メモリが必要なときに確保し、不要になったら解放しなければならない。C 言語では、確保と解放をすべて自分で書かなければなりませんが、C++ 言語を使うと、自動的に確保したり、自動的な解放が実現できます。これにより、次の利点が得られます。
　−メモリの解放し忘れによるメモリリークが発生しない。
　−メモリの多重解放による不具合が発生しない。
　−バッファ決めうちによる不具合 (バッファオーバーラン) が発生しない。

【問題点】
C 言語では、文字列バッファを自分で管理しなければならない。

【解決】
C++ 言語では、文字列バッファを自動的に確保・解放するようにできる。


○文字列の直感的な操作

【問題点】
C 言語では、文字列を直感的に操作・記述できない。

【解決】
SophiaFramework では C++ 文字列クラスを用意することで、わかりやすい記法で、直感的に操作できる。

【事例】
たとえば、文字列を連結する場合、BREW だけだと次のように書く必要がある。

　const char* str1 = "ABC";
　const char* str2 = "DEF";
　int len1 = STRLEN(str1);
　int len2 = STRLEN(str2);
　int len3 = len1 + len2;
　char* str3 = MALLOC(len3 + 1);
　STRCPY(str3, str1, len1);
　STRCAT(str3, str2, len3);
　 .... str3 を使用 ....
　FREE(str3); // 使用後に必ず破棄する必要がある

SophiaFramework では + 演算子を使用して、次のように書ける。

　SFUAnsiString str1 = "ABC";
　SFUAnsiString str2 = "DEF";
　SFUAnsiString str3 = str1 + str2;
　 .... str3 を使用 ....
　// 使用後に破棄する必要はない。


◆ANSI 文字列とワイド文字列の変換

BREW にはANSI 文字列とワイド文字列という2種類の文字列があり、状況に応じてお互いに変換する必要があります。

【問題点】
−文字列を自分で変換しなければなければならない。
−変換後の文字列を自分で破棄しなければならない。

【解決】
−SophiaFramework では必要に応じて自動的に変換してくれるので、意識しなくてよい。
−SophiaFramework が文字列バッファの自動管理をしてくれるので、意識しなくてよい。

【事例】
BREW だけを使用したプログラミングの場合、次のようにして変換します。
(1) ANSI 文字列の長さを計算する。
(2) ワイド文字列用のバッファを確保する。
(3) ANSI 文字列をワイド文字列に変換する。
(4) ワイド文字列が不要になったらバッファを破棄する。

　char* astr = "ABC";
　int astrLen = STRLEN(astr);
　int wstrBufSize = sizeof(AECHAR) * (astrLen + 1);
　AECHAR* wstr = MALLOC(astrBufSize);
　STREXPAND((byte*)astr, STRLEN(astr), wstr, strBufSize);
　 .... ワイド文字列 wstr を使用する ....
　FREE(wstr);

実際には、上記コードの煩雑さは関数に分割することで次のように簡単化できます。しかし、それでもメモリの破棄は行わなければなりません。また、変換関数を自分で書かないといけません。

　char* astr = "ABC";
　AECHAE* wstr = AnsiStrToWideStr(astr);
　 ....
　FREE(wstr);

SophiaFramework を使用したプログラミングの場合、次のように書くだけで変換できます。

ANSI文字列を引数にして SFUWideString クラスのオブジェクトを作成する。

char* astr = "ABC";
SFUWideString wstr(astr);
.... ワイド文字列 wstr を使用する ....
.... 変換後の文字列を破棄する必要はない ....


◆文字列操作関数

【問題点】
BREW API に用意されている文字列操作関数はほんのわずかなので、複雑な文字列処理を行う場合、開発者は自分で文字列操作関数を書かなければなりません。

【解決】
SophiaFramework にはあらかじめ豊富な文字列操作関数が用意されているので、開発者は下準備することなく、アプリ独自の創造的な開発に集中することができます。

【事例】
BREW には文字列の置換を行う関数が存在しません。BREW 開発者は置換関数を自分で実装しなければなりません。SophiaFramework を使うと、次のように簡単に置換できます。

　SFUAnsiString str = "I like an apple.";
　str = str.Replace("apple", "ms");


◆日本語の処理

【問題点】
BREW には、日本語 (Shift_JIS 文字コード) 特有の文字列処理を行う関数が用意されていない。

【解決】
SophiaFramework には、Shift_JIS 文字コードを処理するための SFUShiftJIS クラスが用意されている。

【事例】

次の例では。文字列中の全角カタカナを半角カタカナに変換します。

SFUWideString wstr = "シケモク";
SFUShiftJIS::KatakanaToHalf(wstr);

◆シェイプ

【問題点】
BREW では図形の操作を自分で書かなければならない。

【解決】
SophiaFramework では用意されている関数や演算子を使用して、直感的に記述できる。

【事例】
BREW では四角形の移動を次のように記述します。

　AEERect rect;
　rect.x += 10;
　rect.y += 10;

SophiaFramework では四角形の移動を次のように記述できます。

　AFURect rect;
　rect.Offset(10,10);

【事例】
BREW では四角形の上辺を次のように計算します。

　AEERect rect;
　AEELine line;
　line.sx = rect.x;
　line.sy = rect.y;
　line.ex = rect.x + rect.dx - 1;
　line.ey = rect.y + rect.dy - 1;

SophiaFramework では次のように記述できます。

　SFURect rect;
　SFULine line;
　line = rect.LineT();


◆カラー
シェイプと同じ。
色の操作を直感的に行えることがメリット。


◆コレクション

コレクションとは、複数のデータを管理するためのクラスです。
Java の場合、API としてコレクションが用意されていますが、BREW にはコレクションがありません。

【問題点】
開発者は、自分でコレクションを実装しなければならない。

【解決】
SophiaFramework では、あらかじめコレクションが用意されている。

【事例】
BREW で動的配列を実現しようとすると、以下のようなコードになります。

　int* ar = NULL;
　int arSize = 0;
　ar = REALLOC(ar, sizeof(int) * (arSize + 1));
　ar[arSize++] = 100;
　ar = REALLOC(ar, sizeof(int) * (arSize + 1));
　ar[arSize++] = 200;
　ar = REALLOC(ar, sizeof(int) * (arSize + 1));
　ar[arSize++] = 300;
　 .... ar の使用 ....
　FREE(ar); // 使用後に破棄する

SophiaFramework では次のように書くことができます。

　SFUArrayList ar;
　ar.Append(100);
　ar.Append(200);
　ar.Append(300);
　 .... ar の使用 ....
　// 自動的に破棄される。


◆ストリーム

ストリームとは、データの流れを管理するためのクラスです 。
Java では充実したストリーム API が用意されており、使い勝手がよい。

○直感的な記述ができる

【問題点】
BREW では、データの流れを直感的に記述できない。

【解決】
SophiaFramework では、データの流れを直感的に記述できる

SophiaFramework では、データを変換しながら読み取る・書き込むことができる。

【事例】
次の例では、BREW でネットワークから数値を読み取っています。

　ISocket* sock;
　int number;
　ISOCKET_Read(sock, &number, sizeof(number));
　number = NTOHL(number);

SophiaFramework では次のように記述することができます。

　SFUNetwrokStream net;
　int number;
　net >> endianbig >> number;


○メモリ ストリーム (SFUMemoryStream)

メモリストリームは、自動拡張するバッファです。メモリストリームは、プログラミングでよく使われる基本的な道具のひとつです。Java には API として最初から用意されています。

【問題点】
BREW にもメモリストリームのようなものはありますが、メモリの読み取りしかできず、書き込みを行うことができない。

【解決】
SophiaFramework にはメモリストリームが用意されており、メモリの読み取りと書き込みを行うことができ、メモリの自動拡張をサポートしています

【事例】
SophiaFramework で整数と文字列をメモリに格納するコードを以下に示します。BREW では多くのコードを書く必要があります。

　SFUMemoryStream mem;
　mem.Open(100);
　mem << 100;
　mem << 200;
　mem << "ABC" << AChar(0);

　SInt32 data1, data2;
　SFUAnsiString str;
　mem >> data1; // data1 = 100 となります
　mem >> data2; // data2 = 200 となります
　mem >> str; // str = "ABC" となります


○ファイル ストリーム (SFUFileStream)
ファイル ストリームは、ファイルへの入出力をストリームとして管理するクラスです。

【問題点】
BREW のファイル インターフェイスは、バッファリングをサポートしておらず、頻繁にファイルアクセスを行うと、目立った速度低下が発生する。

【解決】
BREW のファイル インターフェイスをカプセル化した SophiaFramework のファイル ストリームでは、内部的にバッファリングを行っているので、高速なファイル アクセスが可能。また、開発者はバッファリングについて特に意識する必要がない。


○ネットワーク ストリーム (SFUNetworkStream)
ネットワーク ストリームは、TCP/IP 通信をストリームとして管理するクラスです。
Java のネットワーク ストリーム (HTTP ストリーム) は、同期的にデータを受信することができるため、プログラミングは簡単にできますが、BREW では非同期的にデータを受信するため、処理が複雑になります。

【問題点】
BREW の ISocket インターフェイスは、非同期通信を行うために、受信データがばらばらのデータ片として受信されることになり、受信データの処理が煩雑になる。

【解決】
SophiaFramework では、ネットワークから取得したデータ片をバッファリングすることで、受信データをストリームとして扱いやすくなっている。


◆ネットワーク クラス

○名前解決クラス (SFUHostResolver)

【問題点】
BREW で名前解決を行う場合、非同期関数を使用する必要があるため、それに関わる状態変数をたくさん管理しなければなくなります。

【解決】
SophiaFramework では、名前解決に関わる状態変数を１つのクラスにカプセル化しているため、管理が簡単になり、保守性が高くなる。


○HTTP クラス (SFUHttpConnection)

SophiaFramework を使う利点は、名前解決クラスと同じです。
ネットワーク関係の関数は、非同期関数であることが、難しさの根本原因になっています。

◆数値計算

○浮動小数点数クラス (SFUDouble)

【問題点】
−BREW では、浮動小数点数を演算子によって計算できず、すべて関数呼び出しの形式で記述しなければならないため、可読性が低いソースコードになる。
−BREW では浮動小数点数の演算の種類が少ない。三角関数や指数関数の演算ができない。

【解決】
−SophiaFramework では、BREW の浮動小数点数型 (double 型) を、C++ クラスとしてラップすることで、演算子による自然な記法で計算を行うことができる。

−SophiaFramework では、三角関数や指数関数の演算もサポートしている。

【事例】
BREW では、たとえば、(x + y) * z を計算するには、次のように記述する必要があります。

　double x, y, z;
　z = FMUL(FADD(x, y), z);

SophiaFramework では、次のように記述することができます。

　SFUDouble x, y, z;
　z = (x + y) * z;


○乱数クラス (SFURandom)

【問題点】
BREW にはシードがある乱数を生成できない。

【解決】
SophiaFramework には乱数クラスがある。乱数クラスの実装は簡単なことであるが、最初から用意されているのが利点。


◆その他のユーティリティ

○日付クラス (SFUDateTime)

【問題点】
BREW の API には、日付操作関数がわずかしかない。

【解決】
SophiaFramework では、日付操作関数が豊富に用意されており、すぐに使える。


○ヘルパー関数クラス (SFUHelper)

【問題点】
BREW 開発を行う上で、BREW ヘルパー関数を使用することは必須であるが、BREW の構造上、ヘルパー関数の呼び出しはプログラム サイズを肥大化させる。

【解決】
SophiaFramework では、ヘルパー関数を呼び出してもプログラム サイズが肥大化しないような仕組みを用意している。

【事例】
BREW でメモリ確保を行う場合、MALOC() 関数を使う。次のコードは、コンパイルされると28 byte 必要とする。

　void* buffer = MALLOC(256);

SophiaFramework では、次のようなコードを書くが、これをコンパイルすると 8byte しか必要とせず、20 byte の節約になる。

　void* buffer = SFUHelper::malloc(256);


○設定保存クラス (SFUConfig)

【問題点】
BREW アプリを作る場合、ユーザーの設定を保存したり読み取る機能が必要なことが多々あるが、BREW にはそのための API が用意されておらず、自分で作る必要がある。

【解決】
SophiaFramework には、設定の保存・読み取りを行うためのクラスがあらかじめ用意されている。Windows の INI ファイルを読み書きする関数と似ているため、使いやすい。


○グラフィック描画クラス (SFUGraphics)

【問題点】
BREW では、IDisplay と IGraphics という 2 つの描画インターフェイスが用意されているが、一般的な BREW アプリではその両方を使う必要があり、その 2 つを同時に管理する必要がある。

【解決】
SophiaFramework では、BREW の 2 つのインターフェイスを１つのクラスとしてまとめることで、管理が楽になっている。
その他いろいろ使いやすくなっている。たとえば、BREW API では複数の関数を使用して実現しなければならない描画を、SF では関数呼び出し1つで実現してくれる。

【事例】
四角形の中に文字列を折り返して描画したい場合、BREW だけだとそのような関数を自分で作らなければならない。SophiaFramework には、これを行うためのSFUGraphics::DrawString() 関数が用意されており、開発者はこれを呼び出すだけでよい。


◆GUI

○GUI 環境の提供

【問題点】
BREW には、Windows のような GUI 環境がない。

【解決】
SophiaFramework では、GUI 環境を提供しており、簡単なプログラムで GUI を実現できる。


○イベント処理のカプセル化

【問題点】
BREW で無理やり GUI を作成し、イベントのハンドリングを行うと、イベント内容に応じて処理を分岐するプログラムを書かなければいけない。このような構造のプログラムは、保守性が悪く、UI の追加や削除なども行いにくい。

【解決】
SophiaFramework では、イベントはあらかじめ登録したハンドラが受け取る。イベント内容に応じた分岐を記述しなくてよく、また、他のイベントとの影響などを考えなくてよいので、保守性が向上し、UI 部品の追加や削除も容易におこなえる。


○GUI 部品の提供

【問題点】
開発者は GUI 部品を自分で作らなければならない。

【解決】
SophiaFramework では、ウィンドウ、メニュー、ダイアアログ、各種コントロールなどの標準的な GUI 部品を提供している。

【事例】
SophiaFramework では、次のような簡単なコードで、ボタンを乗せたウィンドウを表示できる。

SFRFrameWindow* win = new SFRWindow(this, rect);
SFRButtonControl* button = new SFRButtonControl(win, rect2, "ボタン");


○高機能な GUI 環境

【問題点】
BREW で独自に GUI 環境を構築することは骨の折れる仕事である。

【解決】
SophiaFramework の GUI 環境は、以下のようなさまざまな機能をサポートしている。

　−フォーカス、可視状態、有効無効などの状態の管理や、親の状態の継承の管理
　−自動的なフォーカス移動
　−レスポンダの移動やスクロール、仮想領域のサポート
　−描画領域の自動計算
　−効率的な描画処理


◆デバッグ

SophiaFramework には、デバッグを支援するための仕組みが組み込まれています。


○メモリリーク検出

【問題点】
BREW にもメモリリーク検出機能が備わっていますが、その機構は C++ と相性が悪く、C++ のソースコードで発生したメモリリークを十分に検出できない。

【解決】
SophiaFramework で用意されているメモリリーク検出機能は、C++ で書かれたソースコードのどこでリークが発生したかを突き止めることができ、デバッグの生産性を確実に向上させる。


]]> http://sophiacradle.noblog.net/blog/a/10025225.html SophiaFramework とは、QUALCOMM 社 のBREWプラットフォーム上でのアプレットの開発をより簡単に、より効率的に行えるように開発された C++ 言語用のアプリケーションフレームワークです。また SophiaFramework は、アプリケーションフレームワークとしての... 2004-12-30T21:38:59+09:00

SophiaFramework とは、QUALCOMM 社 のBREWプラットフォーム上でのアプレットの開発をより簡単に、より効率的に行えるように開発された C++ 言語用のアプリケーションフレームワークです。また SophiaFramework は、アプリケーションフレームワークとしての機能だけではなく、様々な、拡張可能な GUI オブジェクトやデータを処理するためのクラス群などライブラリとしての機能も併せ持っています。
SophiaFramework を使用してアプレットの開発を行うと、BREW 標準の開発方法で行った場合と比較して、約 300 ％以上もの作業の効率化を実現できます。アプレットを量産したり、短期間の開発スケジュールで作業を行わなければならないときに威力を発揮します。

BREW 標準の C 言語を用いたアプレット開発方式では、イベントの処理は条件判定の羅列になり、また文字列処理は伝統的な作業用バッファを使用したスタイルになります。さらに BREW API のインターフェースオブジェクトの管理はプログラマ側に任されているので、オブジェクトの解放のタイミングまで管理する必要があり大変です。このような環境はゲームのような速度を要求される、ある程度規模の小さなアプレットの場合は適しているのですが、ビジネス向けのアプレットや情報配信ツールなど規模の大きいアプレットには適していません。

なにより、本題であるアプレット固有のデータ処理に入る前に、もっと低レベルな処理でのバグ潰しに労力の大半を裂きかねません。このような状況を改善するために SophiaFramework を使用した開発では BREW 標準の開発に比べて以下の点で利点があります。

◆インターフェイス管理：BREW API は、ほとんどすべてがインターフェイスオブジェクトにより提供されています。インターフェイスオブジェクトはそのライフサイクルを制御するために、必要に応じて参照カウンタの増加と減少を行わなければなりません。この参照カウンタの管理を適切に管理しないと、メモリリークという携帯プラットフォームにとって最も好ましくないバグが発生します。SophiaFramework を使えば、BREW API のすべてのインターフェイスに対する C++ ラッパークラスと、参照カウンタを管理するスマートポインタが用意されますので、より直感的な API 呼び出しと参照カウンタの自動的な管理が実現されます。

◆イベントハンドラ：BREW 標準のイベントハンドリング機構では、アプリケーションが大きくなるにしたがってイベントハンドラが複雑になり、見通しが悪く保守性の低いソースコードになりがちです。イベントハンドラの複雑化は、多くの UI コンポーネントを利用するアプリケーションで顕著に現れてきます。SophiaFramework は、C 言語スタイルの複雑なイベントハンドラの代わりに、C++ 言語のオブジェクト指向を用いたシンプルなイベントハンドラを使用します。オブジェクト指向を利用したイベントハンドラを使用することにより、ソースコードは見通しがよく保守性の高いものになり、高度で複雑な UI 機能を持ったアプレットも迅速に開発することができるようになります。

◆文字列：BREW 標準の API は C 言語だけを使用しており、文字列の扱いにはポインタを直接扱わなければなりません。ポインタの操作はバグが混入しやすく、プログラマにとって大きな負担となります。これに加えて、BREW には ANSI 文字型とワイド文字型という 2 種類の文字型があり、相互の変換を行わなければならない状況が多くあります。SophiaFramework には、ANSI 文字列とワイド文字列を扱う２種類の文字列クラスがあり、文字列操作や文字型の変換を簡単な構文で実現することができます。

◆コレクション：BREW 標準の環境にはデータをまとめて管理するコレクションクラスが全く存在しません。これは、高レベルな機能の多いアプレットを開発する際には非常に大きな障壁となります。SophiaFramework では、いくつかのコレクションクラスを用意することでデータ管理を行いやすくなっています。

◆ストリーム：BREW のストリーム入出力では、ノンブロッキングモデルが採用されています。C 言語でノンブロッキングモデルの入出力を制御するためには、バッファ管理などのさまざまな煩雑さがともないます。SophiaFramework では、これらの煩雑な処理は C++ クラスの中に実装されているので、プログラマは容易にストリーム入出力を使用することができます。BREW の強力なネットワーク機能を用いたアプリケーションを簡単に作成することが可能となります。

また、BREW 標準の API でデザインの凝った画面遷移の複雑な UI を作成しようとすると、描画タイミングの管理やデザインをコーディングで表現するのは大変な作業です。このような要求にも SophiaFramework は以下のような点で対応しています。

◎柔軟で見栄えのよい UI：BREW 標準の UI コンポーネントはマルチウィンドウを考慮しておらず、プログラマが拡張することが困難であり、デザインもあまり優れているとはいえません。SophiaFramework を使えば、洗練されたデザインをもつ UI コンポーネントを簡単に開発することができ、振る舞いを思い通りにカスタマイズできます。また SophiaFramework で開発された UI コンポーネントは、自動的にマルチウィンドウ対応となります。

◎描画操作：BREW 標準の描画環境では文字列や簡単な図形を描くには IDisplay インターフェースを使用し、多角形や複雑な図形を描くときには IGraphics インターフェースを使用しなければなりません。２つのインターフェースが分かれていることは利点もあるのですが、ほとんどのアプレットの場合は、簡単な操作のためでさえ２つのインターフェースを使いこなさなければならず不便です。例えば、色の設定やオフセットの設定をそれぞれのインターフェースに対して行わないと、文字と図形の整合性が取れなくなります。SophiaFramework では、IDisplay インターフェースと IGraphics インターフェースを抽象化した描画クラスが存在しますので、描画操作をより簡単に素直に行うことが可能となります。

◎図形や色の演算：BREW 標準環境は C 言語スタイルの環境のため、図形や色の演算は直接構造体のメンバを演算しなければなりません。このような作業は比較的頻繁に発生し、またバグの温床にもなりかねません。SophiaFramework を使用すると、図形クラスや色クラスを使用することで簡潔で素直な図形や色の演算を行うことが可能となります。

以上のように、SophiaFramework と C++ 言語を用いて開発を行うことにより、開発期間の短縮とリソースの再利用、またアプレットの保守にかかるコストを大幅に削減することが可能となります。


]]> http://sophiacradle.noblog.net/blog/a/10025227.html ◆ C 言語に起因する諸問題の解決 【問題点】BREW では C 言語を使うため、C 言語に起因するさまざまな問題が発生する。 【解決】SophiaFramework では、C++ 言語をベースにしたライブラリを提供することで、C 言語に起因するさまざまな問題を解決する。 【... 2004-12-30T21:38:59+09:00
【問題点】BREW では C 言語を使うため、C 言語に起因するさまざまな問題が発生する。

【解決】SophiaFramework では、C++ 言語をベースにしたライブラリを提供することで、C 言語に起因するさまざまな問題を解決する。

【補足】C++ 言語で開発すると、C++ はオブジェクト指向言語であるため、C 言語よりも機能をコンポーネント化しやすく、ソースコードの再利用性の向上や、保守性の向上といった利点が得られる。

◆C++ プログラミングのインフラの提供

【問題点】
−BREW で C++ 言語を使おうとすると、デバッグ環境の実装や、BREW インターフェイスのラッパークラスなどの下準備が必要になってくる。
−ARM コンパイラや Visual C++ コンパイラの特性により、C++ 言語にまつわる罠がいくつか存在する。

【解決】
−SophiaFramework では十分な C++ インフラが用意されているので、プログラマは C++ 言語ですぐに開発をはじめることができる。
−ARM コンパイラや Visual C++ コンパイラの特性を熟知した上で C++ のインフラを整備しているため、開発者はコンパイラに起因する不具合に悩む必要がない。

【事例】
−new/delete 演算子の定義や、メモリリーク検出機能の提供。
−VC コンパイラの不具合により、C++ テンプレートが正しく動作しないことへの対処。
−ARM コンパイラの不具合により、クラス内構造体へのアクセスが正しく動作しない場合への対処。
−ARM コンパイラは、C++ 型キャスト関数を十分にサポートしていないため、SophiaFramework では特殊な型キャスト関数を提供している。

◆基本ライブラリの提供

【問題点】
−BREW の開発環境には十分なライブラリが存在していないため、BREW アプリを開発しようとすると、アプリ固有のロジックを組む前に基本的なライブラリを一から作らなければならない。
−そのようにして作られたライブラリは、テストが十分に行われていなかったり、仕様が十分に定義されていなかったり、ドキュメント化されていないことが多く、そこから生まれる不具合や生産性の低下を無視することはできない。

【解決】
−SophiaFramework では、一般的に必要とされる十分なライブラリを用意することで、BREW 開発者がアプリ独自のロジックに集中できるような環境を提供する。
−SophiaFramework の基本ライブラリは徹底してテストされているため、開発者は安心して使用することができる。また、仕様が完全に定義され、ドキュメント化されている。

◆BREW を熟知した所から生まれる最適なライブラリ設計

【問題点】
−BREW を十分に熟知していないままライブラリを設計すると、あとで開発の手戻りが発生したり、解決できない不具合に悩まされることになる。
−BREW は C 言語で開発するが、ARM プロセッサの特性を知らずにライブラリを設計すると、プログラムサイズが肥大化したり、十分な実行速度が得られなくなる。

【解決】
−BREW について熟知した上で設計されているので、開発者は安心して BREW 開発ができる。
−ARM プロセッサの特性を考慮した設計になっている (現状では実行速度よりもサイズを小さくすることに重点を置いている)。

【事例】
−BREW の IDBRecord インターフェイスは、ドキュメント化されていない特殊な振る舞いをするため、そのままラッパー クラスを実装すると不具合が発生する。SophiaFramework では、IDRecord の内部動作に合わせた設計をしており、不具合が発生することはない。
−BREW ヘルパー関数をそのまま使用するとアプリサイズが肥大化するが、SophiaFramework では肥大化させないための関数を提供している。
−関数の定義では、コードサイズが小さくなるように実装されている。


]]> http://sophiacradle.noblog.net/blog/a/10025224.html 　SophiaFramework とは、QUALCOMM 社 BREW 搭載携帯電話向けに「モバイル端末向けマルチウィンドウシステム」を携帯電話業界で初めて実現したアプリケーションフレームワークと各種ソフトウェアライブラリから構成されます。 　QVGA端末の急速な普及、ＡＲＭ... 2004-12-30T21:37:59+09:00 SophiaFramework とは、QUALCOMM 社 BREW 搭載携帯電話向けに「モバイル端末向けマルチウィンドウシステム」を携帯電話業界で初めて実現したアプリケーションフレームワークと各種ソフトウェアライブラリから構成されます。

　QVGA端末の急速な普及、ＡＲＭ９などによる携帯電話向けチップの高速化の進展、プログラムメモリやデータメモリの急速な増大などに伴い、今後はますます、パソコンでいえば、WindowsやMacに代表されるような、使い易いマルチウィンドウシステムが、携帯電話利用者から当然のように求められるであろうと考えて開発されたのが SophiaFramework です。

　使い易いマルチウィンドウシステムのアプリケーションを開発するためには、複雑で難解なイベント処理や描画処理をプログラミングする必要があります。この処理全てをアプリケーションプログラマに負担するのはどう考えても現実的ではありません。このような処理は普遍的で汎用的な処理でもあるので、 SophiaFramework にブラックボックス化することにより、実際は非常に高度なプログラミングスキルが要求されるものであるにもかかわらず、普通レベルのアプリケーションプログラマでも、使い易いマルチウィンドウのユーザーインターフェースを持つ携帯アプリを楽々と実現できるようにしました。

　その他、SophiaFramework にはC++による完璧なオブジェクト指向プログラミングを可能とする各種ラッパー群や文字列処理やストリーム、コレクション、描画処理など、あらゆる携帯アプリに必要なライブラリ群が標準で用意されています。

　将来的な展望として、現在、SophiaFramework はBREW 上でのみ実装されていますが、アーキテクチャ上、プラットフォームに依存する部分と依存しない部分を明確に分離して開発されていますので、SymbianOS、携帯LinuxOS、TronOSなど、今後有力視される他の次世代携帯電話向けOSにもスムーズに移行させることが可能です。この仕組みにより、SophiaFramework をマルチプラットフォーム化するだけで、BREW 上の携帯アプリをオートマティックにSymbianOS、携帯LinuxOSなどへマルチプラットフォーム化するようなことも可能となるのです。


]]> http://sophiacradle.noblog.net/blog/f/10024554.html SophiaCompress(BREW) enables the compression of compiled Binary Runtime Environment for Wireless (BREW) applications at a rate of 60-75%. It has three advantages that are indispensable to differentiate your product to other competing compan... 2004-12-27T12:45:59+09:00
-Reduce an end-user's packet communication expensense by one-third
-Triple the number of applications that are saved in a handset
-Enables distribution of multi-functional applications

Half Communication Expenses

Currently, the price of most official KDDI BREW application (EZ-appli) content is 100 or 200 yen each, and the size of each BREW application is about 300 kilobytes. When a user downloads one application, he/she has to pay 618 yen of communication cost itself. Since the size of a BREW application increases year by year, it is inevitable for content providers to solve such size limitation to provide a better application.

SophiaCompress(BREW) enables a 60-75% compression rate, which gives a simple calculation as an example: an uncompressed 300 kilobyte application becomes 100 kilobytes after compression. This means, the communication expense for that application is reduced to 216 yen from 648 yen. Such great economical advantages of using SophiaCompress(BREW) therefore puts you one step ahead of other companies. (Assuming a communication fee of 0.27 yen per 128 bytes; 1 kilobyte = 1024 bytes)

Doubled Applications in a Handset

The user advantage of small sized application is not only at the time of downloading. Storing in the form of a compressed file half the size of the original allows storage of triple the number of BREW applications in a handset. For example, memory space used for four uncompressed applications is equivalent to the memory space used for eight compressed applications. Therefore, minimizing application size is crucial for the effective use of limited memory.

Develop a Mobile Application as Sophisticated as TV Games

A 900 kilobyte application can be compressed to 300 kilobytes by SophiaCompress(BREW). This means a much higher quality of application that could not have been realized in 300 kilobytes is possible. SophiaCompress(BREW) will even enable transplantation of Nintendo's Super Family Computer software to a mobile phone. As goal size can be set as 900 kilobytes from the former 300 kilobytes, the then software will be used more practically than before.

Easy Handling with GUI

SophiaCompress(BREW) interface is graphical and does not require any complicated work. You can compress a program just by one click. No problem even if your company does not have BREW development system.

How SophiaCompress(BREW) Works

1.An ARM compiler compiles a program written in C or C++ so that it can be used with handsets. The result is an execution format ".mod" which is then compressed by SophiaCompress(BREW).

2.The BREW application in the execution format is distributed through the Internet. Up to this point is done by the developer.

3.A user then downloads a compressed BREW application to a handset and saves it into its memory.

4.The compressed BREW application is finally restored and then functions as an application.

]]> http://sophiacradle.noblog.net/blog/f/10024538.html SophiaCompress(BREW)とは SophiaCompress(BREW) はコンパイル後の BREW アプリを 60-75 ％圧縮することができます。これは他社との差別化を図る上でカギとなる三つのメリットを実現させます。 利用者のパケット通信料が３分の１に ケータイに保存できる... 2004-12-27T12:33:59+09:00 SophiaCompress(BREW)とは

SophiaCompress(BREW) はコンパイル後の BREW アプリを 60-75 ％圧縮することができます。これは他社との差別化を図る上でカギとなる三つのメリットを実現させます。

利用者のパケット通信料が３分の１に

ケータイに保存できるアプリ数が３倍に

高機能アプリの配信が可能

通信料半減

現在、KDDI の公式EZアプリ(BREW) のダウンロード単位で課金しているコンテンツの価格の多くは、1 ダウンロード当たり 100 円もしくは 200 円です。もし利用者が仮に 300KB の EZアプリ(BREW) をダウンロードするとなると、通信料金のみで 618 円もの費用を負担させてしまうことになります。 EZ アプリ(BREW) のサイズは年々巨大化していくだけに、サイズ問題に対する解決策へのニーズは極めて高くなっています。

「SophiaCompress(BREW)」は現在、60-75％程度の圧縮率を誇っているので、300KB のEZアプリ(BREW)を圧縮すればサイズが100KB となります。通信料金は１回のダウンロード当たり、従来 618 円であったものが 216 円に削減されます。価格面において利用者に大幅なメリットを与えるので、「SophiaCompress(BREW)」を利用するコンテンツプロバイダは競合他社に対して優位に立つことができます。
(通信料金：128バイト当たり0.27円と仮定して計算。1KB ＝1024バイト)

SophiaCompress(BREW) 動作原理

C、C++ などで書かれたプログラムを、専用の ARMコンパイラで実機用にコンパイルします。実行形式の .mod ファイルができるので、これを SophiaCompress(BREW) で圧縮します。
実行形式のまま、60-75% のサイズに圧縮された BREW アプリができ、これを配信します。
ここまでが開発側で行われる事柄です。
ユーザー側では、まずケータイに圧縮された BREW アプリをダウンロードしてメモリーに格納します。
圧縮された BREW アプリは、SophiaCompress(BREW) により、実行時に復元されて機能します。


アプリ数倍増

ユーザーにとってアプリのサイズが小さいことのメリットは、ダウンロードの時だけではありません。携帯電話に３分の１の大きさに圧縮した形式で保存するので、利用者は携帯電話にダウンロードして保存できるBREWアプリの数が３倍になります。
例えば、圧縮していない２０個のアプリを保存するメモリースペースがあれば、SophiaCompress(BREW) で圧縮したアプリを６０個保存することができるのです。ケータイの限られたメモリーの有効利用を考えるとき、アプリサイズが小さいことをユーザーは大いに歓迎するでしょう。

ゲーム専用機アプリまで

900KB のEZアプリ (BREW) も SophiaCompress(BREW) で圧縮することにより、300KB というサイズ内に収められます。 300KB のサイズでは提供し得なかったワンランク上のEZアプリ (BREW) も不可能ではありません。 SophiaCompress(BREW) を使うことにより、コンテンツプロバイダは競合他社に対して、機能面に大きな付加価値を与えることによる差別化が可能となります。

また、スーパーファミコンのソフトをケータイアプリに移植するようなケースでも SophiaCompress(BREW) は威力を発揮するでしょう。サイズ削減の目標値を従来の 300KB から、圧縮を念頭においた 900KB にまで緩めることができるため、当時のソフトをより魅力的に再現することができます。

GUI インターフェイスで操作が容易

GUI のインターフェースで、ボタンを一つ押すだけで容易に圧縮操作ができます。自社に BREW アプリの開発体制のないコンテンツプロバイダでも利用可能です。

]]> http://sophiacradle.noblog.net/blog/a/10024536.html Sophia Cradle developed SophiaFramework, an application framework for C++ programming language, to make the development of applets that run on QUALCOMM's BREW platform more efficient. SophiaFramework is not simply a framework, but it is als... 2004-12-27T12:27:59+09:00
With SophiaFramework you can improve your development productivity by 300 per cent compared to standard BREW development method. SophiaFramework is therefore most useful when you need to mass-produce applets or develop in a short period of time.

When you want to process events in C programming language, you will have to enumerate conditions and use traditional working method with buffers. Moreover, you will need to take care of releasing objects because management of objects in BREW APIs is left to programmer. This kind of developmental environment is good when making small applets which require speed, like games, but not when making large-scale applets such as those of business purposes or information distribution. In such case, it is time-consuming because the first thing you need to do before processing data of the applet is to fix bugs at a lower level. On the other hand, SophiaFramework gives benefits to development of BREW applications, much more than the standard development method. It provides the following features.

1.Interface Management

Most BREW APIs are offered in the form of interface objects, and object's lifecycle is controlled by incrementing and decrementing a reference counter. Inadequate object management will lead to a memory leak, which is a crucial bug on mobile phone platform. As a solution, SophiaFramework equips with C++ wrapper classes for all BREW APIs and smart pointers that control the reference counters making instant calls for APIs and automatic management of objects.

2.Event Handling

Event handling mechanism of the standard BREW tends to be complex and the source codes become difficult to be maintained as the size of an application gets bigger. Complexity of event handlers is common in most applications that use user interface components. SophiaFramework uses simple object-oriented event handlers so that the source codes are easily read and highly maintained. It therefore helps a programmer to develop applets that have high-level and complicated user interface functions.

3.Strings

When using string with standard BREW APIs which is written only in C programming language, you need to handle pointers direcly. Handling pointers can cause problems of bugs putting a heavy burden for a programmer. In addition, there are two types of characters for BREW - ANSI and AECHAR, and an engineer often needs to convert them in BREW programming. SophiaFramework offers string classes for each character type so that a programmer can handle strings and convert the character type easily with a simple construction.

4.Collections

There is no collection class in BREW SDK, which makes a huge barrier to an engineer to develop a high-functioning applet. SophiaFramework enables easier data management by providing a number of collection classes.

5.Streams

BREW stream input and output uses non-blocking model. Controlling input and output of non-blocking model in C programming language requires many complicated procedures such as buffer management. SophiaFramework solves the problem because these complicated procedures are implemented on its C++ classes, therefore an engineer can easily use stream input and output to make an application that has strong network function of BREW.

In addition, it is no easy matter to encode drawing timing and design to make user interface (UI) that has active and elaborate design, with the standard BREW APIs. SophiaFramework will help you in such case as explained in the following.

1.Flexible and Good-looking UI:

Engineers find it difficult to extend the standard BREW components because APIs themselves have no multi-window support. The design is not attractive enough either. However, with SophiaFramework, an engineer can easily use well-designed UI components and customize actions as he wants. Moreover, UI components that are developed with SophiaFramework automatically have multi-window support.

2.Graphics Operation:

The standard BREW APIs include two drawing interfaces - IDisplay for drawing strings or simple graphics and IGraphics for drawing polygons or complex graphics. There are advantages of having separate interfaces, but for most applets it is not so useful because you need to go through a number of processes even to make a simple operation. For example, you need to set colors and offsets for each interface to adjust text and image. SophiaFramework offers a drawing class which is an abstraction of IDisplay and IGraphics making it easy to operate graphics.

3.Graphics and Colors Calculations:

Since the standard BREW programming is based on C programming language, operating graphics and colors requires you to calculate member variables of the structures. These operations are common and can become a hotbed of bugs. Therefore, SophiaFramework provides graphics class and color class that help an engineer to calculate easily and correctly.
In conclusion, adoption of SophiaFramework and C++ in the development substantially saves time, resource and cost of maintaining applets.

We offer SophiaFramework Application Wizard for easier development of applets with SophiaFramework.

]]> http://sophiacradle.noblog.net/blog/a/10024535.html What is SophiaFramework? The functions of next generation mobile phone application have increased in variety, to now incorporate such capabilities as music distribution, financial transaction and remote control. These advances will continu... 2004-12-27T12:22:59+09:00 What is SophiaFramework?

The functions of next generation mobile phone application have increased in variety, to now incorporate such capabilities as music distribution, financial transaction and remote control. These advances will continue into the future and in this situation, the importance of application "architecture" will be of increasing significance. BREW is an opening key to the advancing mobile phone industry.

Sophia Cradle's Revolutionary Technology
- The Next Generation of Mobile Applications

As the quality of mobile phone hardware improves, its application size and the development cost increases significantly. For a mobile application developer, it is impossible to make progress unless the existing approach and methodology are changed.

Within the international standardization of a mobile phone application platform, a key factor for the developer to survive in the industry would only be to improve the quality of planning, development technology and service management know-hows. SophiaFramework includes all software libraries that would be needed to make such an improvement. For example, it contains a graphical user interface (GUI) library which would be the most important user interface for mobile phone applications, and other high quality libraries that can be recycled. Only by using SophiaFramework would it be possible to create globally standard mobile applications.

A Hint from the Ford System

When assembling car parts, Henry Ford changed his strategy from "how to allot workers to each operation" to "how to allot operations to each worker," and as a result, an effective method of operations enabled a reasonable price of cars which had previously been too expensive for most people. We applied his idea to the mobile phone application development industry in the hope of making mobile applications more affordable.

Currently, most application developers have done all of the development processes by themselves. This approach is easy if the application size is as small as a few hundred thousand kilobytes. However, now that the average mobile phone application size has increased to more than a million kilobytes, the project is doomed for failure because it costs too much to develop the application. As a solution to this cost problem, SophiaFramework will aim towards maximum quality of mobile applications by clearly defining the archtecture of the application and then distinguishing what needs to be developed from what needs to be bought from other developers.

Characteristics of SophiaFramework

SophiaFramework consists of a variety of software libraries and an application framework that enables "multi-window system for BREW mobile terminals." It is the first of its kind that has been developed in the mobile phone industry.

We developed SophiaFramework due to the demand for an easy multi-window system among mobile phone users that would correspond to Windows or Macintosh operating systems (OS). With the rapid spread of Quarter Video Graphics Array (QVGA) terminals, a need for the development of high-speed mobile phone chips by ARM9 and significant increases in program memory and data memory became apparent.

In order to develop an easy multi-window system application, first programs that handle complicated events and drawing processes are needed. However, it would be too much for a software engineer to complete this entire programming. Since these programs involve universal processes, SophiaFramework allows a standard-level programmer to easily develop mobile phone applications with multi-window interface by making the complicated basic programs a black box.

SophiaFramework also includes a variety of libraries that would be needed for the development of mobile phone applications, such as string processing, stream, collection, drawing and different types of wrappers that enable a perfect object-oriented programming by C++. Currently, SophiaFramework is only available for BREW, but in future, it will also be available for other platforms like Symbian OS, Mobile Linux OS and Tron OS. It is possible because SophiaFramework's architecture is separated into the processes that depend on the platform and those that do not.

The Architecture of SophiaFramework

As software increases in size and complexity, an integrated development approach -- namely a software development method based on an architecture that separates each process according to its content or character -- is of vital importance.

In the near future, BREW mobile phone application development will also require a development method based on architecture, otherwise it would fail at a certain stage of development.

SophiaFramework provides an architecture that optimizes the development of BREW application itself. A developer simply has to follow this architecture to make a high-level application which fits the requirement of the next generation mobile applications, with low cost in a short period of time.

The architecture of SophiaFramework is divided into three main layers. The bottom layer is the C++ wrapper layer, which enables a perfect object-oriented programming. It includes all C++ wrappers for each BREW API. The middle layer is the utility layer, which is made up of different types of libraries that would be necessary in developing most mobile applications, such as string processing, stream, collection and drawing. The top layer is the Graphical User Interface (GUI) framework layer. GUI framework layer allows black-box processing of a variety of complicated events and drawing that would be required in the running of multi-window mobile applications. The basic way of development is, using the GUI framework which corresponds to building material as a base, to combine lower layer APIs from the C++ wrapper layer and the utility layer that correspond to a saw or a hammer. Using these lower layers, it is possible to make new parts that can be recycled. Another advantage of using SophiaFramework is that your original reusable libraries accumulate as you use it, making development itself more effective.

]]> http://sophiacradle.noblog.net/blog/a/10024534.html SophiaFramework とは 音楽配信、金融決済、遠隔制御等々、次世代携帯電話向けアプリケーションは複雑多岐に渡り、かつ大規模化していくでしょう。このような状況において、人々に「感動」を与えるほどにクオリティの高いアプリケーションを提供するためには... 2004-12-27T12:13:59+09:00 SophiaFramework とは

音楽配信、金融決済、遠隔制御等々、次世代携帯電話向けアプリケーションは複雑多岐に渡り、かつ大規模化していくでしょう。このような状況において、人々に「感動」を与えるほどにクオリティの高いアプリケーションを提供するためには、必然的に『アーキテクチャ（基本設計）』というものの重要性がクローズアップされることとなるでしょう。先ずは BREW によって、この世界の扉が開かれようとしています。

新兵器革命　-　次世代アプリを全世界へ

携帯電話機ハードウェアの高度化に伴い、それを制御する携帯アプリのサイズは増大の一途を辿り、その開発費用は桁違いに高騰しつつあります。そのため、携帯アプリ開発会社は従来のアプローチや方法論のままで開発していたのではもはや収益拡大を望めません。

BREW のように携帯アプリのプラットフォームが全世界的に共通化される環境下において、携帯アプリ開発会社が存続し、発展するためのキーとなるのは、企画、開発技術、サービス運営ノウハウなど、あらゆる面においてのQualityを極大化した超一流の携帯アプリを企画、開発し、全世界に流通させ、サービス提供することによってのみ、これまでとは一桁違う収益構造を確立できるという考え方です。 SophiaFramework では、携帯アプリで最も重要となるであろうユーザーインターフェーズに 関する究極の GUI ライブラリを始めとして、再利用可能な数々の高品質なソフトウェアライブラリがラインナップされています。 SophiaFramework をご利用いただくことによって初めて世界に通用する携帯アプリが実現可能となるでしょう。

T 型フォードから得られるヒントとは

これまで、ほとんどの携帯アプリ開発会社は携帯アプリをゼロから自前で全てのプログラムを開発してきました。携帯アプリのサイズが数十キロバイト程度の小さなものであれば、このアプローチも通用しましたが、携帯アプリのサイズが数百キロバイト以上になってくるとこのやり方も破綻してしまいます。何故なら、例えば、サイズが10倍大きくなり、開発費用が10倍になったからといって、その携帯アプリの利用者に10倍の金額を代金として頂くことはあり得ない話だからです。これを解決するための手段としては、携帯アプリのサイズが大きくなっても開発コストが増大しないような開発アプローチを採ったり、開発した携帯アプリを日本国内だけでなく、海外にも輸出したりして、新たなる利用者の獲得というような考えが必須となってきます。

自動車王ヘンリー・フォードは自動車を組み立てる際に、従来、「従業員をどう動かして作業に割り当てればいいか」と考えていたのを、「作業をどう動かして従業員に割り当てればいいか」と発想を変えました。それによって、極めて効率の良い組み立てラインが生まれ、一般大衆でも以前は高価な乗り物であった自動車に乗れる時代が切り拓かれました。このヘンリー・フォードのT 型フォードの発想の転換を携帯アプリ開発にも適用し、高品質な携帯アプリを安価に世界中に流通させるべき時が来ています。携帯アプリを開発するのに「携帯アプリの全プログラムを自社の要員で開発する」というのではなく、「携帯アプリのアーキテクチャ（基本構造）を明確化し、自社の強みが活きるので自社で開発すべき部分と他社から購入すべき部分を明らかにして、携帯アプリのQualityを最大化する」というようなアプローチが極めて重要な開発指針となるでしょう。

効率化のポイントはモジュール化と標準化

携帯アプリを効率良く開発をするために、最も重要なポイントは携帯アプリのアーキテクチャそのものを標準化し、その携帯アプリをそのアーキテクチャに則ったモジュールの組み合わせで開発するというアプローチです。携帯アプリに必要とされる機能や構造を分析し、汎用的に利用されるロジックを再利用可能なライブラリやフレームワークとしてモジュール化し、その API （アプリケーションプログラミングインターフェース）をデファクトスタンダードといえるレベルにまで発展し、普及させて、全世界に流通できるというスケールメリットにより、ライブラリやフレームワークはもとより、携帯アプリまで含めて高品質なアプリを圧倒的に安い値段で世界中に提供することが可能となるのです。

米国 QUALCOMM 社は、以上のようなことを狙って、BREW というシステムで、組み込み系ソフトプラットフォームの標準化を実現しました。 この BREW により携帯電話機メーカーはソフト開発に煩わされず携帯電話機のハードウェア開発に専念できるようになります。ソフトメーカーは機種ごとの違いを調整する手間を大幅に軽減することができるだけでなく、世界中のあらゆる BREW 携帯電話機マーケットに自社のアプリケーションを流通させるチャンスを持つことになります。

SophiaFramework は携帯アプリ開発のアーキテクチャ指向の流れを汲み取り、携帯アプリをブロックのように容易に組み合わせるだけで開発できる高品質なユーザーインターフェースなどを中心としたライブラリとフレームワークを BREW 上に提供しています。勿論、SophiaFramework 上で開発された BREW アプリは全世界の BREW 携帯電話で実行可能です。
携帯アプリ開発はアプリ固有の処理と、GUI 部分やイベント管理などの極めて複雑で難解な部分を完璧に分けることができますが、後者に関しては全て SophiaFramewrok に全て任せることできます。よって、プログラマは純粋にアプリ機能のみの実現に専念できるので、生産性が大幅に高まります。また、利用者にとって喜ばれるとても使い易いモバイルグラフィカルユーザーインターフェースを搭載した、本当の意味で使える携帯アプリを世界中に広めることも可能となるのです。

最初の一歩は大きな一歩

ここで、ジグソーパズルを組み立てるときのことを想い浮かべてみましょう。さて、前半半分のピースをはめるのと後半半分のピースを埋めるのではどちらが、時間や労力がたくさん要求される大変な作業となるでしょうか？勿論、前半半分のピースをはめる作業の方が遥かに多くの時間と労力が要求されますね。

実はアプリケーション開発においてもこれと同じことが当てはまります。たとえサイズ的には同じ大きさであろうと、最初に開発すべき基盤に相当する部分のソフト開発は残りのアプリケーションロジックを中心とした開発と比較して、格段に多くの時間と労力を割かなければならないことが経験的に分かっています。SophiaFramework では、まさにジグソーパズルの前半半分に相当するアプリケーションの基盤といるソフトウェアモジュールが用意されているので、SophiaFramework を利用される方は最初からアプリケーションロジックに専念して開発ができます。そのため、SophiaFramework を採用した時の開発スピードは最初から通常よりも加速度が増している状態でスタートすることになり、通常では考えられないくらい短期間で、かつ少人数で極めて品質の高い携帯アプリの開発が可能となります。

航空業界では離陸するときの 3 分間が特に危険だといわれるように、何事も始動するときにもっとも多くのエネルギーや注意力、集中力が要求されるものです。SophiaFramework は建物でいえば土台と骨格に相当するライブラリやフレームワークを最初から用意し、アプリケーション開発で最も大変な最初の第一歩を全面的にバックアップします。また、アプリケーションの基盤となる SophiaFramework は徹底的にテストされ、且つ実績も数多く積んでいるソフトなので、品質面や性能面においてはバグのことなどに悩まされることなく、安心して利用することができます。 SophiaFramework は建物でいえば土台と骨格に相当する部品群を用意して、アプリケーション開発の最初の一歩を全面的にバックアップします。

未開の地における建築資材のように

或いは、貴方ご自身が周囲に全く何もない未開の地に放り出されたという状況を想い浮べてみて下さい。そこに家を建てるための建築資材が予め用意されていたとするならば、どんなにか有難いことでしょうか。現時点で、BREW プラットフォーム上でアプリケーションを開発するということは自分自身が何もない未開の地に放り出された状況に等しいといえます。

何故なら、アプリケーションを開発するために便利なライブラリやフレームワークなどが用意されていないし、揃っていないからです。SophiaFramework はこのように BREW アプリ開発プロジェクトにおいて厳しい状況に追い込まれた方々を救うという大きなミッションを持って開発されたアプリケーションプラットフォームなのです。SophiaFramework を構成する 3 層のうち、オブジェクト指向を実現する C++ ラッパー層とその他の部品を構成するユーティリティ層は、釘や金槌、のこぎりのように便利な道具です。プログラムの骨格であるGUI フレームワーク部分はまさに建物の土台と、すぐに使える柱や壁です。

いずれの層にあるモジュールも、現在の BREW SDK には付属していない極めて付加価値の高い内容で構成されおり、貴方の BREW アプリプロジェクトを加速するという意味において、多いに役立つものとなるでしょう。


注目の携帯アプリケーションプラットホーム BREW

BREW は 2001 年 1 月に QUALCOMM 社が発表した携帯電話向けのソフトウェア実行環境です。携帯電話間の仕様の違いを吸収し、単一のプログラムで多種の携帯電話に対応できるように設計されており、携帯用アプリケーションの発展を視野に入れたものとなっています。また、機械語に変換されたプログラムを実行するので Java ベースのソフトウェア実行環境より実行速度が桁違いに速いという特長もあります。

世界へ広がる BREW

米国 QUALCOMM 社は次世代携帯電話向けチップ世界市場で 90 ％以上のシェアを誇ります。今後、QUALCOMM 社が提供する全ての次世代携帯電話向けチップには BREW が搭載される予定です。現時点での市場ポテンシャルでも世界的規模で 1 億 5000 万台の市場があります。 3 年後には世界的にみて 3 億台以上の市場に急拡大する見込みです。日本では KDDI が2003年に BREW を本格採用し、2004 年以降出荷される全ての KDDI の携帯電話には BREW が搭載されることになっています。また、 BREW 上で開発されたアプリケーションは全世界の BREW 搭載携帯電話で動作しますので、BREW アプリケーション開発会社は全世界に向けた携帯電話向けアプリケーション開発に取り組むことができます。

SophiaFramework の特長

SophiaFramework とは、米国Qualcomm社BREW搭載携帯電話向けに「モバイル端末向けマルチウィンドウシステム」を携帯電話業界で初めて実現したアプリケーションフレームワークと各種ソフトウェアライブラリから構成されます。

QVGA端末の急速な普及、ＡＲＭ９などによる携帯電話向けチップの高速化の進展、プログラムメモリやデータメモリの急速な増大などに伴い、今後はますます、パソコンでいえば、WindowsやMacに代表されるような、使い易いマルチウィンドウシステムが、携帯電話利用者から当然のように求められるであろうと考えて開発されたのが SophiaFramework です。

使い易いマルチウィンドウシステムのアプリケーションを開発するためには、複雑で難解なイベント処理や描画処理をプログラミングする必要があります。この処理全てをアプリケーションプログラマに負担するのはどう考えても現実的ではありません。このような処理は普遍的で汎用的な処理でもあるので、 SophiaFramework にブラックボックス化することにより、実際は非常に高度なプログラミングスキルが要求されるものであるにもかかわらず、普通レベルのアプリケーションプログラマでも、使い易いマルチウィンドウのユーザーインターフェースを持つ携帯アプリを楽々と実現できるようにしました。その他、SophiaFramework にはC++による完璧なオブジェクト指向プログラミングを可能とする各種ラッパー群や文字列処理やストリーム、コレクション、描画処理など、あらゆる携帯アプリに必要なライブラリ群が標準で用意されています。将来的な展望として、現在、SophiaFramework はBREW上でのみ実装されていますが、アーキテクチャ上、プラットフォームに依存する部分と依存しない部分を明確に分離して開発されていますので、SymbianOS、携帯LinuxOS、TronOSなど、今後有力視される他の次世代携帯電話向けOSにもスムーズに移行させることが可能です。この仕組みにより、SophiaFrameworkをマルチプラットフォーム化するだけで、BREW上の携帯アプリをオートマティックにSymbianOS、携帯LinuxOSなどへマルチプラットフォーム化するようなことも可能となるのです。

SophiaFramework のアーキテクチャ

ソフトウェアが複雑化し、大規模化してくると、必然的に、処理の内容や性格に応じて構造的に分類して、統合的に開発するアプローチ、即ちアーキテクチャに基づくソフトウェア開発方法というものが必要になってきます。

BREW携帯アプリの開発においても、今後はアーキテクチャに基づくアプリケーション開発をしないとある段階で破綻が生じてしまうことでしょう。

SophiaFramework は、その事態を先取りする形で、BREW携帯アプリの開発作業そのものが最適化されるようなアーキテクチャを携帯アプリ開発者に提供しています。よって、開発者はこのアーキテクチャに則って開発を進めるだけで、次世代携帯電話にて要求されるような高度な携帯アプリを容易にかつ低コスト、短期間で開発してしまうことが可能となります。

SophiaFramework のアーキテクチャは大きく分けて 3 つの層で構成されています。 1 番下の層が、C++による完璧なオブジェクトプログラミング指向を実現するための C++ ラッパー層です。 BREWにて提供されている全APIに対するC++ラッパーが提供されます。中間の層は、あらゆる携帯アプリが必要であろう文字列処理、コレクション、ストリームなど各種ライブラリで構成されるユーティリティ層です。一番上の層は GUI フレームワーク層です。 GUI フレームワーク層は、マルチウィンドウの携帯アプリの処理で必須となる各種複雑なイベント処理と描画処理をブラックボックス的に実行してくれます。 SophiaFramework　で携帯アプリを開発する場合、建築材料に相当する GUI フレームワークをベースにして、必要に応じて、下位の層にあるC++ラッパー層やユーティリティ層のAPIを組み合わせて開発していくのが基本的な方法です。さらに必要であれば、のこぎりや金槌に相当する C++ ラッパー層とユーティリティ層を用いて、新たな再利用可能な部品を製作すること自体も可能なのです。

SophiaFramework で携帯アプリを開発すれば、時間の経過と共に、開発会社独自の再利用可能なライブラリも充実化してくるので、 SophiaFramework を使えば使うほど開発効率が向上するというメリットが生まれます。


]]> http://sophiacradle.noblog.net/blog/b/10024317.html Java-embedded mobile phones have been rapidly spreading over Europe, the United States and Asia since their release in Japan in 2001. At that time, Java was mostly used in game applications, but recently mobile phones have become multi-func... 2004-12-25T14:52:59+09:00
Overcoming Limitations in Program Size

One of the biggest burdens of developing mobile Java application is its limitation in the program size due to mobile phone hardware and telecommunication fees. Developing a high-quality and multi-functional mobile Java application in which end-users acquire full satisfaction is dependant on how to install as many useful functions as possible in a limited space of a program. As a countermeasure to this size limit, we developed SophiaCompress(Java) which, with just one click, automatically minimizes the size of mobile Java application program.

SophiaCompress(Java) is applicable with Java of all domestic careers - NTT DoCoMo, KDDI and Vodafone. It is proven to be of stable performance, as it has already been introduced by major game companies and content providers. By using SophiaCompress(Java), a mobile Java application developer is freed from the troubles of program size reduction so that he/she can concentrate on installing application logic.

A Java Application That Impresses Users

Nowadays, 99% of video tapes that are on the shelves of electric appliance stores are Video Home System (VHS) type, and yet Beta-max videos are rarely seen. Why? Are there any differences between VHS and Beta-max? There is a slight but a crucial difference in their recording times, which settled the battle of VHS versus Beta-max. The recording time of a VHS tape is two hours, a little longer than that of a Beta-max tape, so that a VHS tape can record a movie without cutting the last part.

Mobile phone Internet content industry is in excessive competition right now. In such circumstances, there is a lesson to learn from the VHS-Beta-max story: an effort to make one user happy inevitably leads to obtaining hundred thousands or millions of users. Whether you can install one more function on a mobile application or not can eventually result in the complete success or failure in your business.

In developing a mobile phone Java application, you must not compromise the project plan itself. A project that fulfills what end-users really want should never be abandoned if you are seeking success in the industry. It is only if you can accomplish the project to the final servicing part that you can then impress potential users and thus win their loyal service.

In the past, most developers of mobile phone Java application have injected a lot of time and efforts into reducing program size either manually or by using free Java application compress tools. In spite of those efforts, often a project still had to be terminated because the developer could not reduce the last few bytes. In such situations, SophiaCompress(Java) actually has been a helping hand for reducing program size. Since the release of SophiaCompress(Java), it has been used by a number of major game companies and content providers. There are some Java applications that could not have been serviced without the help of SophiaCompress, and that could not have been realized without SophiaCompress(Java)' original program technology.

In addition, we have a complete support system that never dissappoints our customers. So far, there is no mobile Java application that SophiaCompress(Java) could not eventually work. Using SophiaCompress(Java), any mobile Java application can be compressed. And, if we stumbled across one that could not, we would thoroughly analyze the application and definitely compress it because we are confident in our technology.


Programming Compression Operation of Mobile Phone Java Application Size

Mobile Java application size compress consists of the following operations.
　　
-Shortening names of methods, classes and variables 　　
-Sharing names of methods, classes and variables 　　
-Replacing current instruction sets with shorter ones 　　
-Inline expansion of methods 　　
-Gathering variables to one array 　　
-Deleting useless methods, classes, variables and constant entries 　　
-Deleting useless instructions 　　
-Merging classes 　　
- ... etc.

These operations follow set instructions, so they can be programmed to be automatically completed by a computer. Although complicated and difficult, with the understanding of Java Virtual Machine (VM), these processes can be programmed. SophiaCompress(Java) offers some parts whose size can be automatically minimized as a program. It performs a higher compress rate than any other tools especially by sharing names that are used by Java VM itself and the names of necessary outer application program interfaces (API). Therefore, SophiaCompress(Java) can even increase the compression rate by using other compress tools with it.

Obtain Accumulated Know-hows at One Time with SophiaCompress(Java)

When developing a mobile Java application, having particular know-hows - such as how to reduce program size, knowledge about program dependence on carriers and handsets and performance tuning - is crucial to productive development. It is impossible to obtain these know-hows in one day because these are accumulated through experiences in developing Java applications.

In particular, a know-how on "the technology of program size reduction" leads to the supreme quality of mobile Java content, and ultimately puts you a step ahead of the competition. The more of these know-hows you are equipped with, the more functions could be armed on an application in a limited amount of program data. In other words, it is the only way to realize a complex mobile phone application project.

SophiaCompress(Java) is offered as a package of the latest and best know-hows to reduce program size in the world. Therefore, installing SophiaCompress(Java) is a short-cut to acquire these know-hows without going through troubles of developing many Java applications yourself.

Tremendous Advantage in Cost of Life-cycle Maintenance

SophiaCompress(Java) works on a compiled Java Archive (JAR) format program, enabling a programmer to write in any format without worrying about size limits on source codes. Better life-cycle maintenance depends on the ease of reading source codes; mobile phones have different specifications due to carriers and handsets, and each needs to correspond to its own specification.

In addition, mobile Java applications are not automatically produced on a large scale by computers - they are usually developed by hand, with considerable costs. Since new handsets are frequently released, maintenance of versions needs to be done effectively. As an indirect effect, SophiaCompress(Java) is also offered as a tool for writing legible source codes.
]]> http://sophiacradle.noblog.net/blog/b/10024170.html ＜携帯Java圧縮ツールSophiaCompress(Java)＞ いま、携帯電話はパケット定額制の時代に突入しつつあります。パソコンと同じく、パケット定額制となれば携帯電話でのネット利用は大きく変化することでしょう。 これからは、利用者の要望を効率良く実装する。... 2004-12-24T16:42:59+09:00 ＜携帯Java圧縮ツールSophiaCompress(Java)＞

いま、携帯電話はパケット定額制の時代に突入しつつあります。パソコンと同じく、パケット定額制となれば携帯電話でのネット利用は大きく変化することでしょう。

これからは、利用者の要望を効率良く実装する。そして、クールなサービスをスピーディに提供する姿勢が喜ばれるのではないでしょうか。


SophiaCompress は煩わしい携帯電話特有のアプリサイズの問題をボタン一つで解決してくれます。しかも、その圧縮率は世界最高水準を誇ります。

既に、数多くの携帯 Java アプリで採用実績のある SophiaCompress は多様化する利用者のニーズに確実に応えてくれます。

2001年にJava搭載ケータイが国内で発売されて以来、ヨーロッパ、アメリカ、アジアなどにもその普及が急速に進んでいます。また、Java搭載ケータイが発売された当初、ケータイJavaはゲームで利用されるシーンが大半でした。最近では、ケータイにカメラや赤外線通信などの機能が搭載されたりして、ケータイJavaアプリの応用分野の広がりに新たなる展開の兆しが伺えます。今後、金融決済など、ケータイJavaアプリの応用分野の広がりが期待されます。

プログラムサイズ制約を乗り越えて

ケータイJavaアプリを開発する上で、最大の障害要素の一つとして、ケータイのハード機器や通信料金などに起因するプログラムサイズ制約の問題をあげることができます。
携帯電話のユーザーが充分満足できるような多機能で高品質なケータイJavaアプリを開発するには、如何にしてユーザーから要求される多くの機能を、限られたスペースに盛り込んだプログラムとして実装できるかが勝負の大きな分かれ目となります。
このような背景を踏まえ、ボタン一つ押すだけで、ケータイJavaアプリのプログラムサイズを自動的に最小化してくれる、便利なツールを目指して SophiaCompress は開発されました。 NTTドコモ、KDDI、Vodafoneなど国内外の全てのキャリアのJavaに対応しています。既に、大手ゲーム会社、大手コンテンツプロバイダをはじめ多数の企業に導入実績があります。
SophiaCompress を手に入れることで開発者は、これまで最大の懸案事項であったケータイJavaアプリのサイズ削減の問題から完全に解放され、本来やるべきアプリケーションロジックの実装だけに専念できます。

ユーザーに「感動」を与えるケータイJavaアプリとは

もはや街角の電気屋でベータ型のビデオを見ることは滅多になく、売られているビデオと言えば99％以上がVHS型です。
VHSとベータにそれほど圧倒的な差があったのでしょうか。 VHSであれば録画できる時間がベータより少し長くて2時間であり、映画を録画するのに丁度良いというちょっとした差が現在の勝者と敗者の姿を決定付けたのです。
ケータイコンテンツ業界は今や熾烈な過当競争に見舞われています。このような環境の中でこそ、VHSとベータの教訓は活きてくるのではないでしょうか。
この業界は、一人でも多くのユーザーに喜んで利用してもらう努力が、最終的には何十万人、何百万人にも及ぶユーザーの獲得につながると考えられる時期に来ています。あと一つの機能の搭載の如何が後々の圧倒的な成功もしくは失敗という結末へと繋がっていくのです。
多くのユーザーに支持されるケータイJavaアプリを開発するために、企画そのものに妥協することはできません。ユーザーから強く期待されるであろう企画は何としても開発、実現し、サービスインまで漕ぎ着けたいという思いによって初めて、ユーザーの共感や感動を呼び起こすことができるのです。

これまで、数多くのケータイJavaアプリの開発現場において、サイズ制限をクリアするために多くの時間と労力が費やされてきました。これがないと絶対にユーザーの賛同が得られないというような機能を、フリーのJavaアプリ圧縮ツールや手作業によって限られたケータイのプログラムスペースに収納させるため、血の滲むような努力がなされていたのです。
それにも関わらず、どうしてもあと残り数バイトが削減できないような事態に陥り、開発プロジェクト自体がストップしていることがよくありました。そんな時に、SophiaCompressによって解決されたという事例が実際に数多く存在するのです。
発売以来、SophiaCompressは、既に大手ゲーム会社や大手コンテンツプロバイダなど多くの企業に採用され、SophiaCompressがなければサービスインできなかったケータイJavaアプリはたくさんあります。
SophiaCompress 独自のプログラム技術によって初めて実現可能となった事例が多数あります。一方、サポート体制も万全であり、これまで最終的に圧縮できなかったケータイJavaアプリはありません。いかなるケータイJavaアプリもプログラム圧縮可能です。

ケータイJavaアプリのサイズ圧縮作業をプログラミング

ケータイJavaアプリのサイズ圧縮は下記のような作業から構成されます。
　　
●メソッド、クラス、変数などの名前の短縮化　　
●メソッド、クラス、変数などの名前の共有化　　
●より短い命令セットへの置き換え　　
●メソッドのインライン展開　　
●変数の配列化　　
●不要なメソッド、クラス、変数、コンスタントエントリーなどの削除　　
●不要命令の削除　　
●クラスの融合　　
　　・・・

これらの作業自体は一定のルールに基づく定型的な作業であり、何も人間がやらなくとも済む作業です。複雑で難解ではありますが、JavaVMというものをよく理解すれば、プログラミング可能な処理なのです。 SophiaCompressでは、自動的にサイズ圧縮可能な部分は極限のレベルまでプログラムとして実現しています。
特に、JavaVMそのものが利用している名前や必須の外部APIの名前などとの共有化まで実現することにより、他のツールでは絶対になし得ないレベルの圧縮率を達成しています。そのため、SophiaCompressは他の圧縮ツールと併用することによって、更に圧縮率を高められるのです。

蓄積されたノウハウを一瞬のうちに

ケータイ Java アプリの開発では、プログラムサイズ削減、キャリアや機種に依存する知識、パフォーマンスチューニングなど、ケータイJava特有のノウハウを持っているかどうかで、開発生産性に大きな差が生じます。このようなノウハウは、一朝一夕で蓄積されるものではなく、多くのケータイ Java アプリの開発経験の蓄積より獲得できるようなものです。
特に、「プログラムサイズ削減技術」に関するノウハウは、開発されるケータイJavaコンテンツの品質に決定的な差をもたらし、開発会社にとっては他社に対すて大きく水をあける差別化要因と成り得るものです。このノウハウが多ければ多いほど、一定のサイズ制約の中で、より多くの機能を搭載することができるため、贅沢な企画までもがスムーズに実現できてしまいます。
SophiaCompress には、最新かつ世界最高水準のプログラムサイズ削減ノウハウがパッケージとして蓄積されています。開発経験で苦い思いをしなくとも、SophiaCompressを購入するだけで、そのようなノウハウを手に入れることができるのです。


保守性の観点からライフサイクルに渡るコストメリットは甚大

SophiaCompressはコンパイル後のJAR形式プログラムをプログラム圧縮します。よって、プログラマはソースコード上でサイズ制約を意識したプログラミングをする必然性がなく、とても読み易い形式でプログラミングできます。ケータイにはキャリアや端末など多種多様な仕様があるので、それらに対応させるためにはプログラムのソースコードの見やすさが、ライフサイクルに渡る保守性を高める上での重要なポイントとなります。
ケータイJavaアプリはコンピュータが自動的に大量生産してくれるものではなく、人手によって多大なる費用を支払って開発される性格のものだけに、目まぐるしいケータイの新機種発売に合わせて発生するバージョンアップなどの保守作業は効率良くやりたいものです。間接的な効果でありますが、ソースコードを分かりやすく記述できるツールとして、SophiaCompressはここでも大きな役割を果たしているといえます。



]]> http://sophiacradle.noblog.net/blog/f/10024127.html １．BREW 早分かり BREW とは、2001 年 1 月に米国 QUALCOMM 社が発表した、携帯電話の異機種間のOSの違いを吸収する、 C / C++ アプリケーション開発実行環境で、アプリケーションの配信や課金のためのシステム(BDS)も備えています。 2001年 11月に韓国の ... BREW とは、2001 年 1 月に米国 QUALCOMM 社が発表した、携帯電話の異機種間のOSの違いを吸収する、 C / C++ アプリケーション開発実行環境で、アプリケーションの配信や課金のためのシステム(BDS)も備えています。 2004-12-24T13:05:59+09:00 １．BREW 早分かり

BREW とは、2001 年 1 月に米国 QUALCOMM 社が発表した、携帯電話の異機種間のOSの違いを吸収する、 C / C++ アプリケーション開発実行環境で、アプリケーションの配信や課金のためのシステム(BDS)も備えています。

2001年 11月に韓国の KTF が世界で初めて BREW サービスを開始しました。日本では 2003年 2月より KDDI が EZアプリ（BREW） という名称で BREW サービスを開始しています。現在、24 ヶ国 37 通信事業者が BREW を導入、もしくは採用を決定し、世界中でその普及が急速に進展しています。また、NTTドコモは2005年末からBREW を導入します。 Vodafone でも一部の機種に BREW が搭載されています。（2004年10月時点）

アプリケーション開発者は世界中で広く普及している様々な BREW 携帯電話端末向けに、極めて移植性の高い、メーラー、ブラウザ、電話帳など各種アプリケーションを開発することができます。 また、携帯電話端末メーカーはアプリケーションの開発は外部に任せ、年々高度化するハードウェア機能そのものの開発に専念でき、携帯電話事業者はアプリケーション配信による新たなる収益源を得ることができます。


もともと、BREW は QUALCOMM 社が開発した REX ( Real-Time Executive ) と呼ばれる RTOS ( Real-Time Operating System ) の上で動作するミドルウェアでした。 QUALCOMM 社のチップには、この REX と BREW が基本的に搭載されてます。そのため、QUALCOMM 社のチップを採用する携帯電話端末メーカーの端末には自ずと BREW が搭載されていることになります。実際、QUALCOMM 社のチップを採用している、携帯電話端末メーカーの NTTドコモや Vodafone の一部の機種には既に BREW が組み込まれています。

発表当初、 CDMA 2000 向け携帯電話用チップだけに BREW が搭載されていましたが、最近では W-CDMA/GSM/GPRS/EDGE/HSPDA など世界のいろいろな携帯電話通信方式に対応した BREW 搭載チップが発表されています。

＜世界の BREW 導入状況＞
http://www.brewjapan.com/today/

BDS とは
BREW Distribution System の略称で、BREW アプリケーションを配信し、課金し、管理するシステムです。エクステンションと呼ばれる、BREW を拡張する API 単位でのモジュールの配信や課金も可能となっています。アプリケーションに不具合が発見された場合、携帯電話端末を回収することなく、修正版を無線で更新できます。

]]>