Swiftは型に厳格で、誰が書いてもある程度安全で、尚且つ見やすいので好きです。型の概念?が柔らかくて何でも入ってしまうような例えばobjective-cのような言語を使うメリットはなんですか?
Swiftは型に厳格で、誰が書いてもある程度安全で、尚且つ見やすいので好きです。型の概念?が柔らかくて何でも入ってしまうような例えばobjective-cのような言語を使うメリットはなんですか?
1 はじめに iOSでは、簡単なコードで位置情報(経緯度)を取得することが可能です。 すでに周知済みかと思いますが、iOS8以降、プライバシー向上のため、やや利用方法が変わっています。 今回は、ちょっとこの辺をまとめておく事にしました。 2 実装 実装の手順としては、次の通りです。 フレームワークの追加 認証リクエスト 利用目的の記載 情報更新開始 取得データの処理 それでは、各項目について見ていきます。 (1) フレームワークの追加 CLLocationManagerを使うにはCoreLocation.frameworkを追加する必要があります。 フレームワークの追加の要領は、次の通りです。 最初に、Xcodeのプロジェクト画面からGeneralのLinked Frameworks and Librariesの[+]をクリックします。 表示されたダイアログでは、検索窓に CoreLoca
AppleがSwiftを発表し、2年あまりが経過しました。移行や新規プロジェクトにおけるSwift採用も増えてきましたが、まだまだObjective-Cの資産も数多く残っています。連携はできるものの、なるべくならSwiftに移行したいと考えているのではないでしょうか。 Swift採用を促進するために使いたいのがobjc2swiftです。Objective-CのコードをSwiftに変換してくれるソフトウェアです。 objc2swiftの使い方 objc2swiftの画面です。左側にObjective-C、右側に変換後のSwiftのコードが表示されます。 こうやってみるとずいぶんコード量が減っているのが分かります。 左側のコードを変更すればすぐに反映されます。 すべてのコードが変換できるわけではありませんが、Swiftを習い始めている方であったり、既存のコードをどうSwiftで書けば良いか迷っ
Help us understand the problem. What is going on with this article? 世間はクリスマスモードだと言うのに、辛気臭いタイトルですみません。「勝手に殺すな」とか「お前は何様だ」などとなんだか怒られそうです。「喪失感で胸がいっぱい」だとか「 Objective-C はまだまだ使える言語です!」だとか、そういう感傷もありませんし、主張もしません。「いい言語だと思うし好きだけど、結局 Mac OS X や iOS のアプリケーション開発以外に活用(しようとトライしたけど)できないまま Swift が発表されたなー」と思っていて、なぜ活用しにくかったのかを整理してみようと考えました。ですので、「 Objective-C 栄光の歴史」を語ることはありません。体験してないし。知らないし。 それから、ここでは言語としての Objective-
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog どうも、ヤフーの佐野( @taketo1024 )です。先日引っ越しをしまして、張り切って自分でタンスを運んだりして今とても筋肉痛です。 皆さんは Objective-C から Swift への移行は進んでいますか?弊社ではまだ Obj-C で書かれているプロジェクトは多くあります。世に出ている iOS アプリも多くはまだ Obj-C で作られているんじゃないかと思います。 Swift もオープンソース化され、この先その進化のスピードはさらに増してくるはずです。そこでチーム内で開発を進めていた Obj-C → Swift コンバータ を大幅に改良しオープンソースで公開することにしました!この記事ではその導入と活用の方法を説明します
やりたいこと 任意のUICollectionViewCellがロングタップされた際に任意の編集メニューを表示する。 こんな感じ↓ 環境 Xcode 7.1 iOS 9.1 上記環境以外では試していませんが、おそらくiOS6.0以降なら動作すると思います 方法 UICollectionViewCellの編集メニューを表示するには、まず次の3つのデリゲートメソッドを実装する必要があります。 collectionView:shouldShowMenuForItemAtIndexPath: collectionView:canPerformAction:forItemAtIndexPath:withSender: collectionView:performAction:forItemAtIndexPath:withSender: さらに、各々のメソッド内で編集メニュー表示に関する細かい指定を行う
メモリの不正アクセスによる不具合は再現率が低かったりしてデバッグが難しかったりしますが、XCode7で追加されたAddress Sanitizerを使うとXCodeが検知してくれるよ、という機能です。 こちらを参考にしました。 Address Sanitizerを有効にする あからさまに不正アクセスするサンプルを用意しましょう。 - (void)viewDidLoad { [super viewDidLoad]; char *buffer = malloc(80); buffer[80] = 'Y'; free(buffer); } このまま実行しても何事もなく動いちゃったりします。 Address Sanitizerを有効にしてみましょう。 ここからEdit Schemeを選択します。 "Enable Address Sanitizer"をチェックします。 この状態で実行してみましょう。
iOS組み込みのキャッシュモジュールNSCacheについて発表しました - ninjinkun's diary @k_katsumi キャッシュを分ける方のはわかりやすくて良いですね。後から読む人の参考になりそうなので、URL と URL の発言、ブログに引用させていただいても良いでしょうか。 2012-03-26 16:42:44 via web to @k_katsumi @ninjinkun はい。ぜひぜひー。せっかくなので便乗して僕がいつも使ってる画像キャッシュのコードを共有したりしてみます。 2012-03-26 16:45:05 via YoruFukurou to @ninjinkun @k_katsumi お、それは楽しみです!この手のものはみんな独自に作ってる感じだと思うので、参考にさせていただきたいですー。 2012-03-26 16:48:23 via web to
UIWebViewを使用する上での簡単な注意点をいくつか。 UIWebViewオブジェクトはリリース前にdelegateにnilを設定しておくこと リリース前にdelegateにnilを設定しておく必要があるのは、次のページで詳細に説明されているように、UIWebViewのロード処理が別スレッドで行われていることが関係しているためであるようだ。 [iPhone] UIWebView のリリース前に delegate に nil をセットする必要がある | Sun Limited Mt. 「iPhoneプログラミングUIKit詳解リファレンス」ではさらに、リリース直前にロード処理を中止している。 - (void)dealloc { if (webView.loading) { [webView stopLoading]; } webView.delegate = nil; [webView
海外事業向けのiOSアプリケーション開発を担当している西山(@yuseinishiyama)です。クックパッドは現在、海外複数カ国に向けてサービスを展開しています。 XcodeにはInterface Builderと呼ばれる、リッチなGUIを持ったデザインツールが付属しており、これを用いて画面のレイアウトを構成することが主流となっています。弊社ブログでも、iOS開発でstoryboardとxibをうまく使い分けるプラクティス等の記事で、GUIベースのレイアウトについて触れています。しかし、現在私が担当しているプロジェクトでは、Interface Builderを用いずに、レイアウトの大半をコードで記述しています。 今回は、コードベースのレイアウトを実装していく中で得た知見を、以下の3つの部分に分けて共有したいと思います。 Interface Builderを用いたレイアウトとコードベースの
Objective-Cの継承とカテゴリについて さて、本日は今更ですが、Objective-Cの継承とカテゴリについて書きたいと思います。 理由は、最近、自分だけではなく、 『第三者が見てもわかりやすいクラス』 を作ることを意識し始めたからです。 本当に今更ですね笑。 アジェンダは下記です。 Objective-Cの継承 Objective-Cのカテゴリ シングルトンパターンでの継承 シングルトンパターンのクラスを継承したクラスのカテゴリ では、早速見て行きましょう。 Objective-Cの継承 まずは、継承です。 初めに元となるクラスを作成します。 // SampleClass.h #import <Foundation/Foundation.h> @interface SampleClass : NSObject @property(strong, nonatomic) NSStri
qiita.com 以下を参考にさせていただきましたー。 dev.classmethod.jp classmethod様様です。 ただ、iOS8からの対応となると多分上記のバージョン分岐もいらなくなるのかなと。
スマートニュースのようなフリックでページを移動したり、タブをスクロールしてページを選ぶような感じのUI。 最近はかなり増えているので今更な感はありますが、アニマネ の次期バージョンでも導入を検討中です。 一から実装せずともいくつかライブラリがあるようなので、試してみました。 比較したライブラリ はじめにざっくりとした比較表を。 2015年9月前半に比較していたので、今はまた状況が変わっているかも知れません。 あくまで参考程度に見て頂ければと思います。 ※追記 下記のライブラリもオススメです。 言語 ライブラリ 言語 RMPScrollingMenuBarController Objective-C PageMenu Objective-C,Swift PagingMenuController Swift 対応OSバージョン ライブラリ バージョン RMPScrollingMenuBarCo
「Objective-C to Swift Converter」はObjective CのソースコードをSwiftに一発変換してくれるサイトです。SwiftはAppleが昨年発表した新しいプログラミング言語です。今までObjective Cで書いていたソースコードをSwiftに一発で変換してくれるので便利ですよ。左右のパネルでソースコードを見比べられるのもよいですね。 以下に使ってみた様子を載せておきます。まずObjective-C to Swift Converterへアクセスしましょう。 左側がObjective Cのソースコードです。「Convert」ボタンを押すと右側にSwiftのソースコードが生成されますよ。ある程度機会的な作業になる部分はコンバータを使って変換したあとに、目視確認というのもありですね。ソースコードを直接書いて変換できるので、メソッド単位で変換できたり融通がききま
iOSアプリ開発者の皆さま、もう「Swift」でアプリを開発していますか? 登場した日から一年以上たち、今はバージョン2.0のベータ版まで出ているプログラミング言語Swift。初期はコンパイルの遅さや不具合の多さが目立ったのですが、最近はその辺りの問題が解消されて非常に使いやすくなってきています。 そろそろ、ぜひ移行をお勧めしたいのですが、既存のObjective-Cアプリを移行するのはなかなか大変な面もあると思います。チームで開発している場合は自分以外の開発者や関係者へ周知するコストも掛かりますし、Swiftへ移行する際のトラブルを思うと、いろいろな不安がつきまとうでしょう。 本稿では、そういった不安が少しでも解消されるように、アプリ開発のプログラミング言語をObjective-CからSwiftへ移行するメリットや手順、注意点など勘所をまとめて紹介します。 なお本稿は、SwiftやObj
『現実世界をWeb化する』「Physical Web」そして「Eddystone」について詳しく聞いてきた! 白石 俊平(HTML5 Experts.jp編集長) 読者の皆様、「Physical Web」って知っていますか? 昨年10月、Googleが発表したIoT技術で、iBeaconなどのBluetooth Low Energyを活用した技術と、Web技術者にとっては馴染みの深いURL (URI)を組み合わせた技術です。 IoTに関心のあるWeb技術者であればスルーは許されない「Physical Web」について、詳しい人(株式会社リクルートテクノロジーズ ITソリューション統括部 アドバンスドテクノロジーラボ 加藤亮さん)に詳しく聞いてきました! ▲株式会社リクルートテクノロジーズ ITソリューション統括部 アドバンスドテクノロジーラボ 加藤亮さん 編集部より注意 このインタビューの
#import <Foundation/Foundation.h> @interface AAClass : NSObject @property NSString*name; @end #import "AAClass.h" @implementation AAClass -(id)init{ if (self = [super init]) { _name = @"" } return self; } - (void)encodeWithCoder:(NSCoder *)coder { [coder encodeObject:_name forKey:@"name"]; } - (id)initWithCoder:(NSCoder *)coder { if (self = [super init]) { _name = (NSString*)[coder decodeObjectFor
iOS8からのTableViewCellの高さ自動計算は、上スクロールした時にはうまく動かない件で、UITableViewCellの高さ自動計算でハマる場合がある事がわかりました。 これを回避するには、estimatedHeightを使わずに、真面目に高さ計算を行えば良いです。 Autolayoutが無い時代には、これをごりごりと計算していたのですが、UITableViewCellにAutolayoutを使う事で、かなり簡略化できたのでその記録を残します。 おおまかな流れ UITableViewDataSourceから参照できる所に、「表示する事の無い、高さ計算用のダミーセル」を用意します。 tableView:heightForRowAtIndexPath: で、ダミーセルを使って高さ計算を行います。 このときAutolayoutで計算ができるので、比較的楽です。 ソース - (void
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く