サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
www.tokoro.me
Photo by Victor Grabarczyk on Unsplash ブログ記事書くとき画像を埋め込むのが面倒 こういったブログ記事は、皆さんどういう執筆環境で書いているでしょうか? 最近だとHugoなどの静的サイトジェネレータを利用することも多いのではないでしょうか。 この記事もHugoで運用しています。 記事を投稿するときは、いつもVimでさらっとMarkdown形式で書き上げ、ぱぱっとデプロイコマンドを打つだけで簡単便利な環境なのですが、唯一、記事に画像を埋め込むのだけが面倒だと感じてます。 特に、いわゆるブログサービスを利用している場合には、記事作成ページに埋め込みたい画像をドラッグ&ドロップするだけで画像をアップロード&埋め込みできてしまうので、それとの比較で面倒さが際立ちます。 手動での画像埋め込み手順 これまで手動で画像を埋め込む際には、このブログ記事の場合だと、 各
Firebase App Distiribution 先日BETA公開されたFirebase App Distributionですが2020年3月終了のFabricからの移行先としてはもっとも有力ですよね1。 先日「Firebaseを利用していない既存アプリを配信するためだけにFirebase App Distributionを使いたい!」と思い試してみたら、あまりにも簡単で「これは10分で設定から配信まで完了するんじゃない?」と思い、実際に、 Firebase未導入のビルド可能なプロジェクトがある状態 Firebaseのプロジェクトを作成するところから開始 配信用にアプリをビルドしてFirebase App Distributionでテスターに配信するところを終了 という条件で実際にストップウォッチで測ってやってみたところ、なんと「4分43秒」で終わりました! この記事用にスクショを撮影
2019年はSwiftUI誕生の年 2019年のSwiftUIの発表はたいへんインパクトがありましたね! Objective-CからSwiftへの変遷と同様に、ここ数年で間違いなくSwiftUIがiOSアプリ開発のスタンダードになるものと思います。 いっぽうでSwiftUIはまだまだ機能不足、情報不足で実際にリリースする案件に適用するには心許ないというのが2020年1月時点での現状です。特に自社のメインサービスやクライアントワークでSwiftUIの導入を決断をするのはなかなか難しい時期かもしれません。 また次の6月のWWDCでアップデートが発表され状況は変わってくると思いますが、それを待つのも… ということでハッカソン ということで、冬休みにひとりでハッカソンを実施して、 24時間でSwiftUIでiOSアプリを開発して AppStoreでリリースする ところまでやる!ということにしました
本記事は Vim その2 アドベントカレンダー 21日目の記事です。 経緯 今年の8月頃から PEAKS の iOS 12 Programming という技術書の執筆に参加しました。 このとき初めて Re:VIEW による執筆をしました。 現在は技術書展も賑わっており、Re:VIEWで執筆する機会は以前より多くなっているかと思います。 一方で、VimでRe:VIEWを取り扱う環境が意外と整っておらず1、2018年時点の情報を整理させていただきます。 以下、 シンタックス・ハイライト リアルタイムプレビュー 校正サポート コード・スニペット の順に整理いたします。 シンタックス・ハイライト Re:VIEWのシンタックス・ハイライト用のpluginはいくつか見つかったものの、最新のRe:VIEW 2.0にきっちり対応されているものが見つかりませんでした。 Re:VIEW 2.0のフォーマットガ
この記事について この記事は Lottieでアプリにアニメーションを組み込む話(デザイナー編) を受けての iOSプログラマー編 になります。 デザイナー編では実際にアニメーションを作る具体的な方法を含め解説されていますので是非ご参照ください。 Lottieとは LottieとはAdobe After Effectsで作ったアニメーションをそのままクライアントアプリで表示するためのライブラリです。 iOSやAndroidのネイティブアプリの他、React Nativeでも利用できます。 iOS用のライブラリは、 https://github.com/airbnb/lottie-ios です。 なにができるの? 作成されたアニメーション用JSONファイルをアプリに埋め込んでわずかなコードで再生することができる インターネット上に設置したJSONファイルを読み込んでアニメーションを再生すること
extensionでstored propertyを追加したくなることありますか? 少なくともSwift 2.1時点ではextensionでstored propertyを追加することはできず、computed propertyのみに限られます。 でも、ヤダヤダ!ぼくは絶対stored property追加したいんだい!ってことありますか? そう思っちゃうあなた、他に解決方法ありますよね?なんでそのやりかたにこだわるんですか?そういう思考になっちゃう時点でまだSwift脳に至ってはいないのではないでしょうか(建前)。 なお、ぼくはどうしても追加したんだい!ってことがあります(本音)。 対象がAnyObjectならAssociated Objectsで代用できるよ で、そんな時は この記事 でやっているように Associated Objects で代用できることがあります。 対象にきちんと
deferしてますか? Swift2でみんな大好きdeferさんが導入されましたね! guardと違いそんなに使う機会は訪れていないのですが、昨日、こんな感じで使いたい!という場面に遭遇しました。 CocoaLumberjackを使ってデバッグ用にUITextViewにログを吐くCustom Loggerを設定していたのですが、とあるViewControllerだけでそれを使いたく、ViewControllerがdeinitされたらそのCustom Loggerも当然外したい。 そんなコードを書く場合、defer大好きっ子ならCustom Loggerを登録した後にこんな感じで解除したくなりますよね(実際は僕はこのとき初めて実験でないところでdeferを使ったので、本当のdefer大好きっ子はこんな間違いはしないだろう)。 let logger = TextViewLogger(textV
El CapitanでTotalTerminalが動かないならAppleScriptで代用すればいいじゃない? El CapitanにしたらTotalTerminalが動かない! Twitter上でもよくこの話題が出ていて、多くの人はiTerm2に移管しているようです。 しかし、ぼくは長年愛した(普通の)Terminalちゃんをそう簡単に捨てることはできないのです! もともとTotalTerminalはTerminalの表示をカッコよくトグルするために使っているわけで、TotalTerminalというよりはTerminalちゃんをそのまま使いたいわけです。 (実際のところiTerm2を試してないので、iTerm2の良さについては全くの無知です) であれば、そんなトグルくらいならAppleScriptで軽やかにできるはず!ぼくのAppleScriptでTerminalちゃんを救ってみせる!
※2015/3/11時点での比較結果ですので、今後、各ライブラリともにパワーアップしていくと思われます ※いまはできないことでも各ライブラリのIssuesでは実装の検討が進んでいるものも多くあるようです 次の案件で(Swiftで)Promiseライクなフロー制御を実現するために利用するライブラリを選定するため、2015/3/11時点の SwiftTask PromiseKit Bolts-iOS を(表面だけ)使って比較してみました。 なお、昨年の7月時点では(Swiftで使うぶんには)PromiseKitが将来性があると判断し、しばらくはPromiseKitを使っていました。 その後、SwiftTaskも登場して気になっていたので、今回改めて新案件で採用するライブラリを選定したという経緯になります。 以下にそれぞれ使ってみた結果を紹介させていただきます。 更新頻度 この3つのライブラリは
※この記事のコードはXcode 6.3 beta(Swift 1.2)で試しています Swiftいいですね! これまでSwiftの案件を2つほどやってきたのですが、どちらも開発スタートが2014年7月だったため新しめのSwiftライブラリもリスクが高そうで、利用できるライブラリはある程度限定されてしまいました。 例えば、Alamofire のInitial Commitも2014/7/31だったりと。。。 今となっては(2015年3月)Swift公開から早9ヶ月が経過しており、ライブラリの選択肢もだいぶ広がりました。 また、まだSwiftのライブラリを管理する環境もだいぶ整ってきました(ちょうど本日3/11にCocoaPodsのDynamic Framework対応版が公開されました!)。 ということで、3月からはじめる新案件ではAlamofireの採用を決め、APIアクセスまわりのインタ
上記を試したコード let timeZone = NSTimeZone.systemTimeZone() println("#### abbreviation, \(timeZone.abbreviation)") println("#### name, \(timeZone.name)") println("#### description, \(timeZone.description)") let en = NSLocale(localeIdentifier: "en_US") println("#### Standard, \(timeZone.localizedName(.Standard, locale: en))") println("#### ShortStandard, \(timeZone.localizedName(.ShortStandard, locale: en
だいぶ小ネタ。 コード #if (arch(i386) || arch(x86_64)) && os(iOS) AFNetworkActivityLogger.sharedLogger().level = .AFLoggerLevelDebug AFNetworkActivityLogger.sharedLogger().startLogging() #endif UIDeviceを使う方法もあるが、そちらは実際に動いたときに判別することになる。 こちらだとそもそもiPhone用のアプリからはこのコード自体省かれる形になる。 意味 arc(i386) 32bitのMac(シミュレータ)用のビルド arc(x86_64) 64bitのMac(シミュレータ)用のビルド os(iOS) ターゲットがMacじゃなくてiOS オマケ ぼくの手元では、デバッグ実行時に #if DEBUG printl
Swiftオフィシャルの部分適用 まず、Swiftオフィシャルな構文として func addTwoNumbers(a: Int)(b: Int) -> Int { return a + b } というように引数を1つ1つ別の括弧で囲ってfunctionを定義すると let add1 = addTwoNumbers(1) add1(b: 2) //< 3 というかんじに、 まず、1つめの引数だけ部分適用(ここでは a) 部分適用したものに後から次の引数を適用(ここでは b) というのができる。 専用の書き方じゃなくてふつうのfunctionに部分適用できないの? 使うかどうかは別としてHaskellみたいに全ての関数に部分適用できたら面白いなーと。 また、上のような専用の定義にしちゃうと addTwoNumbers(1, 2) みたいな普通の呼び方ができなくなっちゃうし。 そんなとき、 Sw
概要 この記事でできるようになること 安定してInfo.plistの内容(ここではBuild番号)を変更できる ふつうにRun Scriptで編集するとタイミングによってすぐにアプリに反映されないことがあったりしたがそれが解消される Info.plistに差分がでないのでcommitのときに邪魔にならない なお、この方法を教えてくれた熊谷さんがこの方法に行き着いた経緯や所感がこちらに詳しくまとめられています。詳細や考え方などをきちんと知りたいかたは是非、熊谷さんの記事をご一読ください! 必要な設定 Preprocess Info.plist file でInfo.plistをビルド前に確定させる Run Scriptで${TEMP_DIR}/Preprocessed-Info.plistを編集する 以下、具体的な話をします。 経緯 これまで、 デバッグ用やArchive用のアプリのバージョ
非同期処理のテストってどう書いてますか? 標準のXCTest自体がサポートしていれば良いのですがそうではないので、非同期処理のテストを書きたい場合には、その仕組みを自作するか出来合いのライブラリを利用する必要があります。現実的な選択肢としては、 GHUnitやKiwiなど非同期処理をサポートしたテストフレームワークを利用する GHunitの非同期処理のテストの仕組みを真似て抜粋したライブラリを利用する(意外とこれが多いかも?) expectaなどのマッチャーライブラリに付属の非同期処理の仕組みを使う となるかと思います。 ただ、私が調べた時点だとどれもしっくりきませんでした。 まず、GHUnitやKiwiなどを採択している場合には良いのですが、非同期処理のテストを書くという目的だけのためにそれらのフレームワークを使うというのは冗長すぎます。 また、GHUnitの非同期処理の仕組みだけを抜き
これは potatotips第6回め で発表した この話 のまとめと後書きです。 Storyboardいいですよね! Storyboardを使うことで、 画面と画面が疎結合になる 簡単な画面遷移ならノンコーディングで実現できてソースコードを汚さない といったメリットがあります。 Storyboard登場以前だと、次の画面に遷移させるだけでも #import "NextViewController.h" NextViewController *nextViewController = [NextViewController new]; [self.navigationController pushViewController:nextViewController animated:YES]; といったコーディングをし、遷移元のViewControlelrは遷移先のViewController
2014/02/09 追記 コメントのところでやり取りしているようにmergepbxの作者さんから連絡があって、この記事で書いた問題が修正されました! 今現在は merge=mergepbx がいい感じになってきているのでそっちがオススメです。 複数人でプログラミングしているとpbxprojがやたらとコンフリクトする 例えば、 Aさんが AALabel.m をプロジェクトに追加して Bさんが BBLabel.m をプロジェクトに追加して とただそれだけなのにマージのときにコンフリクトするpbxprojさん。。。 ただそれぞれファイルを追加だけのことでコンフリクトするなんて… どうにかならんもんかいとTwitterでつぶやいたところ、 @azu_re さんから有り難い教えが! @tokorom gitはファイル別にマージ方法を指定できるので、mergepbxみたいなのをpbxprojのマージ
XXXViewControllerの親クラスを差し替えたいときありますよね? UIKit内で言えばUITableViewControllerとかはその代表格。 外部ライブラリで言うと、Google Analytics SDKのGAITrackedViewControllerとか。 要するに、XXXViewControllerの継承して実現したい機能があるのに、既にYYYViewControllerのサブクラスなので使えないよーとなってしまうケース。 で、既存のものは置いておくとしても、自分が作るライブラリのXXXViewControllerについては、なんとかその親クラス差し替えの需要に応えられないものかなあと。 runtime使う? いちおう class_setSuperclassという関数があるのですがDeprecated… なんか良い方法ないかな?と考えた結果、今のところ以下のかんじ
2013年11月18日 追記 この記事を書いた後、何人かのかたから「うちでは同じApple IDで両方とも使えているよ」というご指摘をいただき、 Member Centerのほうにアカウント追加 -> iTunes Connectに同じアカウント追加という順番だと「警告は出るもののかまわずContinueすれば」同じApple IDでアカウント作成可能 iTunes Connectにアカウント追加 -> Member Centerに同じ追加という順番だと「複雑な手順にはなるものの適切な手順を通せば」同じApple IDでアカウント作成可能 失礼しました。 追加情報などあれば是非おねがいします! 概要 私はiOSアプリの開発を3年以上やっていますが、恥ずかしながら会社でこのためのアカウントを管理/運用する方法をきちんと把握できていませんでした。 というのも個人で開発するぶんにはそんな管理は必
導入 会社でHaskell勉強会に参加して、カリー化とか部分適用のパートの輪読当番になったのだが、正直、輪読時点でもそれがなんなのかよくわかっていませんでした。 しかし、勉強会で参加者のみなさまに教えてもらった結果、カリー化とかがやっと理解できました! ということで嬉しくなって先日寝るときに布団の中で「Objective-Cでもできるかなー」と脳内コーディングしてみた結果を実装してみました。 もう他の人がやってるかもとか、こんなん実装しても実際のところ使わないよねとか、そんなことはまったく気にせずです。 実際やってみたソースコードは こちら に置いてあります。 ひとまずのゴール カリー化して部分適用ができる状態までということで、Haskellのmapが実現できるところまでを目標にしました。 map (+3) [1, 2, 3] これです。 Objective-Cでは当然、空白区切りで引数を
今回の記事はUIデザイナの Morino氏 からの寄稿です。 iOS 7が正式リリースされました。既にアップデートを行って実際に試されている方も多いと思いますが、今回はUIに大幅な変更が加えられたために、まだ操作に戸惑いのある方もいるのではないでしょうか。 特にiOS 7にしてから重く感じる、もっさりしているという意見もけっこう多いようです。iOS 7をしばらくいじってからiOS 6の端末を触ると、たしかにiOS 6の方がきびきび動いているように感じます。 今回は半透明やぼかし、視差効果などの画像エフェクトをふんだんに使用しているために画像処理の負荷が高いことも確かでしょう。しかし、全てが端末の性能のせいというわけでもないことを、今回はご紹介したいと思います。 頻繁に操作を行う以下の4つのシーンについて、ちょっとした比較検証を行いました。 ロック解除してから、ホーム画面のアイコンが全て出現
今日はGithubに公開したiOS用のライブラリを Travis CI と Coveralls に対応した手順を紹介したいと思います。 なお、実際にこれらを適用して運用しているリポジトリのサンプルは、 https://github.com/tokorom/BlockInjection になります。 前提条件 GitHubを使っていること GitHubでなんらかiOS/Mac用のライブラリを公開していること Travis CI https://travis-ci.org/ 目的 公開しているライブラリの最新コードがきちんとビルドが通るものか、テストが通る状態かを明示できます。 iOS用のCI環境を用意するのは通常すごく敷居が高い(物理的にMacが必要)のですが、Travis CIはiOS/Mac用のライブラリのCIを無料で請け負ってくれるかなり太っ腹なサービスです。 事前準備 Travis
今回の記事はUIデザイナの Morino氏 からの寄稿です 前回 はiOS 7紹介ビデオの中のジョナサン・アイブ氏のパートをご紹介しました。 今回は、その中でも特に重要と感じたいくつかのフレーズをピックアップして深堀りしてみたいと思います。 “True simplicity” iOS 7から話題の"フラットデザイン"が採用されて、画面デザインは大分シンプルな外観になりました。 使う色の数は限定され、簡単明瞭なラインやシルエットがほとんどのデザインを占めています。 iOS 6まで採用されていたSkeuomorphism(装飾的・リアルな外観)は排除され、立体的で質感を感じるデザインから、平面的で形やテキストの意味性をストレートに伝えるデザインに変わりました。 ただ、“Simplicity"という言葉は、単に外観を表すものとして使われているわけではありません。 「複雑さに秩序をもたらす」という
既存記事のまとめのため新しい要素があるわけではないのですが、Appleから発表されたXcode 5が正式にリリースされる前の復習ということで。 Tipsを適用する前のコード #pragma mark - Private Category @interface Sample () @property (strong) NSNumber* i; @property (strong) NSNumber* c; @property (strong) NSNumber* f; @property (strong) NSArray* array; @property (strong) NSDictionary* dictionary; @property (strong) Sample* child; @property (strong) UIColor* color; @property (assi
今回の記事はUIデザイナの Morino@WWDC2013参加中 に寄稿いただきました! Appleの公式サイトに iOS 7 を紹介するビデオが公開されましたね。 http://www.apple.com/ios/ios7/ 特に前半の4分間でジョナサン・アイブ氏により語られているiOS 7の説明部分に、今回の大きなデザイン変更の様々な要点が含まれており、これからのアプリ設計のあるべき方向性が示唆されています。 これらをよく理解しておくことが非常に重要だと感じていますので、自分自身の復習のためとみなさんへの展開の意味で、書き起こし&和訳を行いました。 デザイナのみならずアプリ開発者の皆様にも有用かと思いますので、ぜひご参照ください。 iOS 7 Video - 書き起こし & 和訳 ※ 画像はすべて iOS 7 Video の中からの抜粋です We have always thought
tokorom@WWDC2013参加中です。 WWDC2013で膨大なアップデートを学習中でしゃべりたいことが盛りだくさんなんですが、NDAのため我慢の日々。 で、キーノートの範囲の話は既に各所で情報が出ているわけですが、キーノートに出ていない項でも、Appleが非ログインで参照できるサイトで既に公表しているものがいくつかありました。 概要レベルでありますが、なかでも TDD とか CI まわりでiOSアプリ開発者にとって嬉しい情報がありましたので報告させていただきます。 あくまでもAppleのサイトで公表されている範囲内のことしか書けませんのであしからず。 ついにXcodeから任意のテストだけを簡単に実行できるようになる ついに、ついに…というかやっとかという話。 Xcode 5 で Test Navigator というやつが加わり、テスト駆動での開発を助けてくれますとのこと。具体的に、
UIAlertViewは警告目的のダイアログ そもそもUIAlertViewはエンドユーザになんらかの警告をするときに利用するもので、iOSヒューマンインターフェースガイドラインにも、 一般にアラートは、次のような場合には不要です。 * なんらかの情報、特にアプリケーションの標準機能に関する情報を目に付かせるためだけの場合。 代わりに、アプリケーションのスタイルに調和し、目を引く情報表示の方法を設計すべきです。 と記載されています。 その一方で、UIAlertViewは簡単に利用でき、なんらかの情報を表示するのにどうしても使いたくなってしまいます。 それならばUIAlertViewの外観を変えて使えば、というのも考えられますが、ところがどっこいUIAlertViewはAppearanceの変更を一切サポートしていません。 警告目的のアラートダイアログの外観がアプリによって変更され
UIKitで使われている画像はどこにある? 例えば、UIAlertViewのアラートの画像ってどういう構成になってる?とかUISegmentedControlのAppearance変えたいんだけど当てはめる画像はどう作る?などというときにUIKitが標準で使っている画像パーツを参照できると便利です。 プログラマというか特にはデザイナさんにとって有用だと思います。 その画像パーツですが、Xcode(iOSシミュレータ)の中に入っているのでそこから抜くのが手っ取り早いです。 具体的には(これはiOS6.1の場合)、 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/System/Library/Frameworks
BlockInjectionとはなんぞや Objective-Cの特定のメソッドの前後に処理を追加できるライブラリです。 クラスの外側からアスペクト指向的に振る舞いを追加できるのが特徴です。 https://github.com/tokorom/BlockInjection で公開しています。 バージョンアップ内容 前記事 からのバージョンアップ内容は以下です。 リファクタリングしてメソッド名が一式変更になりました(これまでのものはDeprecatedですがまだ使えます) クラスメソッドにも対応しました 複数のクラスやメソッドを一度に追加できるようになりました 正規表現で指定できるようになりました(※1) 注入したBlockの中で注入先のメソッド名を取得できるようになりました(※2) オマケで単純なメソッド実装置き換え機能も追加しました UIViewの勝手に呼ばれているsetterでまとめ
次のページ
このページを最初にブックマークしてみませんか?
『TOKOROM BLOG』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く