This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

2010年10月08日02:23 カテゴリiPhone iPhoneアプリの公開手順、ビルドから登録まで iPhoneアプリの公開手順です。公式ドキュメントに日本語のpdfがあるので、それも見ておきましょう。 iTunesConnect_DeveloperGuide_JP.pdf この時点の情報からちょっと変わっているようです。 ビルドが終わってってその先についてです。Apple Storeに登録するまでを解説します。アプリのビルドをまだ行っていない方はこちらの記事を参考にファイルを準備して下さい。 【iTunes Connectへ登録】 ・iTunes Connectへ移動。読んで同意する。 ・「Manage Your Applications」の「Add New Application」をクリック ・「Primary Language」は「English」がおすすめ。（これを選択すると

無事にアプリをリリースできたので、申請までの記憶をたどって残しておきます。 アプリの登録iOS Provisioning Portal で 以下を操作(1) App IDs を登録 ユニークになるようなIDを決めて登録する。 CrossBacklogの場合は、私が持っている sorausagi.org をつかって org.sorausagi.CrossBacklog にしました。 前にランダムな英数字が振られて *******.org.sorausagi.CrossBacklog のようなのがApp IDに。 (2) Distribution Provisioning Profiles を登録 App Store用のProfileを作成する 出来上がった Provisioning のファイルをダウンロードして、ダブルクリックでインストール iTunes Connect で 以下を操作(3)

寺子屋サルでき新サーバーへようこそ！切り替え作業は無事完了しました。不具合が見つかった場合はすぐ教えてくださいね。 【サルできBOOKS、新刊続々】 ・比嘉加津夫さん 『比嘉加津夫 書評誌 Myaku 2010年3月 Vol.1』 ・よもぎ史歌さん 『晴明たん』 【サルでき公認アプリ、新着】 ・auratioさん 『ジャンケン神』 ・くみんさん 『CatShuffle』 ・かめくすさん 『マネー探偵』 ・GT.BLEDSさん 『バスケ3作品』 ・ヤマチャンさん 『親指アメバ』 ・kishiharaさん 『いまにゃんじ？』 ・寺子屋の運営費を稼ごうプロジェクト、1月の集計が出ました。祝！1万超え！目指せ専用サーバー。 Xcode 4 Now AvailableXcode 4 is now available to all Mac and iOS Developer Pr

UINavigationBarをUINavigationControllerではなく、UIViewController等に独自に実装する場合、以下のようにします。 // ナビゲーションバーを生成 UINavigationBar* navBarTop = [[UINavigationBar alloc] initWithFrame:CGRectMake(0, 0, 320, 40)]; navBarTop.alpha = 0.7f; // ナビゲーションアイテムを生成 UINavigationItem* title = [[UINavigationItem alloc] initWithTitle:@"Title"]; // 戻るボタンを生成 UIBarButtonItem* btnItemBack = [[UIBarButtonItem alloc] initWithTitle:@"Bac

Advice from an experienced Appreneur, Mentor and Coach. UIWebView has very few instance methods. One of them is stringByEvaluatingJavaScriptFromString, which very powerful and unfortunately poorly documented. (This is literally the extent of Apple’s explanation: “Returns the result of running a script.”) Let’s explore this mysterious method with a couple of examples. A trivial example of how to us

iPhone/iPod touch iPhone/iPod touchはAppleから発売されているスマートフォンおよびミュージックプレイヤー。どちらも世界的に普及しており、Apple Storeからデジタルコンテンツを購入して利用できる。 当初は一般ユーザーはAjaxアプリケーションしか開発できなかったが、200８年2月に「iPhone　2.0」が公開され、ソフトウェア開発キット「iPhoneSDK」も公開となり、ネイティブアプリケーションも開発可能となった。 開発したソフトウェアが有償の場合は30%をAppleに支払い、残りの70%を開発側で手にすることができる。無償の場合はAppleへの支払は不要となる。 ネイティブアプリケーション 統合開発環境として「Xcode」、プログラミング言語として「Objective-C」、アプリケーションフレームワークとして「Cocoa

トップページ > iPhone/iPad > 実機転送時に「the program being debugged is not being run」というエラーが出たら 有効期限の切れたプロビジョニングファイルがデバイスに残っている 有効期限の切れたプロビジョニングファイルが デバイスに残っていると Error launching remote program: security policy error. Error launching remote program: security policy error. The program being debugged is not being run. The program being debugged is not being run. みたいなエラー文がコンソールに出力されているようです (絶対かどうかはわからないけれど) 有効期限

参照カウンタ方式は、一般的なメモリ管理手法として、よく知られているので、wikipedia などを説明をご覧頂きたい。 メモリオーナーシップ Objective-C では、メモリオーナーシップという概念に基づき、メモリ管理をします。メモリオーナーシップとは、メモリの所有権のことです。すなわち、あるインスタンスには、その所有権があるということです。誰が所有するのか？それもインスタンスです。あるインスタンスは、他のインスタンスに所有されるのです。ただし、あるインスタンスの所有者は、複数存在することもあることに注意が必要です。 この所有関係が、直接、参照カウンタの関係とつながります。つまり、所有者が、所有されるインスタンスの retain count を+1し、所有者がインスタンスの所有権を放棄すると、インスタンスの retain count を-1します。これにより、あるインスタンスが所有され

最近少し凝ったiPhoneアプリを作り始めたせいか、メモリ管理について気になったのでXCodeに付属の「Instruments」というツールを使ってみた。 InstrumentsはiPhoneアプリだけではなくCocoaアプリ全般に使えるメモリの利用状況やCPU使用状況などを表示してくれるツールで、今回はiPhoneアプリのメモリリーク監視に使ってみました。 使い方は単純で以下のとおり XCodeを起動して監視したい対象のアプリのプロジェクトを開く 「ビルド」→「クリーニング」で一旦プロジェクトをクリーンにする プロジェクトをクリーニングしないとコード変更後の内容が反映されていないアプリケーションの実体で起動されてしまう場合があるので注意してください ビルドしてアプリケーションの実体（*.app）を作成 「実行」→「パフォーマンスツールを使って実行」→「Leaks」をクリック 起動して１０

Xcodeに付属している解析ソフトのInstrumentsはすごく便利．CPU負荷やメモリリークを数値で確認できるので，デバッグには不可欠なソフト．しかし，検索してもあまりでてこない（名称が一般英単語と同じだし，セイコーインスツルが真っ先にくる）ので，使い方というか解析風景のキャプチャをYouTubeに挙げた．注意点はInstrumentsから対象アプリを起動すること．これでチェックしていけば，メモリリークは回避できる． （追記） Instrumentsでも確認できないメモリリークがあった．autoreleaseが上手く動作していないと，Live Byteが適正内でも落ちる．その対策はソースコードを眺めて，autoreleaseを使わないように書き換えるか，NSAutoreleasePoolを使って手動でリリースする． NSAutoreleasePool pool = [NSAutorel

iPachiで起きていた不具合なのですが、 特定の画面を表示中にメモリ不足に陥り didReceiveMemoryWarningを受け取ると アプリがクラッシュするという問題をついに 解消しました。 didReceiveMemoryWarning後にクラッシュするので メモリ管理でどこかがおかしくなっているのだろうとは 予想がつくのですが、いかんせん貧弱なエラーメッセージの ため、まったく発生元がつかめませんでした。 EXC_BAD_ACCESSとか言われてもさっぱりわからんです。 が、すばらしい記事をみつけました。 NSDebugEnabled これでクラッシュをおこしているオブジェクトの生成場所を 特定できるので、格段にデバッグ効率があがります。 というわけで、エミュレータでのメモリ不足時のシミュレートと デバッグのための設定をまとめます。 エミュレータでのメモリ