2013/05/08

staticライブラリを含むcocoapodsを使うときのメモ

staticライブラリを含むcocoapodsを使うときは、アプリ側のbuild settingsに"$(inherited)"を追加しておくといい感じ。



podのCrittercismSDKを使うときにBuild Errorになって探したところ、

CocoaPods@githubでそれっぽいコメントを発見。

試したところ期待どおりに問題が解消しました。

これでいつも通りにpodsが使えます。


公式ガイドのFAQ 1が該当するのかも。

2013/04/11

bundlerから始めるruby

久々にrubyを触ってます。難しいですが書いてて楽しい。

以前はシステムで共通的に利用されるgem(要root権限)を使ったり、自分のアカウント用にrubygemsをインストールして使ったりと不便でした。
(rvmのgemsetで管理とか話は聞きましたが、大変そうだったのでスルーしました)

ここでbundler (http://gembundler.com/) の登場。

bundlerを使えばプロジェクト毎にgemを管理できるように。これでモヤモヤしてた気持ちがスッキリ。

目的:

bundlerを使ってプロジェクト毎にgemを管理する感じにしたい。

対象:

プロジェクト毎にディレクトリ作って、そこにファイルをまとめたいruby使い向け。
(ただし、railsとかtemplateを作ってくれるコマンドがある場合はそっちを使う方がいいはず)

環境:

ruby-1.9.3p392, bundler 1.3.5

こんな風にするといいぽいと思った事を書いてみます。

準備

 1. とにかくbundlerのgemをインストール

$ gem install bundler

最初の手順


 1. プロジェクトのディレクトリを作ってそこに移動

$ mkdir ${project_name}
$ cd ${project_name}

 2. bundlerの初期化

bundle init

 3. プロジェクトローカルでgemを入れておく場所を作る

$ mkdir vendor/bundle

 4. 最初のbundle

$ bundle install --path ./vendor/bundle

(.bundle/config に --pathを保存されて、以降のbundleコマンドで有効になる様子)

それ以降(必要なときに)

 1. なにかgemが必要になったらgemを追記

$ vim Gemfile
 2. bundleコマンドで必要なgemをプロジェクトローカルにinstall
$ bundle update

mosh + 公開鍵認証

遠くにあるサーバへsshでリモート接続して作業してると、たまにキー入力に対するレスポンスが悪くて悲しくなります。

 そんなときはmosh(mobile shell)を使うと少し悲しさが減ります。

便利機能や設定方法はgoogleに聞いてもらえればいいのですが、普段使っているsshの公開鍵認証の使い方が見当たらなかったので書いてみます。

こちらの~/.ssh/configの設定の方が普段使うには便利そう.

目的:

   ssh+公開鍵認証 を moshでも使いたい

方法:

mosh --ssh="ssh -p $(port) -i $(private_key)" user@host

補足:

  moshには"--ssh" オプションがあってmoshの中でsshセッションを開始するときに実行するコマンド名とオプションを渡せる様子です。

 ということで、普段こんなコマンドを叩いている人は、
ssh -p 3001 -i ~/.ssh/id_rsa user@hostname

  こんな感じに置き換えて、クライアント側で実行するといい感じです。
mosh --ssh ="ssh -p 3001 -i ~/.ssh/id_rsa" user@hostname


2013/01/11

分かりやすいiOSアプリのリンクURLの作り方

日頃お世話になっているStackOverflowからのメモ。

元記事:How to link to apps on the app store


AppStoreで公開されているiOSアプリへのリンクURLを作る方法。

Company Name, Application NameからURLが作れるらしい。

  • 特定のiOSアプリへのリンク先URL
    • http://itunes.com/apps/#{appname}
  • 特定のdeveloperが作っているiOSアプリのリストへのリンク先URL
    • http://itunes.com/apps/#{companyname}
  • 特定のdeveloper/iOSアプリへのリンク先URL
    • http://itunes.com/apps/#{companyrname}/#{appname}

URLの先頭が"http://"のままだと、リンク先を開いたときにリダイレクトが入るらしい。

リダイレクトさせたくないときは、URLのスキーム部分を"itms-apps://"にする。

#{appname}, #{companyname}の部分は適宜入れ替えて使う感じの様子。


例) chrome appへのリンク先
メモ:"Google, Inc." => "googleinc"、"Chrome" => "chrome"に変換されてます(ルールは下記参照)


ここの#{appname}, #{companyname}は以下のルールに従ってフォーマットする必要があるらしい。
  1. whitespaceを削除
  2. すべて小文字に
  3. copyright(©), trademark(™), registered mark(®)は削除
  4. "&"は"and"にすべて置換
  5. 以下の記号は全部削除
    !¡"#$%'()*+,\-./:;<=>¿?@[\]^_`{|}~
  6. Replace accented and other "decorated" characters (ü, å, etc.) with their elemental character (u, a, etc.)
    (最後の文はしんどかったのでそのまま。雰囲気で感じてください)

詳しくは、以下のサイトを。



2012/10/29

Mr.Childrenの出したニューアルバムのTestCase

Mr.Childrenの出したニューアルバム「[(an imitation) blood orange]」の名前が(objective-c的に気持ち悪いので)動くかどうかTestCaseを書いてみた。


きちんと動いた。

2012/10/07

「シェアする/共有する」という表現


まだまだ不勉強なのですが、個人的に感じている気持ちをメモしてみます。

最近いろんなサイトやアプリケーションで目にする「シェアする/共有する」といった表現が気持ち悪いなーと感じてます。


人が「すばらしい」と思う情報を見つけたときは、こんなフローがあるのではないかなと。

1. ユーザが何かの対象に対して抱いた感情とか気持ちが沸き上がり、
2. その気持ちから何かのアクションが生まれ、
3. そのアクションの結果がユーザのネットワークを通して周囲の人に伝播する。

「シェアする/共有する」は、「情報を周りの人に伝えることが目的の、感情や気持ちを表現しない単純な動作」という表現と感じてしまいます。
そのため、上記のフローの最初にある「人の感情や気持ち」が欠けてしまっている気がして、これが個人的に気持ち悪く感じている理由な気がしています。

そんな理由から、個人的にはfacebookのlikeやgoogle plusの+1、昔のdiggとかであったthumbs up/downとかの表現はすばらしいと思います。


「シェアする/共有する」は、コンテンツをいろんな人に伝えてほしい情報提供者側の気持ちが多く込められていて、ユーザ視点からの表現ではない気がします。

いろんなサイトで安易に「シェアする/共有する」操作を追加するのよりも、提供するコンテンツにあった感情も表現できるアクションをつけてあげるといいのではないでしょうか?

2012/09/29

カスタムUIActivityのアイコン画像

iOS6でUIActivityViewControllerが追加されました。


これまでテキストや画像などなどに対するAction(iOS6でのUIActivity)をユーザに提示する簡単な方法としてUIActionSheetを使う方法がありましたが、それに変わる手段としてUIActivityViewControllerが追加されました。

アプリケーションでカスタムUIActivityを追加する方法も提供されており、
すでにCocoa ControlsでInstagramへshareするDMActivityInstagram for iOSが登録されているようです。(動作確認はしてないですが、カスタムActionが気になる人はコードを読んでみましょう)

ここでカスタムActionのアイコン画像について少し調べたのでメモ。

MailやTwitter、Facebookのアイコンのようにカラフルな透過領域のないアイコン画像を用意しても、白いグラデーションのかかったアイコンになってしまいます。


透過領域のないアイコンを使うと、塗りつぶされた感じに。

UIActivity Class Referenceにある activityImageメソッドの説明をよく読んでみると、いろいろと書かれてまして、試してみた結果としては以下が判りました。

iOS6で用意されているCopyするActionのアイコン
  • アイコン画像の透過領域はマスクされて金網っぽい画像が表示される。
    (上のcopyアイコンでいうと、外枠と内側のファイルっぽいアイコンの間の領域)
  • アイコン画像の色は無視されて単一色のグラデーションがかかった感じになる。
    (上のcopyアイコンでいうと、ファイルっぽいアイコンの色)
補足:アイコン画像はiphone用に43x43(86x86 for Retina Display)、ipad用に55x55(110x110 for Retina Display)がそれぞれ必要みたいです。

つまり、用意する画像ファイルは、「背景透過にしてアイコンを書いた画像」を用意するとcopyアイコンのようないい感じになるようです。(アイコンは何色で書いても、グラデーションのかかった単一色になるようです)

背景透過にアイコンを書いた画像だといい感じに。

とりあえず、今判った範囲ではMailやTwitter, Facebookと同じようなカラフルなアイコンは追加できない様子でした。

残念。

2012/09/27

DashにiOS6のdocsetを追加する方法

DashというアプリにiOS6のdocsetを追加する方法

Dashについての説明は他の場所に譲るとして、
ここでは自分の環境で起きてたiOS6のdocsetがDashに追加できなかった件の対処方法をメモします。

0. 最初の状態

Xcode(4.5)をインストールした後でもPreferenceからみるとiOS6のドキュメントはインストールされた状態と表示されていました。

  このときのiOS6のdocsetは以下のようなパスにあると表示されてました。
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Documentation/DocSets/com.apple.adc.documentation.AppleiOS6.0.iOSLibrary.docset
パスをみると判るように、Xcode.appのサンドボックス内にあるファイルになってます。
そのため、DashのPreferences->Docsetから"+"ボタンで表示されるfinderから選択できずに困っていました。

開発者さんに聞いたところ「finderでひらいてdocsetをダブルクリックすればいいよ」とのこと。

いろいろ試してfinderで開いてdocsetをダブルクリックしたり、itermからopenコマンドで開いてみたりしてみたのですが、「おかしなdocsetみたいだからダウンロードし直して試してみて」とDashからエラーダイアログが表示される状態でした。


1. 対処方法

XcodeのPreferenceの"Check for and install updates automatically"にチェックを入れると、iOS6のdocumentがアップデートされました。



アップデートが終わった後のiOS6のdocsetは以下の場所にパスが変わっていました。
/Users/<AccountName>/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.AppleiOS6.0.iOSLibrary.docset
その後でDashのPreferenceを開いてDocsetsタブの右下にあるリロードっぽいボタンを押します。



これでめでたく"iOS 6.0 Documentation Set"が追加されました。

2012/09/21

OAuth2.0の行き着く先


今更感たっぷりなのだけど、OAuth2.0って1.0から何が変わったのか調べていたらこんな記事に行き着いた。

OAuth 2.0 and the Road to Hell (2012/07/26の記事)

OAuth2.0について少し調べた程度しか予備知識が無いので深い事はわからないのだけれど、上記記事の筆者(Eran Hammerさん)がOAuth2.0が曖昧でひどいものになってしまい手がつけられなくなってしまったため、諦めて手を引くとかいう話の様子。

「OAuth1.0でうまくやってるのならOAuth2.0にアップグレードすることに価値はないし、OAuth2.0を使うのなら信頼できるところのソースをつかってきちんと理解して使わないといけないよ。」とか。

(他に何があるのかは知らないけど) Web2.0と同じように、2.0がつくものはあまり良くない結果になるという事なんだろうか。

ちょっとがっかりだけど、気を取り直してOAuth 2.0の中身について勉強しないと。

[追記] 上記記事の続きがあったので追記

On Leaving OAuth

こちらも併せて読んでみるとおもしろそう。

2012/08/22

UIWebViewのscrollを検知する方法

iOSのUIWebViewでscrollを検知する方法
(iOS5.1)

「UIWebViewを滑らかにスクロールする方法」で紹介した事とほぼ同じです。
UIWebViewのscrollViewプロパティで参照できるUIScrollViewのdelegateを設定します。

@interface ScrollDetector : NSObject <UIScrollViewDelegate>
@end

@implementation ScrollDetector
#pragma mark - UIScrollViewDelegate methods
- (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView
{
   NSLog(@"start");
}
- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate
{
  NSLog(@"end");
}
@end

// あとはwebViewへdelegateを設定するだけ
self.webView.scrollView.delegate = [[ScrollDetector alloc] init];



2012/07/01

UINavigationBarに影をつける方法

UINavigationControllerのNavigationBarに影をつける方法


ナビゲーションバーに立体感を持たせる感じで、ほんのり影をつける方法を探してココを見つけました。

http://stackoverflow.com/questions/5940076/how-to-create-uinavigationbar-drop-shadow

ありがたい情報を参考にして、こんな感じで。

私の場合、UINavigationControllerのサブクラス(MyNavigationController:クラス名は適当..)を使っているためこんなコードで実現できました。

ヘッダファイルに "#import <QuartzCore/QuartzCore.h>"を追加した後、ソースファイルをこんな感じで修正

 // MyNavigationController.m
 - (void)viewDidLoad
  {
    [super viewDidLoad];
   // ...
  // drop shadow
  CALayer *layer = self.navigationBar.layer;
  layer.masksToBounds = NO;
  layer.shadowColor = [[UIColor blackColor] CGColor];
  layer.shadowOffset = CGSizeMake(1.0f, 1.0f);
  layer.shadowRadius = 3.0f;
  layer.shadowOpacity = 1.0f;
}

アニメーションしたりするときは、layer.shouldRasterize = YES; とかしておくといいらしいです(未検証).

あと、layerに設定している各種プロパティの値については、こちらのブログで細かく検証されていました。すばらしー。

頭と尻尾はくれてやる!- 画像に影を付けたいのでいろいろプロパティをいじってみた


iosのUIWebViewを滑らかにスクロールする方法
(iOS5でのみ動作確認済み)
 // CGRectは一番上にスクロールしたいから適当なサイズ.
 CGRect topRect = CGRectMake(0, 0, 10, 10);
 [self.webView.scrollView scrollRectToVisible:topRect animated:YES];

探してみるとjavascriptでスクロールする方法が見つかったけれど、
objc側から制御した方がぬるぬる動くスクロールで見栄えがよかった。

ポイントはwebview.scrollViewでUIScrollViewが参照できるという点。

2012/01/06

gem twitterで認証付きproxyを越える方法 (続き)

昨日の続き。

rubygemsのfaradayの動作をスッキリさせる方法。

require 'rubygems'
require 'twitter'
require 'pp'

module Faraday
  class Adapter
    class NetHttp 
      def net_http_class(env)
        if proxy = env[:request][:proxy] 
          Net::HTTP::Proxy(proxy[:uri].host, proxy[:uri].port, proxy[:uri].user, proxy[:uri].password)
        else
          Net::HTTP
        end 
      end 
    end 
  end 
end

Twitter.configure do |config|
  config.proxy = { 
    :uri => "http://ユーザ名:パスワード@localhost:3128/"
  }
end

pp Twitter.user_timeline("wakatter")

これが一番すっきりする気がした。

gem twitterで認証付きproxyを越える方法

rubygemsのtwitterライブラリ"twitter"を使って認証付きproxyを越える方法を考えてみました。
ライブラリ自体の使い方は調べ中なので他のサイトを漁ってみてください。

方法1. Twitter.configureでproxy(別々にuri,user,password)を設定する。
require 'rubygems'
require 'twitter'

Twitter.configure do |config|
   config.proxy = {
       :uri => "http://hostname",
       :user => "proxy_user_name",
       :password => "proxy_password"
    }
end

p Twitter.user_timeline("wakatter")

方法2. Twitter.configureでproxy(uri文字列)を設定する。

設定値として"http://ユーザID:パスワード@ホスト名:ポート番号/"なURIとして有効な文字列を指定してあげたいという方法。

require 'rubygems'
require 'twitter'
require 'pp'

module Faraday
  class Connection
    def proxy(arg = nil)
      return @proxy if arg.nil?

      @proxy = 
        case arg 
        when String then {:uri => proxy_arg_to_uri(arg)}
        when URI    then {:uri => arg}
        when Hash
          if arg[:uri] = proxy_arg_to_uri(arg[:uri])
            arg 
          else
            raise ArgumentError, "no :uri option."
          end 
        end 
      if (@proxy[:uri].user and @proxy[:uri].password) then
        @proxy[:user] = @proxy[:uri].user
        @proxy[:password] = @proxy[:uri].password
      end 
      @proxy
    end 
  end 
end

Twitter.configure do |config|
  config.proxy = { 
    :uri => "http://ユーザ名:パスワード@localhost:3128/"
  }
end

pp Twitter.user_timeline("wakatter")

ここまでやってみて、fadarayというgemライブラリのプロキシ設定のデータ構造がopen-uriで使える環境変数での値と異なるところが気持ち悪い事がはっきりした。



2011/08/03

メモリ管理の基本ルール in objective-C

AppleのMemory Management Programming Guideを読んで大事なところをメモ。


メモリ管理の基本ルール

メモリ管理とは、オブジェクトの所有権の管理
  • 自分で作ったオブジェクトは自分のもの。
    • "alloc", "new", "newObject", "copy", "mutableCopy"とかで始まる名前のメソッドで作る。
  • "retain"を使ってオブジェクトの所有権を得る。
    • 受け取ったオブジェクトは受け取ったそのメソッド内では有効なことが保証され、そのメソッドも安全にオブジェクトを返してくれるはず。
    • "retain"を使う二つのケース
      1. accessor methodの実装、または'init'メソッドの実行
      2. 必要なオブジェクトが他の操作で無効化されないために。
  • 必要なくなったら、オブジェクトの所有権を捨てる。
    • "release"または"autorelease"で所有権を捨てられる。
    • Cocoaではオブジェクトの所有権を捨てることをオブジェクトを"release"するという。
  • 自分のものでないオブジェクトの所有権は捨ててはいけない。


Cocoaのルールに沿ってコードを書かないと後で困る事になる、というお話。

2010/11/30

掃除しました。

残骸をお掃除しました。

まぁ、ぼちぼちと...。