iPhoneDev.

mac fan３月号

に、
非開発者向けiPhoneアプリ開発講座が載っていました。
ちょっと見てみたのですが、非常にわかりやすく書かれていました。

また、http://sites.google.com/a/gclue.jp/iphone-app-docs/
の様なドキュメントを公開されている方もいらっしゃいました。

JavaScriptで作成するライブラリ
（store公開まで行った物もあるようです）もあるようですし、
これからもっと簡単に開発できるようになればいいのですが・・

kuni プログラム

kuniです、

よく観光地にある顔をはめるパネルのような。
撮影の際に常にカメラ画像の上にパネル画像がある
アプリケーションを作ろうと思い、実装していきました。

ですが・・

カメラを取る際、上に画像を重ねることは出来るのですが、

・下に置いているカメラ画像部分（動いている画像）が
一瞬上に来てしまう事が何度もある。
（強引に上に画像を重ねているからか・・。）

・撮影後、「please wait..」の様なアラートが出るが、
上に重ねていた画像の下に来てしまう。
（もちろん、撮影ボタンを押した時にその辺りを操作できればいいのですが、
そのボタンイベントは取れない模様・・）

結果として、
SDKでカメラの挙動自体は操作できない（多分）ので、
こういったソフトは難しいと思いました。

なので、storeでこういったソフトは無かったんですね・・
撮影後に画像をはめる、というやつはあるんですが。

kuni プログラム

Googleが連絡先およびカレンダーをiPhoneと同期可能にしたようです。

Google Sync for your iPhone

http://www.google.com/mobile/apple/sync.html

Microsoft Exchangeサーバを使用するようです。
Google Appsの独自ドメインアカウントは、設定でEnable Google Syncにチェックを入れる必要があるとのことです。

wakasa 未分類

wakasaです。
マイコミジャーナルに面白いインタビュー記事がありました。
新聞フル紙面を配布するiPhoneアプリ「産経新聞」。産経デジタル 取締役 近藤哲司氏のインタビューです。

こだわったのは”レイアウトの価値” – iPhone版「産経新聞」を作った理由


インターネット時代において新聞のようなメディアは不要であるという論までありますが、個人的にはそう考えていません。
新聞社の役割とは紙を刷ることではありません。
裏打ちされた情報量からの分析能力、ソースとソースを付け合わせ導きだして行く新たな情報の価値、それらをもとにニュースソースに「重み付け」を行う。それが新聞社だと思います。

【ジャーナリズムの腐敗／陳腐化などの問題はまったく別な問題ですので置いておきます】

インターネット上での情報の「重み付け」は、Googleの思想に代表されるようにネットワーク上でのつながりが絶対的、それが「重み」であると考えられています。
集合知と呼ばれるようにその軸での評価は機能的で素晴らしいものです。

しかし、ニュースというものにおいて、その軸だけではポピュリズムに寄ったものに陥りやすく、危険な面があります。
ポピュリズムに対するエリートという軸が必要であり、それこそ新聞社が担う役割であると思っています。

レイアウトままというのは新聞社の重み付け、そのエリートとしてのプライドととも取れるかもしれません。
違う方法論も含め、まだまだ模索は続くとは思いますが、物珍しさだけで終わらずに何らかのマネタイズ方法を見つけて事業として成功してほしいものです。

【参考】他メディアでの近藤哲司氏のインタビュー
産経新聞、なぜ無料でiPhoneに「失敗続き」の電子新聞チャレンジに手応え
産経新聞のiPhone版アプリが新聞を変える!?（株）産経デジタルに直撃インタビュー[動画有り]


一時的に誤って公開されてしまったという、新ｓあらたにすのiPhoneアプリもいずれ正式に出るのでしょう。
そちらも楽しみです。

wakasa 未分類

画像処理／認識ライブラリOpenCVのビルド方法が載ってるそうです。
（Thanks : iphone_dev_jp@Twitter）
これを使えば顔の認識などが可能ですがiPhoneの処理速度でどこまでいけるのか…

Cross-compiling for iPhone

http://lambdajive.wordpress.com/2008/12/20/cross-compiling-for-iphone/

wakasa 未分類

kuniです。

ad hocでようやくビルド出来ました。

主な流れは、

http://son-son.sakura.ne.jp/programming/ad_hoc.html


http://max.iamas.ac.jp/2061/?p=1192

などのサイト様を参考に進めました。

その後、転送をしても「検証できなかった」と出て、
iTunesからインストールできなかったので、
調べたら、アプリをビルドする際、
デバイス向けで書き出された物を使っていませんでした・・。
（iphoneシミュレーター向けの物を使っていた。
intel cpu向けにはき出された物が動くわけないですね・・。）

あと、プロジェクトの設定である、「プロジェクト設定を編集」と、
ターゲットの「情報を見る」を選択したときの画面、
同じかと思っていたのですが、違うんですね。
自分はターゲットの方にしか設定していなかったのですが、
動いているので、こちらに設定すればいいようです。

kuni プログラム

wakasaです。

今回は、青空文庫リーダーという確立されたジャンルと言って差し支えないアプリ群の開発技術とその競争について触れたいと思います。
※ここでは個々のアプリの紹介は控えます。

青空文庫とは、著作権の消滅した文学作品、著作権者からの許諾のある作品が並ぶインターネット図書館です。
そのデータを利用したビューアとして、iPhone内でどう展開させていくかというアプリ同士の競争が熾烈を極め、まさに開発技術戦争と言えるものでした。

日本語の「組み」は非常に複雑です。
ルビや傍点、傍線、加えて踊り字など、iPhone標準のAPIでは対応しきれない「組み」が出てきます。

青空文庫リーダーも最初は、横書きルビ無しという単純なリーダーという地点からスタートします。
複雑な「組み」は置いておいて、まずデータを取得し表示するという機能しかありませんでした。
長い作品を読み込ませても落ちないか、データの取得／解析にかかる時間はどのくらいかなど、安定性や処理の効率化での競争をしていました。

その競争に「縦書き」という武器を持って挑むものが現れたことが、転換期となったように思います。
この競争の勝者となる目標が明確に定められたのです。

文庫本のように

いかに文庫本のような「組み」に近づけるか、近づいたものが勝者たるというものです。
もともと紙であった作品のデータですから、再び紙に近づけたいという欲求は当然のものです。
しかし「縦書き」そして「ルビ」対応への技術力、これはデータを取得し解析して、いかに効率よく表示するかといったものとは、全く違うものを必要とすることは明らかです。
句読点や括弧といった約物は横書きと縦書きでは違ってきます。
句読点（、。）ひとつとっても位置さえ変わってきます。音引き（ー）や括弧は向きが変わります。
文中の英文の扱いも考えると、縦書きにすることで処理しなければいけない項目は飛躍的に増えていきます。

「縦書き対応」は高い技術力として、誇っていいそのアプリの「売り」となりました。

縦書きに追従し、いかにルビを正確にふれるか、禁則処理は正確か、「組み」へ挑むことが「売り」となり、その技術を競い合いました。
しかし、文庫本に近づけるという命題そのものには、その技術力「だけ」では超えられない壁が立ちはだかっていたのです。

フォントの呪縛

iPhoneには日本語フォントはゴシック体しか入っていません。
このゴシック体だけではどうがんばっても「文庫本のように」とはなりません。
文庫本はたいていの場合、明朝体の活字が使用されています。
約物をどう処理し、ルビをどこに出して、禁則処理はこうすると、計算上、数値上では近づいたが、表示に関しては限界が見えてしまった。
でも無いものは仕方ない、そう誰しもが思っていたかと思います。

そこにその概念を打ち破るように、今度はフォントをアプリ内に同梱し表示するという方式を持ちこむものが現れました。
この方式はかなり革命的だったと思います。
最初にこの方式を持ち込んだのは辞書アプリだったと思いますが、システムの制約を超える表現を得ることができる道筋を示しました。

このシステムに無いフォントを使うという方式が青空文庫リーダーにも採用されはじめます。
この革命的手法で一気に見た目を文庫本に近づけることができたのです。
一見した印象的なところでは、ほとんど完璧に近いと言っても過言ではないでしょう。
熾烈な競争は一気に日本語縦書き表現の技術を押し上げたのです。

文庫本との戦い

文庫本という目指すところがあったからこそ、ここまで辿り着けたのだと思います。
しかしその大いなる目標に近づくことには成功しましたが、残念ながらiPhoneは文庫本ではないことは明らかです。
近づくことができたからこそ分かることですが、単行本の持つ質感、量感、それらをiPhoneの中で感じることは不可能です。

フリックしてページを送ったところで、紙を１枚めくる質感にはとうてい敵うことが出来ません。
厚みという量感が無いのは、作品を読むインターフェイスとして致命的とさえ思えます。
ソフトウェア的に縦書きや明朝体の壁を崩していけても、そのハード面での壁は崩せるものではありません。

青空文庫リーダーというジャンルが次に持つべき目標は、電子書籍端末としてあるべき姿を描くことでしょう。
文庫本をいかに超えるか。今度は「文庫本そのもの」との戦いです。
頻出の単語のインデックス化など、作品の中身を動的に解析することなどは紙の文庫本では出来ません。
読んだ時間、ページをめくる時間、ユーザの取った行動を記録することもできません。
決定的な質感、量感という武器との差を埋め、超えることさえ出来る新たな武器の可能性は数限りなくあると思います。

次々と進化し続ける電子書籍端末はありませんでした。
日本ではハードウェアから押しつけの電子書籍端末はことごとく失敗しています。
（英語圏ではAmazonのKindleは成功しています。また、ケータイ小説を読む端末としての携帯電話は作品内容が特異としてここでは含まないこととさせてください）
iPhoneとAppStoreいうプラットフォームが電子書籍端末とは何を目指すべきなのか、それを探ることを可能にしました。

ソフトウェアでの競争が続いて行くのであれば、その何かはきっと掴めるはずです。
電子書籍端末の未来を描くことができる青空文庫リーダーに胸が躍ります。


青空文庫リーダー開発者の方々に敬意を表して。



文庫リーダー・「ｓｏRａ」


青空本棚


iBunko


SkyBook

wakasa 未分類

iPhoneDevCampの日本での開催が5月8日～10日に予定されているそうです。

iPhoneDevCamp Japan Discussion List

http://www.iphonedevcamp.org/2009/02/05/iphonedevcamp-japan-discussion-list/

iPhoneDevCamp Japan (English)

http://groups.google.com/group/iphonedevcamp-japan-english

wakasa 未分類

oshimaです。
昨日なぜか更新作業をすっぽり忘れていました。
他ごとで頭がいっぱいだった証拠ですね・・・。面目ない。できるだけ一日一回は更新していきたいと思っています。

iPhoneアプリをレビューしていくうえで、できるだけ心がけようと思っているのは「iPhoneを扱うときに便利な機能を持っている」アプリではなく「iPhoneにしかできない機能を持っている」アプリを紹介していこうということです。
そんなことを考えつつ、今日紹介するのはリバーシ、無料アプリです。
オセロアプリなんですが、強みはネット対戦ができることです。
特に何も考えずアプリをダウンロードし、ネット対戦を選ぶだけで世界中の人たちとオセロができます。
CPUを相手にゲームをするより人間相手のほうがずっと楽しいですし、世界中の人と対戦できるということは、ネットワークさえつながっていればいつ何時でも飽きさえしなければ楽しむことができます。
たかだかオセロですが、これを触って感じたのはiPhoneの環境は気軽にネット対戦をするにはとても優れているんじゃないかということでした。
ネットにあふれているハイスペックを要求するようなオンラインゲームほどは無理としても、必要な回線や場所などの環境を必要とせずそれなりの画質と音を表現できるiPhoneは、PSPやDSといったゲーム機器がやろうとしていることや求められていることを実行してしまったのではないかと思います。
次世代iPhoneはゲーム機としての機能性が増すとどこかで読んだのですが、それがただの噂だとしても納得できる性能をすでに持っています。
他の携帯にも3G機器は多く、回線速度の面ではiPhoneも同等ですが、それらを活かすスペックとマルチタッチをはじめとした操作性や表現の可能性をもったものがいままでになかったと思います。

iPhoneはまだまだこれからどんどん進化する余地を残しています。
携帯ネットワークゲーム機としてどこまで力を発揮できるでしょうか。楽しみです。


iReversi Pro

oshima ソフトウェア

kuniです。

malloc: *** error for object 0×454000: double free
*** set a breakpoint in malloc_error_break to debug
というのが起きてしまい、いろいろ調べて廻ったところ、
「malloc_error_break」ブレークポイントの置き方は
以下のようになるようです。

デバッガを開いて、
右から２番目にある「ブレークポイント」アイコンをクリック。
（ウインドウが狭いと表示されないので、
アイコンがない場合はウインドウを広げてみる）

ウインドウがひらいたら、 左側のリストから
「グローバルブレークポイント」を選択

メインウィンドウの
“ダブルクリックしてシンボルを追加”に、
「malloc_error_break」を入力。

そうするとデバッガが、malloc_error_breakが起きている
部分で停止するようになる。

とのこと。

しかし・・メモリ内の動きで表されるので、
実際何に問題が起きているか分からず、
結局エラーが起きている部分をコメントアウトしていき、
問題が起きている箇所を狭めていったところ、

NSMutableArray *weekArray = [[NSMutableArray arrayWithObjects:@"SUN",@"MON",@"TUE" , @"WED" , @"THU" , @"FRI", @"SAT" , nil]autorelease];

と言ったように、autoreleaseされるオブジェクトを
さらにautoreleaseしていた・・！
これを直したら解消しました・・。


C言語でもそうですが、メモリ周りは相当注意していかないと、
最悪、エラーを追っても解らないと言うことが出てきてしまいそうですね・・。

ガベージコレクションの追加は・・さすがに無いか・・。

kuni プログラム