Hatena::Groupiphone-dev

f-shinの日記 このページをアンテナに追加 RSSフィード

ああああ

2009-02-18

iMovatwitterがリリースされていました。

02:19 | iMovatwitterがリリースされていました。 - f-shinの日記 を含むブックマーク はてなブックマーク - iMovatwitterがリリースされていました。 - f-shinの日記 iMovatwitterがリリースされていました。 - f-shinの日記 のブックマークコメント

激戦区のtwitterクライアント市場に、無謀にもモバツイッターのiPhoneクライアントを投入いたしました。

みなさん情報、アドバイスありがとうございました。 m(__)m

ちょっとここ数日元気がなく、どうも自信が出てこないので、まともにプロモーションをする気力がないのですが、とりあえず今回は有料版のプロセスを経験することが何よりもの目標でした。

深津さんのお話を聞いていてやってみようと思ったのがきっかけです。


ここではPending Contructについてリリースまでのプロセスをメモしておきますので、ご参考いただければ幸いです。

【1/29】 アプリがready for saleになって、pending contructとなる。もちろん元データは日本語です。

【1/29】 にiTunes connectのお問い合わせに「Company Addressのところが日本語文字化けしてるから直し方を教えて」という内容を送る

【1/31】 に返信が来て、devprograms@apple.comに問い合わせるようにと連絡が来たので、そのままの内容を転送

【2/3】に、検討するから待ってねという返信が来る

〜そのまま一週間待つ〜

【2/9】に、1週間前にレビューするって言ってた内容はどうなりましたか?というメールを送る。

【2/10】に、日本のDev Connectionの担当の人から、iPhone Dev Centerは直しました、iTunes Connectはちょっと待ってねという連絡が来る。

そこから数日で、iTunes Connectが修正されたのを確認

さらにそこから数日、Pending Contructの進捗なし。

【2/17】に、iTunesの契約担当宛メールに文字化けが直ったから、Pending Contructの処理を進めてねと念押しを送る。

【2/18】に、アプリがリリースされていた模様。

なお、W-8BENについては、昨年末に送ってありました。


Pending Contructに油断してたので無料版を何も手をつけていませんでした。

同一ソースを共有して、無償版と有償版を管理する方法って、どなかたか書かれてましたよね。

探して、無償版についても作業を進めたいと思っています。

http://tinyurl.com/bljquy

(画像が古いままなんだよなぁ・・・)

2009-01-22

見えるぞ・・!私にも敵が見える! (autorelease / release完結編)

23:50 | 見えるぞ・・!私にも敵が見える! (autorelease / release完結編) - f-shinの日記 を含むブックマーク はてなブックマーク - 見えるぞ・・!私にも敵が見える! (autorelease / release完結編) - f-shinの日記 見えるぞ・・!私にも敵が見える! (autorelease / release完結編) - f-shinの日記 のブックマークコメント

前にreleaseの使い所がよくわからんと書いたのですが、なんとなく理屈はわかってるつもりだったものの、どうにもカラダが覚えてないなぁと思ってたので、カフェで以下のエントリーをじっくり読んだら敵が見えるようになった。

releaseの使いどころ

http://blog.livedoor.jp/faulist/archives/1051536.html

Cocoaでいこう! Macらしく 第10回」から数ページ読む。

http://www.remus.dti.ne.jp/~yoshiki/cocoa/ed1/10/index.html


ガベージコレクション脳が板についたままautoreleaseに頼るのがそもそも間違っていることと、autoreleaseの解放処理はイベントループでほいほい実行されているからこそ、メソッドを抜けた後で、うっかりミスするとあっさり落ちるんだ、というあたりが見えたら、ソースの見え方が変わった感。たぶんね。

2009-01-21

ダイアログ窓の作り方

09:47 | ダイアログ窓の作り方 - f-shinの日記 を含むブックマーク はてなブックマーク - ダイアログ窓の作り方 - f-shinの日記 ダイアログ窓の作り方 - f-shinの日記 のブックマークコメント

■現状の問題点:

実機で写真を2枚撮るとアプリが落ちる

■現状:

写真を撮ったら、その写真を縮小表示してコメントをつけられるダイアログウインドウ的なものをサブウインドウとして表示している。

■問題点:

当然、初回表示時は、viewの初期化処理が走るが、写真を2枚撮った後に、再度、viewの初期化処理が走っていて、その初期化処理終了時に、カーネル保護違反みたいなエラーが出て落ちている模様。

単純に「そのウインドウを開く/閉じる」というボタン(が別にある)では、viewDidLoadは走らない。

初期化手順:

viewDidLoadイベントの中で、viewの初期化処理が走っている。

その初期化処理が二度走るとエラー???でも、そこを二回実行しないようにしてもうまく動かないので、初期化内部の処理に地雷がある?

TODO

1.二度目のviewDidLoadはどういうタイミング、理由で実行されるのか?を調べる。

2.一度目の実行はOKなのに、二度目で落ちているなら、二度目の実行で支障のあるコードになっているわけだから、そこの不整合点を調べる。

(やっぱり、autoreleaseあたりなのかなー)

3.その他

・そもそもviewDidLoadでviewの初期化をしてよいのか?

ダイアログウインドウを閉じる処理の方で開放しておくべきメモリはないのか?

・むしろ必ずviewDidLoadが走るような毎回初期化するような状態にした方が良いのか?

・そもそもそういう方法で別窓を実装して良いの?(addSubview、removeSubView?あたり。夏ライオンの書き込み窓を参考に。)



ここが解決できたら、ほぼほぼアップできる見通し。

tmokitatmokita2009/01/21 10:29お世話になってます。

全く同じ現象かはわかりませんが、似たようなことがあり
軽く調べて根本的な原因はよくわかりませんでしたが
簡単に言うと、viewが作り直されている感じです。
(viewのアドレスが変わっていたので、たぶん)

なので、viewがそのままで存続していることを期待して
変数とかオブジェクトとか参照していると、落ちる原因になります。

なんの裏付けも無い超直感ですが、このviewが再構築される現象は
残メモリの状態で変わってくると思います。

自分の場合、具多的に発生したフローは
1. ボタン押下でviewCtrlからUIImagePickerViewを表示
2.写真取り終わったコールバックで親に戻す
3.UIImagePickerView release
4.親にもどる ← ここらへん

また、UIImagePickerView以外でも画面遷移の際に
(NavigationCtrlのpop/pushとかでも)発生しました。

で、自分の場合は、処理フローを見直して
viewが再構築されても問題ないようにして回避しました。
ただ、これが正解かどうかは正直わかりません。。。
というかむしろ自信ありませんが。。。

tmokitatmokita2009/01/21 10:44先のコメ書いたあと思ったのですが、view retain しておけば回避できるかもしれません。
って、これも何も試していない超直感ですが。

fladdictfladdict2009/01/21 16:23えーとですね、それはカメラ系アプリを作るとよく発生する地雷の1つです。

UIViewControllerサブクラスはディフォルトは、メモリ不足のイベントを取得すると、自分のviewがsuperViewを持っていない場合、viewを開放するという凶悪仕様になっているのですね。

なのでメモリが足りないと、ビューが開放され、またビューを参照する瞬間にビューが生成され・・・ といった具合にビューが多重生成されるわけです。

打開策としてはメモリ不足の警告を無視するのが1つ、もう1つはビューが完成したときに行った処理は全部、ビューが強制開放されるときにreleaseされるようにすることです。

ここら辺をやっとかないと、無限メモリ不足や、nilによるBADAccessで死んじゃいます。

fladdictfladdict2009/01/21 16:27ToyCameraやQuadCameraの場合、アプリのメモリ最大限使用量した場合もアプリが落ちないことが検証済なので、一度作成したviewはメモリ不足イベントを受けても開放しないようにしています。

ku-sukeku-suke2009/01/21 17:27僕も今週それではまりました。新しいビューを作って、何もせず閉じると問題ないけど、たとえばAddressBookを読み込んだ位下後閉じるといろいろ消えてて焦りましたw
viewの再構築イベントをどうハンドリングするかがいま悩み中です〜

tmokitatmokita2009/01/21 18:38f-shinさんの場所でお礼いうのもなんですが、
>fladdictさん
半分勘でやってたことだったので(おぃ、とても参考になりました。
ありがとうございます。

場所借りてしまってすみません。m(_ _)m >f-shinさん

f-shinf-shin2009/01/22 03:18ありがとうございます。
元ウインドウの参照までごっそり消えていたので初期化の仕方そのものを変えて行かなくてはいけないのは参りました。

fladdictfladdict2009/01/22 18:12外部に作った参照が吹っ飛ぶのがアレなんですよね… viewの参照を外部に持つのをやめて、viewControllerからgetter経由で毎回取得するようにすると view がない場合自動生成されるので、ちょっと楽になるかと。

AnjarulAnjarul2012/05/30 06:12That's a sikllufl answer to a difficult question

afgczggbafgczggb2012/05/30 19:42trfJNN <a href="http://nslecepemgwz.com/">nslecepemgwz</a>

lxxtgpflxxtgpf2012/06/01 03:427ERurV , [url=http://esyyvjeqnmjx.com/]esyyvjeqnmjx[/url], [link=http://fxdwknvpethw.com/]fxdwknvpethw[/link], http://zolgovimcpfa.com/

2009-01-20

カメラで連射・・・できるんだよねぇ・・・。

00:39 | カメラで連射・・・できるんだよねぇ・・・。 - f-shinの日記 を含むブックマーク はてなブックマーク - カメラで連射・・・できるんだよねぇ・・・。 - f-shinの日記 カメラで連射・・・できるんだよねぇ・・・。 - f-shinの日記 のブックマークコメント

今、自分で作ってる奴が、写真を2枚撮るとメモリが枯渇して落ちるんだけど、写真を連射できるんなら頑張れば大丈夫だよね。

WebViewを組み込んでる部分がメイン機能なんだけど、Webページをクリックするたびに利用メモリが増えていくという、なんとも言えないプレッシャーが。

Instrumentsで見る限り、そんなにメモリリークが検出されないんだけど、その代わりメモリを暖め過ぎなのかなぁ。

⇒これバグだった。次に書く