簡易版wiki
ttp://http://www15.atwiki.jp/flickapplication/ SH-04Aでフリック使いたいね。
アプリ作れる知識あれば協力したいけど…自分はまったく駄目です…
わたしは知識ある方を応援しまつ
アプリ作成の知識０だけど、期待と応援と動作テストくらいはするぜ
変換エンジンに直接アクセスできなきゃ予測候補も取れねーし
自前で変換エンジン作るなんてのはなおさら現実的じゃねー
少なくともDocomoのドキュメント見る限りInputMethod関係のAPIは出てないぜ
フリーの「skkime」のJAVA移植からやるって手もあるけど結構大変だと思うぞ
予測ついてないし、文法解析やらが無いとこの手の入力方式では「skkime」だと使いずらすぎる
つべこべいわねぇで知識あんなら作れや。最初から無理だとか言ってんな。
最大限努力しろ。俺らのフリックのために寝る間も惜しんで働けよ。おら、早くしろ。
基本設計からちゃんとやらんでどうすんだよ
共同でやるんならそこんとこ無視しちゃ誰も協力して作れないだろ
そんな調子じゃ誰かが作り始めても挫折した後にまた一から始める事になって
いつまでたっても出来あがんねーよ
まずは現状の問題点の解決策が出てこない限りは作り始めてもどーしよーも無い
基本設計に問題があったら最初っから作り直しだって所を良く考えろ
いや、言い訳はいいから手と頭動かせよ。あと数時間で発売開始なんだぞ？
知識もスキルもないですが、応援してます。
ときどきｗｋｔｋしながら見に来ようと思います。
お前プログラムなめすぎ
開発なんて半分は設計のドキュメント作業だ
共同で作業するならなおさら一人で勝手にやり始めると後で収拾つかなくなる
ちゃんと頭使って問題点洗い出してんだからお前が率先して解決案を出せ
お前は自分で頭使わない気かよ
wiki見たけどSVNはあった方がいいよ
ブランチ切ってバージョン管理できるし共同作業するならコンフリクト気をつけないといけないから
あんな、いいか？お前一生懸命作る人、俺らはそれを使う人。立場を考えろ。
共同？解決案？ゴタク並べる時間と余裕があんならさっさと作業にかかれ。
お前知識あんだろ？アプリのプログラムになんの知識もない俺らが問題点だの解決案だの出せるかってんだ。
はい、お話はここまで！はい、作業して。
UIからエンジンを叩く時に抽象化する部分くらいには分けた方がいいから
まずはその部分のクラス設計からだと思う
結局変換エンジン部分が出来ないとちゃんとしたインターフェースも作れないと思うけど
一つ言っとくけど誰も作る義務負ってないんだから協力する気が一切無いなら
こっちも作る気なんてねーよ
文句しか言わないなら誰も参加しないと思いますけど
いいのか？
まだぁ？協力？応援してやっから。ふれーふれーがんばれーはよつくらんかいー
はい、協力したよ。さぁ作れ。今作れ。すぐ作れ。
勝手にやってろアホ
ガキだねぇ。出来ないとすぐ諦めて逆ギレかよ。会社でもこうなんだろうねw
人を怒らせる天才だな
見ててもいい気がしないわ
このアプリが可能なら是非実現させて欲しいです
問題点が解決するまで無理
それに「予測が出来ない」ってユーザー観点の問題点の提起もしてるのに回答無いからはなっから協力する気も無いようだし
これじゃUI部分も決まらない
デスマーチに必ずいるタイプ
SVNはできれば採用したいけど、ある程度プログラム組むメンバが決まってからのほうが
いい気がする。さすがに不特定多数でSVNはいろいろ危険な気がする
作業工程は確かにUIとエンジンなどで分割すべき。でも俺はソフトの開発をやったことがない
ので、どのように分けるべきかとか、どのような工程を踏むべきかがわからん。その辺は
実際ソフト開発とかに携わっている人がいたら引っ張っていってほしいかな
まずするべきことは、宣伝かなーと思う。人がある程度集まらないことには厳しいと思うので。
それと同時進行でどんな機能が必要かとかをこのスレで話し合って決めるべきかな。
だから作り出すのはもっと後かな。先にがんばって人を集めて方向性を決めよう
じゃあ宣伝手伝って♪
最終的には変換エンジンの仕様で制限がかかるけど
まずはどうゆうUIがいいのかを意見出してまとめてくのがいいよ
内部の実装に必要な事がそこから具体的に見えてくるから問題点とか解決に必要なことも洗い出せる
UIだけのプロトタイプなら工数もそんなかからないしね
なぁ、おい。やる気あんのか？イライラさせんなよったく…
気が散るから首を挟まないでくださいね
言い忘れてたけど不特定多数だからこそsvnは必要
最初はいらないってのは同意するけど
なにか問題が起きた時にコミット単位の差分だとかが取れるのは重要
何より特定のリビジョンにロールバックする機能なんかは多数で共同作業するなら必須になってくるかと
ケータイで、入力を乗っ取るようなソフトって
作れるの？
というかgesture10keyをSH-04Aに載せたら
需要ありそうと思って。
Appleのしていることをどうしてそんなに心配するのかと質問した。
AT&T MobilityのCEOのde la Vega氏の回答は、
業界がAppleをどう見ているのかを要約しているように思える。
「業界の残り99.5％が、iPhoneをコピーしようとしているからだ」
ttp://http://japan.cnet.com/special/story/0,2000056049,20388431-2,00.htm さすが。いたって冷静な判断w
ドコモの大好きな「格」と「威厳」がもう大学生と小学校２年生くらいの差。
スレタイ読めばわかるけどアプリでやる時点で乗っ取りとかそういうものではない
メールとか長文打つ前にアプリで文字入力して一括コピペってイメージかと
変換その他は自前でアプリに乗っける必要があると思われる
変換の箇所でフリーで移植可能なものがあれば
UI自体はそれほど難しくはなさそうな気がしてますが
サバ/クラを前提とした部分をどうにかしないとアプリに実装は難しいかも
一応文章の一括変換も出来るから使えれば強力だと思うけど
ほんとにサバクラ型にしてネット上に置いちゃうと通信量&レスポンスで話にならんだろうし
内部にコミコミで動くように移植、改修するのは面倒かも
移植したときのどのくらいのサイズになるかも気になる
詳細知ってる人おらんかな？
エンジンは既存(携帯本体にある辞書、変換)を上手く使えないかな
インタフェースとしてフリックをつかってその文字列を携帯本体の変換エンジンに投げて
また結果を返してもらって表示。みたいな。
携帯本体の変換エンジンをフックして使う感じ。これができたらめっちゃ楽なのだが
JAVA、windows mobileとかで開発やってるから多少は力になれるかもしれん
ここまで読んで見てだけど
が言ってることが一番現実的かな
UIがどうのとか話が出てるが、まず屋台骨部分がどのようになってるか調べないとUIとかエンジンとか考えても無理だと思う
携帯本体の変換予測とか、携帯の機能を呼び出して使うとかいうのは基本的にムリだからな
iphoneのjailbreakingと同じ事をしない限り自由には使えない
仮にjailbreakingが出来たとしても、そこからの道のりが・・・
まず作ろうとしてるのはiアプリで実現しようとしてるのか？
であればまずiアプリで可能な事がなんなのか洗い出さないと、いつまでたっても創造の範囲でしかすすまないぞ
で、
あとで調べてみるけどメール起動中にiアプリ起動出来るのん(＾o＾?
あとiアプリは起動したら必ず全画面になるのかな
もしメール起動中にiアプリが起動できてそれが、全画面でなく画面の一部表示可能なら、文字入力UI部分の上にiアプリ版フリックU
Iをオーバレーさせて、iアプリで拾った文字を・・・
なんてちょっと思ったりしたがDoJaの仕様がどうなってるか見ないとやっぱわかんねぇ(^_^;
プロトタイプの段階だから最終的な理想型を考えるで良いと思うよ
制限があるとしても、どういう風に近い形にするかって考え方しないと
経験的に実装都合だけでUI決めると良いものにはならないし
例えば予測は出来なくても入力の度に裏で変換呼び出して変換候補を常に出すようにすれば操作感は近くなる
みたいな感じで
>あとで調べてみるけどメール起動中にiアプリ起動出来るのん(＾o＾?
今まで使ってた端末は出来たんで疑問に思ってなかったわ
>あとiアプリは起動したら必ず全画面になるのかな
既存のはそう
新たに追加されたウィジェット型のアプリで拡張されてなければ自ずと全画面になるかと思う
やっぱし最新の機種はすごいな・・・
たしかに、なにやら出来たけど使いにくいでは話にならないもんね
プロトという意味であればフリックのUIを作成からかなぁ
使いやすい配置はどんなのか・・・
HTCのTouch Pro(UK輸入版)でgesture10key使ってフリック入力出来るようにしているけど
入力部分をスキンで変更できるので、そういうのが出来れば、あとあと個々で調整してもら
えるね
ウィジェット型のiアプリはDoJaでなくてstrarの方か
拡張APIのTouchDeviceクラス辺りをみてるとフリックのような動きは十分出来そう
基本APIにMail、MessageAgentクラスとかあるんで、メール専用のだけどフリック入力可能
とか出来そう・・・かなっ(^^;
今まで使ってた端末は出来たんで疑問に思ってなかったわ
D903i使ってるけど出来るな・・・
普段imodeとかiアプリとか使わないんで気がつかなかった_(_ _;)
>あとiアプリは起動したら必ず全画面になるのかな
既存のはそう
新たに追加されたウィジェット型のアプリで拡張されてなければ自ずと全画面になるかと思う
そっか・・・なら入力部分以外は透過にして下のメール部分が見えるように出来ればいいのんな
>ウィジェット型のiアプリはDoJaでなくてstrarの方か
>拡張APIのTouchDeviceクラス辺りをみてるとフリックのような動きは十分出来そう
基本APIにMail、MessageAgentクラスとかあるんで、メール専用のだけどフリック入力可能
>とか出来そう・・・かなっ(^^;
とりあえず、ウィジェット使いたいかどうかに関わらず
starで追加されたインターフェースなので選択肢はstarいったくっぽい
ループで描画回すような作りにしてスライド中の位置追跡するような作りにしないと
駄目っぽいから注意が必要
iPhoneで思ったけど、フリック入力があればQWERTYとか使わなくなるし。
最強のモバイル日本語入力だよ。
いずれにせよほぼSH-04A専用と考えればstarでいいんじゃないかと。
どうせ今後のタッチパネル端末もstar対応になっていくのだろうし。
あとの話でサバクラ型で変換エンジンを置くという事を考えてみると、
基本は2chブラウザみたいに個人の中間鯖みたいな考えでいいんじゃないだろうか。
置けない人は、有志の変換鯖が置かれるならそれを利用する、って感じで。
変換時のみのアクセスだから、ブラウザ利用よりは軽い可能性も？どうだろう。
>あとの話でサバクラ型で変換エンジンを置くという事を考えてみると、
>基本は2chブラウザみたいに個人の中間鯖みたいな考えでいいんじゃないだろうか。
>置けない人は、有志の変換鯖が置かれるならそれを利用する、って感じで。
>変換時のみのアクセスだから、ブラウザ利用よりは軽い可能性も？どうだろう。
これはたぶん現実的じゃないです
通信できない所では使えなくなったり、通信状況が悪い電車なんかだと候補が出てくるのがやたら遅くなったりと言った不便が大きいのが一番のネック
TCPで通信する部分を取っ払って直接繋ぐように改修するのが一番良い選択になるかと思う
wnn使うとしたらだけど
一応PC上だしあまり参考にならないかもしれないけど
javascriptのIME
ttp://http://ajaxime.chasen.org/ うちの環境だとレスポンスはきわめて良好デス
地下鉄やビルで使えなくなってもOK？
なんとも言えないけれど、フリック入力する状況ではタッチポジションであり、その状態で
文字入力を求める状況としてはほとんどがメール作成のため、と考える事が出来るから
電波状況の良い場所で使う事が前提・・・と考えると鯖式でもいいかもしれない。
もっともメールを作成するのに電波状況なんて考えて打つわけではないだろうし、
アプリに変換エンジンを組み込める見込みがあるのであれば、それに越した事はないよね。
タッチ操作で初期座標取得＆Canvasにフリックを描画
タイマ起動100ms？ぐらいでイベント発生させて、100ms後の座標取得
初期座標から100ms後の座標とxyの移動量をと方向を計算フリックにかかる位置に移動してたら
その文字の色を変更してフリックを再描画
リリース操作でフリック消去＆文字取得
って感じかな
この部分だけなら難しくないねぇ
なんか見てるとJAVAのSwingのサブセットみたいに感じる >> star
電波状態の悪い所で変換できないのはつらい(^^；です
ただクラサバ型でjavascriptでも条件が良ければ結構速いので悪くないかなぁと・・・(^^;
あとアプリの仕様としてスクラッチパッドの容量に収まらないとダメだと思うので、
仮に変換エンジンとか作ったとしても辞書なんかは外部メディアにもたないと無理っぽい
ように思う
開発環境Eclipseかぁ
Eclipse3.0/3.1になってるけど3.3で動くかなぁ
今の開発環境おかしくなるの嫌だなぁ・・・_(_ _;)
>タッチ操作で初期座標取得＆Canvasにフリックを描画
>
>タイマ起動100ms？ぐらいでイベント発生させて、100ms後の座標取得
>初期座標から100ms後の座標とxyの移動量をと方向を計算フリックにかかる位置に移動してたら
>その文字の色を変更してフリックを再描画
ゲームみたいに描画のためにループ回してループ内で処理する方がタイマーよりは構造がシンプルで見やすくなると思うけどどう？
プロトの段階でここに凝ってもしょうがないけどメインループ見ればシーケンスの流れがわかりやすくなるし
検索エンジンの部分は多分別スレッドにしないと処理速度に影響しそうなんで
タイマーとスレッドとか入り乱れるてシーケンスがわかりにくくなりそう
>なんか見てるとJAVAのSwingのサブセットみたいに感じる >> star
starってDojaのソースコードと互換無いんだっけ？
まだドキュメントしか見てないけどバイナリ互換だってのは書いてあった
コードについてはまだ見てないんだけどどうなん？
SDKだけでも動作するはず
eclipse版もあるってだけ
doja5.0もそうだったから多分そうだと思うんだけど
eclipseの方がエディターは使いやすかったけど
SDKの方はプロジェクト管理とビルド環境、エミュレータだけなので
エディタは自分のテキストエディタって感じになる
公式のQ&Aでソースコードレベルの互換性は無いって書いてあるね。
Starってアプリケーションサイズとスクラッチパッドの合計が2048KBも使えるのか。
かと言って辞書まで入れられるかっていうとそんな容量でもないんだろうけど。
プログラムの知識はほとんど無いからどこまで意見していいものやら；
>あとアプリの仕様としてスクラッチパッドの容量に収まらないとダメだと思うので、
>仮に変換エンジンとか作ったとしても辞書なんかは外部メディアにもたないと無理っぽい
>ように思う
確かにそれはあるね
ただ、今回のアプリの場合スクラッチパッドには辞書以外置く物が無いからそれは大丈夫じゃないか？確認はして無いけど
最新機種しか動作しないこと考えたらSD前提でも問題ない気もするけど
コードの互換はそんなに気にしなくていいレベルっぽい
↓
ttp://allabout.co.jp/internet/java/closeup/CU20090128A/ >……と聞くと、「また全部やり直しか……」とがっくりしてしまうことでしょう。が、この「互換性がない」という表現、実はけっこう注意しないといけません。
>実際には、パッケージ名といくつかのメソッド名が違うだけで、他はほとんど同じなのです。ですから、「DoJaのソースコードをStar用に書き直す」といっても、作業時間は１分でおしまい、という感じで終わってしまいます。
>想像していたような心配はほとんどないのです。
と言う事らしい
いまのところiアプリ前提で話をしてるけど
auは多分厳しい(てか対応端末無い？)
brewは審査が通らないと配布できないし
オープンアプリで作ろうとするとアプリサイズ100k、ﾃﾞｰﾀ用の領域30kって言う制約がきつい
辞書をサーバーに置くか、って事にしても一日の通信量が限定されているのでバカスカ通信するわけにもいかないので
ソフバンの方の制限はよく知らないけどここも通信周りで制限があったような
それと通信するには公式に登録しないといけないんだっけ？
ソフバンに関してはすげー勘違いしてるかもしれない
>56
実験コードね
タッチ操作でループ開始したとして、リリース操作時のイベントがループ内で取れるかなぁ
リリース操作でコールバックされた関数にendFlg = trueとかしてループ内で判定する？
どうなんだろ(^o^;
単純ループだとCPUリソースくってリリース操作のイベントが延滞するとか、コールバックされないとか・・・
が気になる
Thread.sleep()とか見たいなの使える(^^?
3Dとかグリグリ動かせるからあまり気にしなくてもいいかなぁ
そんな部分も良く分かってない・・・_(_ _;)
>57
開発環境インストールするときにEclipseのインストール先聞いてくるので、3.１も入れることにするよ
インストールするとエミュレータもは入るみたいだね
エミュレータってタッチパネルのエミュレート(マウスでクリック)してくれるのかな(^o^? SH-04欲しいよぉ・・・
>59
今思ったけど辞書作るの大変・・・
>単純ループだとCPUリソースくってリリース操作のイベントが延滞するとか、コールバックされないとか・・・
もちろんスリープは入れるんだけど
↓グーグルキャッシュだからいつまであるかわからんけどわかりやすいコード
ttp://209.85.175.132/search?q=cache:WafNUYQD_CwJ:yun.cup.com/iappli003.html+iアプリ+作成+描画ループ&hl=ja&ct=clnk&cd=1&gl=jp >エミュレータってタッチパネルのエミュレート(マウスでクリック)してくれるのかな(^o^? SH-04欲しいよぉ・・・
機能全部試せないと開発できないから大丈夫でしょw
>今思ったけど辞書作るの大変・・・
エンジンはフリーだけど辞書は無しなんて事は無いと思うから大丈夫でしょ(無かったら確かに大変^^;)
auのbrewはCなんだね
アプリのサイズが100kって言うのはひょっとしたらクリア出来るかもしれないけど
それ以前にソフィア・クレイドルってところから、何やらと買わないと開発出来ない？
ソフトバンクはS!アプリとモバイルウィジットと２本立てどっちもＪＡＶＡかな
技術資料とるのに会員にならんとダメなんかぁ
登録と入ってもメアドぐらいだけど・・・
ありがとうです
JAVA Swingとほぼ同じような処理っすね
starＡＰＩとウィジット仕様がクリアになればガリガリコードは書けそう
ダウンロードしたウィジットの開発環境にある
Star-2008_Emulator_DevGuide1.03.pdf
みたところタッチパネルという文言が検索に引っかからない(^o^;
brewの審査は個人レベルでは通らないと思っていい
それとbrewとオープンアプリは別物
brewで思ったように開発できないので変わりに自由に開発できるものとして
オープンアプリが乗ったって事100k制限はオープンアプリでの話し
>アプリのサイズが100kって言うのはひょっとしたらクリア出来るかもしれないけど
辞書を考えるとリソースに置くのも保存領域に置くのもほぼ不可能と思っていい
■iアプリコンテンツ開発ガイド for Star-1.x iアプリオプション・iアプリ拡張編
jguideforstar_1_x_opt_081105.pdf
のP.82
■iアプリコンテンツ開発ガイド for Star-1.0 オプション・拡張APIリファレンス編
jguideforstar1_x_apiref_opt_081105.zip
com.docomostar.opt.ui(ユーザインターフェースの作成に使用するオプションAPIを定義します。)の中の
TouchDevice(タッチパネルデバイス機能を定義します。)
とにもかくにもAUでは現状ムリと・・・
どうしようもないですね
>67
あっエミュレータがタッチパネルをエミュレーションしてくれるのかなぁと
いうことでエミュレータのユーザガイドにタッチパネルの文言がないよーと・・・
APIの方はjavadocの方でも確認できます(^o^)ノです
>あっエミュレータがタッチパネルをエミュレーションしてくれるのかなぁと
>いうことでエミュレータのユーザガイドにタッチパネルの文言がないよーと・・・
そこはやってみるまでわからない....と
出来ないとなると実機が無いとつらい事に(実機があってもつらいけどw)
ふーむ、そうか、一応全般的に考えるんだね。でもdocomo以外は厳しそう？
個人的にはStar版があればいいんだけどねｗ一番現実的っぽいし。
プログラムは組めないにしても話に参加するならStarプロファイルには目を通して
おいた方がいいんだろうか。出来ない事をああすればこうすればって言っても
しょうがないし・・・。
とりあえず動作テストだけは参加できるから、試す時は色々やれます。
開発側では気付けない事にも気付くかもしれないし。・・・ないかなｗ
乞食は何処まで言ってもクズだな
如何にも文系って感じ＾＾；
技術系の話は知ってる人に任せてどうしたいかだけで良いとおもいまつ
出来る出来ないは知ってる人が判断すればいいから
理想型があれば、そのままでは実現不可能でも代替案作って出しやすいし
俺には何の知識もないが時間をかかれば作れるはず・・・！
作成者にはがんばってほしい！！
今のところsh04aスレでしか宣伝してないけど
他に宣伝するとこあるかな？
s03aは12キーついてるから需要がなさそうな気がして
わざわざタッチ買うのかーやるなぁ
女々しいやつらの溜まり場か？
まずは準拠する形での実装から始めるのが早いでしょうね
実機があればまずはそこからと言う事でしょう
で、出来ることと出来ないことを洗い出してその部分を具体的にどうして行くか
skkime使うにしてもfreewnn使うにしてもどちらにしろJava移植しないといけなくなるから
ここ詰めてかないと次の話は進まないかな
暫く先になると思うけど
VBとC#となら出来るんだけど・・・
ひとまずJavaを勉強しながら応援させて頂きます
言語としてはjava
構文なんかはたいした問題じゃないけどクラスは解ってないとつらいかも
やべー。Cが少しわかる程度だから、この辺さっぱりわからん
一応、宣伝、wiki作成、スレ立てとかで支援するつもりだが
正直ソース書く自信はない
真の意味で理解してなくてもコードは書けるけどね
理解という意味では現場の技術者でもちゃんと解ってないやつはごろごろしてる
どう書けばどう動くかってのがわかってればなんとかなるから(笑)
ただ今回みたいに多人数でやるからには最初にある程度きっちりやってかないとぐっちゃぐちゃになるから
ある程度知識のある人がインターフェース決めるぐらいまではやらないとダメな気がするっす
なにげにテキスト回りが面倒だから
キャレットの管理だとか候補の出す位置の座標管理だとか割りと大変だよ
ひとまずdocomo用というかSH-04Aでの実装に向けて、ってのが目標になると思うけど、
iモードメールとiアプリの同期・・・というか、メモ帳みたいな感じでみたいに文章を
コピペって感じになるのかな？この方法だとメールに文章を貼りつけるのは手動って事だろうか。
だったらいっそ送信専用のメーラーアプリにしてまうのは？電話帳の参照が出来ないか・・・。
あとUIはiPhoneみたいな感じで考えると、文字をタッチする部分は縦5列になるよね？
中央3列が「あかさたな」で。フリックの候補表示のためにもこれしかなくなるか。
SH-04Aは現状の3列でも結構打ち間違うんだけど、それはキーの縦幅が短いから
だろうから、iPhoneみたく正方形っぽくしちゃえば同じように打てるのかもしれない。
フリック入力のテストみたいなので、ひらがなのみの送信メーラーとか作ったり
するのは無理？後から色々（変換エンジン等）載せるのが難しいとか、最初から
作り直しになるとかだったら別にいいんだけど。
なんか人が増えてきたですね(^-^
>メモ帳みたいな感じでみたいに文章を
>・・・
>だったらいっそ送信専用のメーラーアプリにしてまうのは？電話帳の参照が出来ないか・・・。
一応、可能かなぁ
メールの件名と本文をフリックのエディタで作成して送信に MailAgent クラスのsendメソッドを使うと
入力に使ったエディタが一旦サスペンドして、端末が本来持っているメーラーが起動する。
そのとき入力した内容は端末のメーラーに自動的に挿入されて送信待ちの状態になるので
そこで送り先を選択して送信できる。
送信したら、またフリックのエディタが起動するようになる。
内容を保存すれば端末メーラーの未送信？保存フォルダに保存される
メール専用ならエディタの入力内容をコピペして、端末のメーラーに貼りつけるとかしなくても
シームレスに連携することができるね。
もうちょい書くと
MessageReceived クラスのメソッドを使えば受信フォルダにあるメールを取得出来るのでフリックのエディタ
から返信とかも出来ると思う。
人増えたっつーか俺が結構書いてるわけだが
コテつけた方がいいんかな
キャレットですけど、入力文字は可視、非可視に関係なくTextBoxに出力するように
すればTextBoxが解決してくれないないのかなぁ
TextBoxのsetTextで文字をいれるとキャレット位置に自動的に文字が入るとか・・・
あまいか・・・_(_ _;)
iアプリDX（トラステッド）なら可能だが
そういうツテでもあるの？
また完成する時期は？
これが実現できるならこの機種買いますｗ
i-modeでTextBox使ったことある？
ある程度のプログラミング経験があることはわかる
しかし、iアプリの制限はあまくないよ
ひらがなだけの入力に限れば実現不可能ではない
漢字変換もDOS時代を考えれば（そのレベルでは）実現可能
しかしネイティブアプリとの連携ができないので
TextBoxとクリップボード経由というとても使い勝手の悪いものになっちゃう
ほどの身分でもなく。
お？お？そこまで出来るの？
・・・と思ったら↓
やっぱりDXじゃないと無理・・・か。
そりゃ端末内を参照するのはDXじゃないと無理だよね。
実用的とまでいかなくても、実験的にでも何か出来たらいいなぁ・・・。
だけど作る側がそれで納得出来ても、使うだけの側からすると文句言われたりするんだよね；
iアプリは作ったことないよ(^-^;ゞ
ＪＡＶＡ+swingはＯＫ
端末系だとWindowsMobileで開発はしてた
アプリDX（トラステッド）だけどこれは、機能的に何処までの範囲になるんかな？
GPSとかFeliCaとか電話帳とか個人情報に抵触する類いのもの
審査もきついが継続性とかも求められるから個人レベルではほぼ無理と思っていい
iアプリコンテンツ開発ガイド for star-1.xの
2.2.3 iアプリAPI 以下に書かれているパッケージのクラスしか通常は使えないのかぁ
内部にはアクセス出来ずアプリ単体でどうにかするしかないとなると、
やはりテキスト作ってクリップボードにコピーする程度が限界？
>しかしネイティブアプリとの連携ができないので
>TextBoxとクリップボード経由というとても使い勝手の悪いものになっちゃう
そこはアプリでやる以上割りきってやるのは当たり前かと
みんなそのつもりかと思ってたが
この入力方式をわざわざ使いたいくらいだから別アプリで入力する手間をかけてもOKなんじゃないか？
大分最初の方で言っておいたんだが
ネイティブアプリに対してのコピペはできるのん(^^?
あっ
そこ確認してないや
最悪でも標準入力の初期文字列にコピーさせたい文字列設定してキックすればそこでコピーは可能なはずだけど
直接クリップボードに入れられるかどうかは不明
それくらいは標準でついてほしいとは思うが
