サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
こんにちは @yimajo です。この記事は今から新規でAndroidアプリを書き始めるなら。に大きく影響されています。主な内容として次のような事柄を取り扱っています。 今から書くならこんな設計 こんなライブラリがあるが使ってみた感想 ただ、結論として大して深い内容は書けませんでしたので、がっかりせず、みなさん思い思いにやればいいよっていうことに終着しています。アドベントカレンダーのネタにみなさんも書いてみてはどうでしょう。 言語について Objective-C かSwift か まず最初に言っておくとObjective-CやSwift以外にもiOSアプリを始める方法はあります。例えばObjective-C++とかRubyMotionとか。まあそれはそれで良いところもあると思いますが、複数人でiOSアプリ開発を行いそれを保守したり機能追加したりすることを考えるとObjective-CかS
SwiftのenumがObjective Cで欲しいときはどうするか - soutaroブログ この記事には enumが便利なのは ある状態では有効だけど、別の状態では有効ではない値を定義するとき です。 と書きましたが、「それはサブクラスっていうやつではないか」という声があります（どこに？）。その通りで、enumとクラスはよく似ている側面があって、enumでできることはクラスでも（再コンパイルの量とか、網羅性の検査とか、isKindOf:とか、キャストとかの問題を見なかったことにすれば）できるという話でした。 ここで疑問になるのは、 なぜSwiftにはenumとclassという似たような機能が二つ用意されているのか（TMTOWTDI？） 何を考えてenumとclassを使い分ければ良いのか でしょう。 enumとclassの違いSwift的には「classは状態を持てるがenumは持て
as!って言うのは、要するにダウンキャストできない場合にプログラムを終了させるものである。 if let x = expr as? SomeClass { f(x) } else { fatalError() } と書くのであれば、 f(expr as! SomeClass) と、同じことなので、as!で書いた方が良い。その方がタイプ数が減るし、コードの見た目も簡潔になって理解しやすくなる。長いコードはそれだけで苦痛だし、なにか間違ったプログラミングをしていることを示すシグナルにもなる。ダウンキャスト失敗の場合に終了するためだけにifを書くことは、全体的なコードの乱雑さを増してしまい、本当の問題の見落としに繋がる。 ただし、as?とかas!とかダウンキャストをしてる時点で、そのプログラムには潜在的な問題があると考えることもできて、本当にダウンキャストが必要なのか3回くらい考えた方が良い。
おはようございます。シニアアプリケーションエンジニアの id:cockscomb です。WWDC が目前に迫ったいま、今秋にリリースが予定されているSwift 3.0 について、Swift OSS コミュニティの中心であるSwift Evolution から読み取っていきたいと思います。 [PR]本記事は、筆者が株式会社はてなの協賛を得て主催した「関西モバイルアプリ研究会 #14」において、“Swift Otaku — NerdySwift-Evolution Watching” と題して発表したものをブログの記事として再構成したものである。 関西モバイルアプリ研究会は、毎月一度、平日夜に京都や大阪で開催される、モバイルアプリ関連の勉強会である。次回の「関西モバイルアプリ研究会 #15」は6月22日水曜日に開催予定だ。 目次 Focus Winding Down Complete
Jesse Squires InstagramでiOSアプリを開発しているソフトウェアエンジニアです。jessesquires.comにてSwiftやObjective-Cに関するブログを書いています。Github上で多くのオープンソースプロジェクトにコントリビュートしています。走ることと新しいことを学ぶのが好きで、主にブラックコーヒーとブラックメタルによって元気になります。twitter.comSwiftに貢献したいですか？どのように、また、どこから取り掛かればいいか分かりませんか？パッと見て圧倒されるかもしれません。この講演では、さまざまなSwiftのプロジェクトがどのように関係しているかを見て、貢献し始めるために必要なスキルを議論し、あなたが行うであろう最初の変更が承認されるためのベストな方法を学びます。 セッションビデオ公開済み DIAMONDスポンサーのRealm様より、セッ
オープンソース化ばんざーい！！とかそういうのは全然興味ないです、ごめんなさい。 XCode7で何気なくimport Foundationなどをすると、ついでに以下のライブラリがリンクされるそーです。SwiftCore（Swiftのコア言語仕様） Darwin（UNIXベースのOSX/iOSの基盤部分。CoreFoundationもここに含まれる） Dispatch（Grand Central Dispatch） CoreGraphics（描画処理の基盤部分。今はOpenGLだと思いますがそのうち中身がMetalになるのでしょうね） ObjectiveC（Objective-Cランタイム関数）SecuritySwiftがオープンソース化される、と言っても本当にpureSwiftのコンパイラだけが提供されてもあまり意味がないので、「どこまでがどうオープンソースになるのか？」というのが興
AutoLayoutと仲良くなった ぜんぜん言うこと聞かないからAutoLayout大嫌いだったんですが、接し方を変えたら言うこと聞くようになったので、そのコツを紹介します。 AutoLayoutにふりまわされないように AutoLayoutを使うと、色んな画面サイズに柔軟に対応することができます。今まではAutoresizingmaskを使っていましたが、AutoLayoutが主流になりつつあるので、積極的に使っていきたいです。 しかし、AutoLayoutを初めて触ったとき、なんで思い通りにならないんだ！と何度も悔しい思いをしたことがあります。挙句の果てには、見返してもよくわからない制約がいろんな場所についてしまって、しぶしぶ「Use AutoLayout」のチェックをはずしてリセットすることもありました。 初歩的なことですが、以下で紹介することを念頭においてAutoLayoutを設定
1 pixel｜サイバーエージェント公式クリエイターズブログサイバーエージェントのクリエイターの取り組みを紹介するオフィシャルブログです。最新技術への挑戦やサービス誕生の裏話、勉強会やイベントのレポートなどCAクリエイターの情報が満載です。 こんにちは。 iOS版のAmebaアプリを開発している @tasanobu と @nghialv2607 です。これまでのAmebaアプリはWebViewとのハイブリッド形式でしたが、UI/UXを改善すべくフルネイティブ化して大幅にリニューアルしました。 数ヶ月間に及ぶアプリの構成を大幅に変えるプロジェクトは、Objective-CではなくSwiftで実装を進めました。 このエントリでは、Objective-CのコードベースをSwiftへ移行していくために行った取り組みを紹介させて頂きます。 このエントリの公開時点では、Swiftを既存プロジェクトに
iOSアプリのコーディング規約を考える時はGoogleよりもNYTimesのObjective-Cスタイルガイドを参考にすべき By raimon, 2015-03-21(土), in category IosGoogleのスタイルガイドは古い 複数人でiOSアプリをObjective-Cコードで書いて保守する時、コーディング規約を検討することになる。 参考にすべきスタイルガイドとして良く挙がるものにGoogle Objective-C StyleGuideがあるが、これはいかんせん古い。メモリ管理ARCやNSNumberのリテラル構文など、比較的新しいトピックについても追記されてはいるが、 インスタンス変数のアクセス修飾子 プロパティを使う事が主流となっている2015年現在、余り扱われない autorelease を使ったオブジェクト生成など、MRC時代の規約 何よりホスティング先が
Clang-Format Style Options¶ Clang-Format Style Options describes configurable formatting style options supported by LibFormat and ClangFormat. When using clang-format commandline utility or clang::format::reformat(...) functions from code, one can either use one of the predefined styles (LLVM,Google,Chromium, Mozilla, WebKit,Microsoft) orcreate a custom style by configuring specific style opt
http://vimeo.com/109624121 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 Michele Titoloについて取り上げるのは、 「モバイルAPIデザインのまとめ」 「Ruby RoguesメンバとiOSエンジニアのAPI議論」 に続いて三回目ですが、今回はiOSアプリづくりにおけるチーム内の連携がテーマ。 彼女は現在、redditのiOSチームのリーダーをしながら、Objective-Cプロジェクトの依存関係の管理をしてくれるCocoaPodsの開発と、非営利団体 Women Who CodeのCEOを兼務しています。 redditはwebで大量のトラフィックとユーザを抱えてますが、スマホのアプリに注力しはじめ、切り口を変えた複数のreddit閲覧アプリづくりにチームで取組
はじめにSwiftのコードは多様な記述の仕方ができるので柔軟でかつ表現力もありますが、チームで開発を行うとどうしても記述の仕方が統一できず可読性も上がりません。弊社（Wantedly）でSwiftのアプリを開発した経験をもとにアプリ開発におけるコーディングスタイルガイドを作成しました。このコーディング規約がベストプラクティスだというわけではなく、Swiftもまだまだ手探りなところもあるので、参考情報としてご参照ください。また、規約の範疇ではないですがエラーになりやすい記述も合わせてフォローしています。 バージョン v0.3 改版履歴は文末を参照ください。 コーディング規約の必要性についてSwiftはプログラマがリスクを取ることによってより簡素に端的に記述ができたり、型推論が強力なので型の明記を省略して記述ができます。チームでSwift開発を行う場合は、詳細に記述するのか、省略して記述す
Retired DocumentImportant: OpenGL ES was deprecated in iOS 12. Tocreate high-performance code onGPUs, use the Metal framework instead. See Metal. Multitasking, High Resolution, and Other iOS FeaturesMany aspects of working with OpenGL ES are platform neutral, but some details of working with OpenGL ES on iOS bear special consideration. In particular, an iOS app using OpenGL ES must handle multit
#WWDCPAD の発表資料です http://connpass.com/event/6877/
Learn the recommended steps to migrate your code.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
