2011年02月10日

願望と絶望の狭間で

とりあえず今のところはうまく動いているように見える我がアプリですが、まだ絶対罠がありそうで怖くて公開に進む気持ちになれません。
「想い出作り」でいいや、という気持ちもありますが、釈然としません。
今回結局レコードの特定でnullを使うのではなく、レコード作成時に必要なカラムはすべて空白を打ち込むという方法をとったのですが、やっぱりnullかどうか確認するのでも良かったのではないかとも思え、いやいや、現在実装していない、これから作る予定の項目移動機能にとってはやはりnullに戻すより空白かどうかの判定の方が楽だとも思ったり、千々乱れる思いです。
データ構造自体は変えていなくても、カラムの性質が変わると後々修復不可能なデータとなる可能性もある訳で、そうなると例によって手に負えなくなる可能性があります。

こういう判断ってずっとプログラムの勉強を続けていけばなんとかなるのでしょうか?
僕自身はそうは思えないのですよね。
勉強を始めるのが遅すぎたということを別にしても、ネット上で色々解説を書いてくださっているプログラマの方々の書いている内容が、勉強を続けただけで理解できるようになるとは、自分では思えない訳です。

そもそも市販の入門書に書かれている内容と実際に使い物になるプログラムの間に深い断層があるとしか思えません。
繰り返しになりますが、どう考えても今後自分がクラスライブラリを平然と読み下せるようになるとは思えませんし、より数学的なアルゴリズムを抜きにしたとしても、高度なプログラミングを理解することすら適わないのは確実です。
もう少しハードルを下げたとしても、ネット上の解説すら理解できるように思えないのではお先真っ暗です。

しかし、何故かとある理由でCreativeのZii○を買ってしまい、今ここにあるのですが、これでマイアプリを動かすと機能的に実にフィットしそうで非常に良い感じ。(横画面に対応していないので、実際はイマイチですが)
将来的に実現を夢見ている(た?)機能が伴えば、最高だと思えるのですが、(自分の能力の制限で)実現の可能性が低すぎて挫折せざるを得ないかと思うととても残念です。

こんな理想と現実、願望と絶望の狭間で悩みながら、基本的な機能が動作するようになったものをこんなところで反故にするのかと自問する毎日から抜け出したい今日この頃。
(うっ!さらにいつの間にかIllegalStateExceptionというのがログに出るようになっているのが発見されました。この障壁は抜けられなさそう……)


※Zii○のoを丸にしたのは当該機種のレビューを探している人の検索に引っかからないため。(理由は前回のエントリーの通り)
でもZii○、なかなか良いですよ。iPadにはまる人の気持ちが分かりました。
写真がなんか変な表示になったり、キャリブレーションしてもキーボードの打鍵ポイントなどがずれる(横画面でエンターが入らないっ!)とか、マルチタップが使えない、マーケット未対応(Android携帯に普通に入っているギャラリーとかYoutubeアプリが入っていないのはかなり辛いですが)なことなど差し引いても楽しいです。
自分専用として買った訳ではないのと、本当は「もうひと越え」と思ってましたが、これで2,4800円(ポイントを考えるとAmazonよりヨドバシの方が安い)なら結構良い買い物かも。
ポイントはHoneyComb対応のタブレットが出るまで貯金しておきましょう。(笑)

posted by 白虹 at 00:15| Comment(0) | TrackBack(0) | Android開発

2011年02月09日

ドミノ倒しのように!

やれやれ。
ホントにもう半分諦めているような感じですが、前回のエントリーを書いたのちも一カ所修正したら、まるでドミノ倒しのごとくに次々とおかしくなり、ようやく「直った!」と思って翌日動かしてみると別の部分に不具合が出るといったことを繰り返してました。

それというのも、またもSQLについての認識も甘かったことから来ている訳ですが、これに関しては最初から大丈夫だろうかとうすうす心配していたのが表面化した結果でした。

当初データのないカラムは使用しない予定だったのですが、(最終)テストで誤動作が出た結果レコードの判定に必要になった(気がした)のです。

SQLiteでデータのないカラムを調べるには「カラム名 = ""」などではなく、「カラム名 is null」だとのことで、これを複数ある判定箇所に設定するだけでもう訳が分からなくなりました。
そもそも、劣悪なPC環境であることもありますが、for文で複数カラムの抽出条件を生成するSQL文がどのように構成されたか見るのが面倒。
頻繁に文字列連結する場合文字列を+でつなげるよりStringBufferが、StringBufferよりStringBuilderの方が速いらしいのですが、StringBuilderだと余計見づらいので、SQL文をLogで出力するのですが、エミュレータはエラーで起動できない方が多いし、実機を繋いでいても何故かLogがはき出されないことがしばしば。
それにデータベースの状態をeclipseから直接閲覧できれば良いのですが、Androidはできない(んですよね?)のが残念。
ファイル・エクスプローラーからPullしようとしても、これも良く失敗するので、イライラの原因に。

四苦八苦しながら、データ一覧のSQL文を直したと思ったら今度は重複判定のSQLがおかしくなり、重複判定を直したら、データ追加が、追加を直したら編集が……と無間地獄のよう。
賽の河原じゃあるまいし、何度直せば良いのだ!とホトホト嫌になり、いまはようやく動いたかのように見えますが、きっとどこかに罠があるに違いないと思うと、やはり公開する自信がなくなるのでした。

マーケットで公開せず、自分のWebとかで公開して野良アプリとして……などという考えも浮かばないではありませんが、このブログからして定期的に見ている人は(不思議にもブックマークから来ている?方がいますが)ほとんどいないはずなので、意味がない。
そもそも、このブログは誰かに見られることを前提としていませんからね。

……そういえば、見ている方がいても「こいつ、ホントにバッカだなあ」と優越感に浸るために見ているのでしょうから、ここで迂闊にあまり為になる可能性のあることを書いてはいけないな、と思いました。
たまに、うまくいったことを書いているのが他の人の参考になるかどうかはさっぱり分かりませんが、万が一検索で上位に表示されたりしたら、(王様の耳がロバの耳であることがバレて)「捕らえられて死刑になってしまう!」(笑)。

話が逸れましたが、SQLなどを一カ所で集中管理できれば良いのですが、AlertDialogの時の失敗で痛い目を見ているし、そもそも何故メソッドに分かれているか、という前提を覆すことにもなるので、ちまちまと直すしかないのでしょうか?
でも、あまりにもセンシティブになりすぎて、今回のように脆さを痛感することになるので、今現在正しく動くようになったように見えますが(明日はまた不具合が見つかるかも)、本当はなんとかしなければいけないんでしょうねえ。
それに動けば良いというものでもなく、シンプルに美しく、合理的でないと良いコードとは言えないのでしょうけど、このままでは本当に公開できそうにありません。はぁ……

posted by 白虹 at 00:43| Comment(0) | TrackBack(0) | Android開発

2011年02月06日

やる気0

えーっ、先日のエスケープ文字の関連から文書のタイトルに使用できる文字を制限しようと思ったのが運の尽き。
各ファンクション(新規作成とか編集)から呼び出す際に使っているAlertDialogを間違えやすいし、コードがゴチャゴチャしているのが嫌なので一つにまとめようとしたところ、これがドーシテモうまくいかず、丸二日程ああでもない、こうでもないとやってました。
そのため完成目前だったはずが、むしろグチャグチャになって、完成など遙かに遠ざかってしまったのでした。

いや、ホントに頭が悪い。
もうやる気をなくしました。
最初から分かってはいましたが、僕のプログラミングに未来はない!
機能拡充には色々夢は広がるところでしたが、根本的に無理ですね。
技術力をつける云々の前に、技術を培う土台が脳みそに欠けてます。
AlertDialogをまとめるだけでどうしてこんなに時間がかかるんだと自分で思いますし、傍から見たら単純なメモ帳アプリ一つ作るのにどうなってんの?と思われますよね。

とりあえずAlertDialogはwhile文の中で使えない(当たり前?)ことは学習し、途中で部分的に諦めて禁止文字のチェックと重複チェックのメソッドのみまとめて、AlertDialogは各ファンクションで設定することにしました。
本当は各ファンクションの処理を呼び出すところを含めて一つのメソッドにまとめればできるはずだとは分かっていましたが、途中まで書いた部分を大幅に反故にして書き直す方が精神的に苦痛なので。
(かなり書き直しが激しかったので、テストやり直しなのも充分苦痛ですけど)

それでもこれで鉄壁の処理になったようにはまったく思えず、コードの行数がむしろ増えているような気がするのは何故でしょう?
しかも、文書の編集の場合のタイトルチェックメソッドの呼び出し部分は、すごく試行錯誤した程複雑(に自分では感じる)なものになってしまいました。
それから、禁止文字についても充分に深い根拠があるとは思えぬまま"$%'*,_と/に決めたのも大丈夫か不安です。+とか.とかも正規表現で使われるのでできれば禁止したいのですけど、文書タイトルにあまり制限も加えたくないので、一番危なそうに思える文字を適当に追加したというところ。

さらには、その後初期の段階でクリアしておかなければならなかったはずの論理的欠陥も見つかったりして、数日間やさぐれてました。
(ちなみに僕がフローチャートとか書いてキチっとやっているなどと思ったら大間違いです(苦笑)。というか書けないんですよね。それに手書きでもアプリを使っても大変面倒くさいし)

ああ、もうマーケット公開なんて諦めて、自分だけで使おうかな?
ある意味世界に一台だけの(?)機能を持った携帯になるし。(笑)
例えば、自分と違ってどんな凄いアプリでもあっという間に創れてしまう人がいたとして、その人が自分のためだけにアプリを創って使っていたら、最強のオレ様専用最強携帯!ってことで自慢できるのでしょうね。
まあ、そこまでいかなくても、自分で便利だと思う機能を自炊して(バグはこっそり避けて)使っていたら、それはそれである意味ちょっとかっこいいかも。
もちろんオリジナリティが侵されない(他に同様の機能のアプリがない)限りにおいてですけどね。

僕の作っているものはもう似たようなコンセプトのものがある見たいですけど。

とりあえず、今日覚えたこと。

・AlertDialog.Builderでキャンセルされて困る場合はnew AlertDialog.Builder(this).setCancelable(false)でキャンセルを防げる。

でした。

posted by 白虹 at 23:44| Comment(0) | TrackBack(0) | Android開発