Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
![【最強】iOSアプリのデバイス毎の確認をiOSシミュレータを複数起動して最速で行う【最高】](https://cdn-ak-scissors.b.st-hatena.com/image/square/96c17240e5e2d585a7b88afbfdb589268b9535b1/height=288;version=1;width=512/https%3A%2F%2Fcdn-images-1.medium.com%2Fmax%2F1200%2F1%2A4nQvYibd3aHYOp1xrvmfMQ.png)
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
StoreKit の SKProductsRequest と SKPaymentQueue を Rx化して課金処理を簡単に書けるライブラリを GitHub にて公開しました。 github.com RxStoreKit を使うと課金処理を以下のような感じで書けます。 let productRequest = SKProductsRequest(productIdentifiers: Set(["xxx.xxx.xxx"])) productRequest.rx.productsRequest .flatMap { response -> Observable<SKProduct> in return Observable.from(response.products) } .flatMap { product -> Observable<SKPaymentTransaction> in r
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
この文脈では、「編集内容のキャンセル」という処理を続行しても良いかをユーザーに確認しています。続行に同意したい多くのユーザーは直感的に同じ表記の「キャンセル」を押したくなるでしょう。しかしそれでは編集のキャンセルが実行されません。 このキャンセルボタンが意味するのは、「『編集内容をキャンセルする』のキャンセル」なのです。つまり、ユーザーが望み通りに編集内容を破棄するためには、反対側のOKボタンを選ぶべきなのです。このような「キャンセルのキャンセル」は二重否定で意味がややこしくなるので避けなければなりません。 ここで「キャンセルのキャンセル」にならなければ良いということで、次のようにボタン名を変えてみました。 これでもう迷うことは無くなりましたか……? 私はこの修正は誤りだと判断します。「はい」「いいえ」は結果を予想しにくい表現なので、ダイアログのアクションボタンに用いることはあまり適切では
はじめに こんにちは、ピクトリンク事業部開発部サーバサイド開発課のkitajimaです。弊社サービスピクトリンクは、システム再構築の一環として
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
(English version here) 技術部モバイル基盤グループのヴァンサン(@vincentisambart)です。今日は最近作ったツール「Dokumi」の話をしようと思います。 紹介 他部署のエンジニアの仕事をもっと楽にすることが、技術部の重要な目的の1つです。その中で、Dokumiはモバイル開発者のコードレビューの負荷を減らすためのツールです。 なぜ「毒味」という名前にしたかと言うと、人間がレビューする前に、コードに毒(バグ、不自然なコードなど)が入っているかどうか毒味するツールだからです。別の言葉で言うと、少し進化したCI用のlintツールですね。pull requestが出る度に、Jenkinsがそのpull requestにDokumiをかけます。現在はDokumiはiOSアプリだけに対応してしていますが、今後はAndroidアプリへの対応も考えています。 現時点でDo
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
iOS7・iOS8の処理分岐なし!UITableViewのCellの高さをAutolayoutで自動計算する方法 こんにちは、 iOSエンジニアの木村です。 2015年最初のエントリーはUITableViewCellの高さをAutolayoutを用いて計算する方法を紹介したいと思います。 一見、チュートリアルなどでよく見かける内容ですが、iOS8対応をするとiOS7ではうまく動かなくなってしまうなど、OSの違いが元でUITableView周りは結構トラブルが起こります。 今回はiOS7とiOS8で分岐を行わず、同じコードで動く方法を紹介したいと思います。 iOS7との互換性を保つためUIAutomaticDimensionは使用しません。 今回作るもの 以下のように タイトル(title) 詳細(body) を持ったDataオブジェクトを一覧で表示したいと思います。 class Data
Push通知の確認ダイアログの表示タイミングを色々テストするときに、再表示させるためのデバイスの操作を毎回忘れるのでメモ。 手順 アプリをアンインストールして1日以上経過した状態を作りだすのが重要みたい。再起動は面倒だけど省くと上手くいかないです。 デバイスの時刻を自動設定から手動に変更 アプリをアンインストール デバイスを再起動 iPhone の時刻を1日以上未来に手動で変更 デバイスを再起動 アプリを再インストール 参考 Troubleshooting Push Notifications The first time a push-enabled app registers for push notifications, iOS asks the user if they wish to receive notifications for that app. Once the use
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く