What's New Qiita

20190323のSwiftに関する記事は4件です。

  • 投稿日：2019-03-23T16:01:50+09:00

UIViewをaddSubViewしたあとにオートレイアウトをはる

環境

  • Xcode10.1
  • Swift4.2

余談

Swiftでコード書いてるとUIViewControllerのviewに画面いっぱいのUIViewサブクラスをaddSubviewしたり
UIViewのコンテナにxibから生成したインスタンスをコードからaddSubviewしたりすることがあるかと思います。

でも、addSubviewしただけでは親Viewに対してオートレイアウトが適応されていないのでレイアウト崩れすることがあります。

※UIViewControllerを想定して書いてるのでself.viewでもok
※hogeViewはUIViewのサブクラス

view.addSubview(hogeView)

addSubViewしたあとに親Viewの上下左右にオートレイアウトをはる

以下のようなUIViewのExtensionを作成すればVCに大量のオートレイアウトコードを書かなくて良いと思います

extension UIView {
  /// addSubViewした親Viewと同じ大きさにオートレイアウトを作成
  ///
  /// - Parameter equalTo: addSubViewした親View
  func anchorAll(equalTo: UIView) {
    // AutoresizingMaskからAutoLayoutへの自動変換を無効化
    translatesAutoresizingMaskIntoConstraints = false
    // 対象のViewの四辺にアンカーを貼る
    topAnchor.constraint(equalTo: equalTo.topAnchor, constant: 0).isActive = true
    leftAnchor.constraint(equalTo: equalTo.leftAnchor, constant: 0).isActive = true
    bottomAnchor.constraint(equalTo: equalTo.bottomAnchor, constant: 0).isActive = true
    rightAnchor.constraint(equalTo: equalTo.rightAnchor, constant: 0).isActive = true
  }
}

使い方

view.addSubview(hogeView)
// viewの上下左右に合わせてオートレイアウトをはる
hogeView.anchorAll(view)

UIViewのaddSubViewメソッドごとラップしてしまってオートレイアウトを貼ってくれるaddSubView機能をextensionで書いてもいいかもしれないですね。

おしまい

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-03-23T15:22:57+09:00

Swift から Objective-C, Objective-C++のメソッドを呼び出す

環境

Xcode 10.1

方法

  1. Objective-Cのファイルを生成する
  2. <プロジェクト名>-Bridging-Header.h ファイルを生成する
  3. ヘッダーファイルを作る
  4. Swiftからメソッドを呼び出す

ソースコード

:warning: 参考にする場合、それぞれ書き換えて下さい :warning:
1. test-Bridging-Header.h は <プロジェクト名>-Bridging-Header.h
2. ObjCTest は クラス名
3. testMethod は メソッド名

test-Bridging-Header.h

test-Bridging-Header.h
#import "ObjCTest.h"

ObjCTest.m(Objctive-C++なら、拡張子を".mm"にする

ObjCTest.m
#import "ObjCTest.h"

@implementation ObjCTest

-(void) testMethod {
    // 処理
    NSLog(@"helloworld");
}

@end

ObjCTest.h(ヘッダファイル)

ObjCTest.h
#import <Foundation/Foundation.h>
// クラス定義
@interface ObjCTest : NSObject
// メソッド定義
-(void) testMethod;

@end

ViewController.swift(呼び出し元のswiftファイル)

ViewController.swift
import UIKit

class ViewController: UIViewController {
    override func viewDidLoad() {
        // メソッド呼び出し
        ObjCTest.init().testMethod()
    }
}
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-03-23T11:28:29+09:00

【SwiftChaining】 オブジェクトの保持

SwiftChainingの解説記事その7です。

SwiftChainingとは何か？というのは、こちらの最初の記事を参考にしてください。

SwiftChainingのメモリ管理

SwiftChainingでバインディング対象にしたオブジェクトは、監視を開始してもバインディング処理の中では強参照で保持されません。

バインディング対象のオブジェクトは内部的に弱参照で保持されているので、意図的にどこかしらのプロパティなどで保持していないとバインディングの処理を書いたそばから解放されてしまって何も動かないということが起こってしまいます。

SwiftChainingのメモリ管理のポリシーとしては、「実装をし忘れて動かないことより、知らずに動き続ける方が複雑な問題を生む」という考えで極力バインディング部分で強参照しないようにしています。

とは言えUIControlAdapterやNotificationAdapterのような、本来の監視対象となるオブジェクトとの橋渡し的な役割のオブジェクトの場合、わざわざプロパティで保持するのも冗長です。

そこで、例外として送受信オブジェクトをObserver側に強参照で保持させるという方法を用意しています。

Observerに監視対象のオブジェクトを保持させる

Chainableに適合したクラスでは、SwiftChainingの内部で保持させるためにretainという関数が呼び出せるようになっています。

以前の記事に出てきたNotificationAdapterを使うコードを例にすると、以下のようにchain()の前にretain()を書く感じになります。

let observer = NotificationAdapter(MyClass.name,
                                   object: object,
                                   notificationCenter: .default)
    .retain()
    .chain()
    .map { (notification: Notification) -> String? in
        return notification.userInfo?["key"] as? String
    }
    .sendTo(receiver)
    .end()

これで、NotificationAdapterはobserverの内部に強参照で保持され、プロパティなどに保持する必要があるのはobserverだけになります。

上記のコードでretain()を挟まなかった場合には、chain()の後のmapを実行する時点で既にNotificationAdapterは解放されてしまっています。chain()はChainクラスを返すので、NotificationAdapterは必要なくなるからです。

受信対象のオブジェクトを保持させる

sendTo()で受け取るReceivableに適合したクラスでもretain()が使えるので、また別の記事にあったKVOAdapterでイベントの受信をするような場合でも、Adapterをプロパティで保持しなくても良くなります。

以下のようにsendTo()に渡す前にretain()を呼びます。

self.isOnHolder
    .chain()
    .sendTo(KVOAdapter(self.mySwitch, keyPath: \UISwitch.isOn ).retain())
    .sync()
    .addTo(self.pool)

retainを呼ぶ、というのがちょっと昔に戻った感じがしないでもないですが、解放は自動で積極的に行われるようにしているので、メモリリークを気にしないといけないようなものではありません。

retainの書き忘れ

こういったretain()のような記述はついつい書き忘れてしまいがちですが、バインディング処理の構築時にオブジェクトが解放されてしまっていないかどうかはAssertをしているので、どの変数にも入れず記述している場合は気付くことができるはずです。

ただし、ローカル変数に代入してから扱う場合は、バインディング処理の構築中に解放されることはなくAssertに引っかからないので注意が必要です。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-03-23T00:27:08+09:00

iOSアプリをリリースするためにしたすべてのこと

iOSアプリをリリースするためにしたすべてのこと

はじめましてDysonです。この度iOSのアプリを個人でリリースしました。
iOSアプリをリリースするためにしたことを今回共有します。
これからアプリを作ろうとしている人にとって参考になれば幸いです。

リリースしたアプリ

■旅の計画アプリ Sharevel [Webページ]

sharevel_screenshot_ja_1.png

このアプリをリリースするためにしたことを大まかに書くと下記の8つになります。

  1. アイデア出し
  2. 要件定義
  3. 設計
  4. 実装
  5. テスト
  6. アプリ審査
  7. リリース

それぞれの工程でどんなことをして、何を行ったか書いていきます。

1. アイデア出し

まずはなにわともあれアイデアが必要です。
最初のアイデアはANA主催のアイデアソンから生まれました。

Peatix　実現化にこだわった、新しいカタチのアイデアソン！「IT'S ON BOARD」プレイベント

アイデアソンではチームを組み、旅に関するテーマでアイデアを出し合いました。
旅がテーマだけあって何十カ国も周ったことがあるような旅行好きも多く、
旅行で楽しかったことや困ったことなどいろいろな話を聞くことができました。
アイデアづくりにあたって、その道の人に話を聞くことはとても重要だと感じました。

下記がアイデアソンで作ったものです。

1-1. ブレストのメモ書き
1-2. アンケートフォームとアンケート結果
1-3. カスタマージャーニーマップ
1-4. バリュープロポジションキャンバス
1-5. ビジネスモデルキャンバス

それぞれ紹介していきます。

1-1. ブレストのメモ

チームで話し合ったニーズや課題、体験などです。いろいろ発想を発散させていきます。この時点ではその場の思いつきも書いていきます。その中で検証すべき課題やアイデアの原型を作っていきます。

1-2. アンケートフォームとアンケート結果

ブレストで話し合った課題やニーズが本当にあるのか仮説の検証をする必要があります。その方法としてアンケートを取りました。
チームメンバーの協力のもと200名ほど回答をもらうことができました。ここで注意したことは誰から回答をもらうかです。例えば、家族向けサービスのアンケートなのに独身者ばかり回答をもらうと全然検証にならないので、誰から回答をもらうかは重要です。

Screen Shot 2019-03-21 at 14.15.18.png

Googleのアンケートを利用しました。Googleスプレッドシートに結果が反映されるので、集計作業などが楽にできました。

1-3.カスタマージャーニーマップ

ブレストやアンケートの結果から体験をカスタマージャーニーマップを用いて可視化します。
カスタマージャーニーでどこを改善すべきか、改善後どのようにユーザーの気持ちが変化するのかチームで共有します。
Screen Shot 2019-03-21 at 13.51.32.png

1-4.バリュープロポジションキャンバス

ユーザーのニーズや課題、サービスが提供する価値を1つのキャンバスにまとめます。
Screen Shot 2019-03-22 at 23.25.15.png

1-5.ビジネスモデルキャンバス

ビジネスモデルを9つの要素に分けて、それぞれの要素がどう関わるかを１つのキャンバスに書いていきます。サービスで収益を上げるならしっかり作り込む必要があります。
Screen Shot 2019-03-21 at 14.13.12.png

2.要件定義

要件定義ではアイデア出しの末、磨き上げたアイデアからサービスやアプリをデザインしていきます。
要件定義はいろいろなやり方がありますが、自分でプログラミングもするので必要最低限の範囲で行いました。
具体的にはPReP model、アクティビティ図、画面イメージ&画面遷移図を整理しました。
詳細は後ほど説明しますが、要件定義ではサービスでどんな価値を生み出し、どのようにして実現するか整理することが重要です。

そこで、PReP modelでサービスに関わる成果物を、アクティビティ図でサービスのタスクを整理します。そして、画面イメージ&画面遷移でより具体化していきます。

2-1. PReP model

PReP modelでは成果物(製品や情報など)に着目して、サービスが生み出す価値の過程を整理していきます。
ここで重要なのは成果物に着目していることです。サービスのアイデアをまとめていくと、どうしても何を使うか、どうやって作るかといった手段に気を取られてしまいます。
しかし、ユーザーに届けるべきは成果物であり、手段は何でもよいのです。
何で成果物を作るかは一旦後回しにして、成果物の生産過程を整理することが大事になります。
そのため、成果物に着目するPReP modelは重宝します。

実際に作成したPReP modelの全体図です。
Screen Shot 2019-03-22 at 23.31.56.png

こちらがストーリー更新のPReP modelの例です。
Screen Shot 2019-03-22 at 23.32.44.png
簡単に見方を説明すると、文書アイコンが成果物です。成果物は必ずしも文書とは限りません。実線の矢印が成果物作成、点線の矢印が同期を意味します。矢印というシンプルな記法のため、手段を気にせず書けます。

参考: PReP model – 超上流工程のための業務プロセスモデルと要件定義手法

2-2. アクティビティ図

PRePでサービスが何を生み出すか整理しました。次はどうやって生み出すか整理します。

PRePの矢印の部分を具体化していきます。
成果物を生み出すための活動(アクティビティ)を書いていきます。PReP modelと整合性を取ることが大事です。

作成したアクティビティ図です。
角丸の四角が手続き、ひし形が分岐、矢印がアクティビティの遷移です。
Screen Shot 2019-03-22 at 23.35.18.png

参考: アクティビティ図(Activity Diagram) - UML入門 - IT専科

2-3. 画面イメージ&画面遷移図

アクティビティを実現するための画面をデザインしていきます。粒度に多少のブレはありますが、バッチ処理を除き、1プロセスに少なくとも1画面は必要になります。
画面の構成などをデザインします。ここまでくるとアプリっぽいです。
今回は横着をして画面イメージと画面遷移を1枚にしていますが、量が多いなら画面イメージと遷移図を分けた方がよいでしょう。
Screen Shot 2019-03-22 at 23.29.50.png

3.設計

要件定義でサービスのイメージを具体化していきました。ここからはどうやってプログラムに落とし込むか整理します。要件定義ではITの知識はあまり必要がありませんが、設計からは必要になります。

今回作成したものは下記です。
3-1. ER(Entity Relationship)図
3-2. クラス設計
3-3. 対応表

3-1. ER図

データの構造を定義します。
データベースにどのようなデータを登録するか決めていきます。
Screen Shot 2019-03-22 at 23.36.40.png

3-2. クラス設計

アプリで使用するクラスを決めていきます。
ER図で決めたデータを扱うクラス以外に表示を処理するもの、共通処理を担うものなどを決めていきます。
Screen Shot 2019-03-22 at 23.38.04.png

3-3. 対応表

今まで設計したきたものの対応表です。漏れや重複がないかチェックします。
Screen Shot 2019-03-22 at 23.39.42.png

4. 実装

4-1. 環境準備

開発に必要なアカウントや設備、開発用ツールなどを用意します。
iOSなら開発用アカウントやMac、Xcode、確認用の実機iPhoneなどが必要になります。

4-2. 技術調査

いきなりプログラミングを始めても良いですが、技術的に懸念点があれば事前に確認をしておきます。(作り始めてから解消不可能な問題があると手戻りや中止に繋がります。)

今回特にEvernote連携やローカルでDB利用があり、調査、検証を行いました。
Evernote連携は結構苦労しました、、

4-3. プログラミング

調査も出来ているので、黙々とと作業をしていきます。つまずいたら、QiitaやStack OverflowやAppleの公式サイトを調べて解決していきます。
今回はSwiftで開発しました。比較的新しい言語のため、バージョンごとの差分があり、苦労する点でもあります。作ってる感があるので楽しい工程です。

4-4. プログラミング以外

4-4-1. プライバシーポリシー作成

iOSの申請にはプライバシーポリシーが必要です。
ジェネレータをお借りして用意しました。

App Privacy Policy Generator

4-4-2. 利用規約作成

結構骨が折れますが、申請に必要なものです。
他のアプリやサイトなどを参考にしながら作りました。

4-4-3. 翻訳

多言語対応(日本語、英語、中国語)をしたかったため、ラベルなどを翻訳させます。英語はまだいいですが、中国語はさっぱりできないので、二重翻訳やiPhoneの言語設定を中国語などを参考に翻訳していきました。

5. テスト

きちんと動くかアプリをテストします。
無料アプリで機能数も少ないので、テスト項目は抑えめです。商用サービスなら徹底的にやりましょう。

テスト項目はこんな感じで作りました。
Screen Shot 2019-03-22 at 23.52.50.png

6. アプリ審査

作成したアプリをアップルに審査してもらいます。審査が通らないとアプリは公開できません。
審査用のキャプチャや説明文の準備などいろいろやることがあります。
アップルの審査は厳しいのでめげずに対応を頑張りましょう。どんなに納得のいかないリジェクトであっても真摯に対応しましょう。

7. リリース

7-1. アプリ公開

審査が通ればアプリを公開できます。今回は審査が通れば自動公開の設定にしました。
iOSでは自動公開以外に時間指定の公開と手動公開があります。

7-2. 宣伝

アプリが公開したら多くの人に使ってもらいたいでしょう。
SNSなどの媒体で宣伝をします。企業のアプリであれば、
お金を使って広告をだしたりします。

今回はじめてiOSアプリをリリースしましたが、学ぶことも多くやってよかったです。
みなさんもぜひトライしてみてください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧