投稿日：2019-05-22T23:51:13+09:00

処理中にNavigationBarのボタン操作を無効にする。

まくら

Navigation Controller を使ったアプリを作っている時に、稀によくある問題に対するアプローチです。

例えばこんな場合

とある画面で時間のかかる処理中に読み込み中のインジケータを出したい

インジケータが出ている間はナビゲーションバーの操作（戻るボタンとか）を無効にしたい

インジケータを出すのはいいとして、操作を無効にする方法はいくつか思いつきますが、今回は前面に目隠しを出して操作できないようにしてみましょう。

ほんだい

まずはソースをどうぞ。
インジケータを表示する部分です。
    // インジケータを表示する
    private func showIndicator() {

        // 背景になるView
        let backView = UIView()
        backView.backgroundColor = UIColor.init(white: 0.0, alpha: 0.5)
        backView.tag = 12345 // 消す時用にタグを付けておく

        // インジケータ
        let indicator = UIActivityIndicatorView()
        indicator.activityIndicatorViewStyle = .whiteLarge
        indicator.frame = CGRect(x: 0, y: 0, width: 100, height: 100)

        // NavigationControllerのViewを使う
        guard let naviView = self.navigationController?.view else {
            return
        }

        // 背景にインジケータを貼り付け
        backView.addSubview(indicator)

        // 背景をNavigationControllerのViewに貼り付け
        naviView.addSubview(backView)

        // サイズ合わせはAutoLayoutで
        backView.translatesAutoresizingMaskIntoConstraints = false
        backView.topAnchor.constraint(equalTo: naviView.topAnchor).isActive = true
        backView.bottomAnchor.constraint(equalTo: naviView.bottomAnchor).isActive = true
        backView.leftAnchor.constraint(equalTo: naviView.leftAnchor).isActive = true
        backView.rightAnchor.constraint(equalTo: naviView.rightAnchor).isActive = true

        // インジケータもAutoLayout
        indicator.translatesAutoresizingMaskIntoConstraints = false
        indicator.centerXAnchor.constraint(equalTo: backView.centerXAnchor).isActive = true
        indicator.centerYAnchor.constraint(equalTo: backView.centerYAnchor).isActive = true
        indicator.widthAnchor.constraint(equalToConstant: 100).isActive = true
        indicator.heightAnchor.constraint(equalToConstant: 100).isActive = true

        // インジケータ起動
        indicator.startAnimating()
    }
これを適当に実装するとこんな感じになります。

ポイントはNavigationBarがグレーのViewに覆われていてBarButtonItemが押せない状態になっているところです。

ここですね。
    // NavigationControllerのViewを使う
    guard let naviView = self.navigationController?.view else {
        return
    }
    // 背景をNavigationControllerのViewに貼り付け
    naviView.addSubview(backView)
要は、NavigationController.ViewにもaddSubViewできますよって事ですね。

NavigationControllerの上にViewを貼り付けるので、当然その下のボタン等は押せなくなるわけです。

ちなみに注意点としては、当然ですが、NavigationController.Viewが存在しないと使えません。

prepare for segueの遷移時などNavigationControllerが追いづらい時には正直使いづらいです。

現場からは以上です。

　 Tweet
Qiitaで続きを読む

投稿日：2019-05-22T23:43:38+09:00

FlutterでWebアプリが書けるようになった

https://9to5google.com/2019/05/07/flutter-apps-web-desktop-more/
↑が原文です。変なところあればご指摘いただけるとありがたいです。

Flutter doubles down on ‘write once, run anywhere’ apps w/ web, desktop, more

おおよそ全ての開発者は、モバイルアプリとウェブアプリ・デスクトップアプリ間で統一をもたせる、あるいはそれを維持することの難しさはよく知るところだろう。FlutterはiOSアプリとAndroidアプリの間のギャップを埋めるフレームワークとして知られているが、この度その領域をWebまで広げ、「一度書けばどこでも動く（write once, run anyware）」の夢へと更に近づいた。

これまでFlutterは、iOS/Android関係なく同じ見た目・振る舞いをするモバイルアプリを作るためのGoogleのフレームワークとして知られていた。昨年行われたFlutterの最初のイベントで、GoogleはFlutterをモバイルアプリ領域を飛び越えてWebまで飛躍するためのHummingbirdプロジェクトを公開した。

Google I/O 2019では、Googleは「FLutterはモバイルアプリだけ」という概念を取り払おうとしている。GoogleはFlutterを”portable UI toolkit”として企業や開発者がプラットフォームごとにアプリを作るのではなく、アプリを１度作るだけで全てのプラットフォームで動作することを可能にしようとしている。そのために、Webアプリやデスクトップアプリ、そしてRaspberry Piのような組み込み系のプラットフォームでも動作することを目標にしている。

本日のイベント前に、私は小規模なFlutter製Webアプリを自分のマシンにインストールしてもらう機会を頂いた。そのアプリを触ってみて私が最初に気づいたことは、動作速度の速さである。これは、Dartで書かれたFlutterがJavascriptのようなWeb言語にコンパイルされているから実現できることである。下記画像のように、ブラウザ上でネイティブアプリのように読み込まれる。

Flutter製Webアプリの印象的なところはもう一つある。それは、Hummingbirdデモであったスライドパズルのごとくアニメーションがヌルヌル動くことである。4K Lenovo Yoga Chromebookやthe Pixel 3で動かしてみても、動作が遅くなることはなかった。

デスクトップアプリの観点から見ても、Flutterの成長速度は著しいものである。Flutter製アプリはChromeOSのサポートの甲斐あってChromebookでもすでによく動作するが、キーボードやマウスのサポートはここ数ヶ月で少し落ち込んでいる。Windows、Mac、Linuxなどのコンピュータで動作させることが優先されているため、これらのサポートは先に持ち越されているのだ。

ゆくゆくは、GoogleはFlutterがおよそ全てのデバイスで動作させることを目標にしている。一つのFlutter製アプリが複数のプラットフォームで動作するのだ。”scenarios including home, automotive and beyond.”

Googleはあらゆるアプリ開発技術の中でFlutterを一番にしようとしている。あなたの作りたいアプリがAndroid向けであれ、iOSであれ、ChromeOS、Windows、Web、IoTその他なにであろうと関係ないのである。これは驚異的なことだ。

　 Tweet
Qiitaで続きを読む

投稿日：2019-05-22T21:43:59+09:00

iOSリリースのためにアーカイブを行う

iOSアプリをリリースする手順はAndroidよりも複雑です。
今回はファイルをアップロードする手順に特化して記載したいと思います。
iOSアプリをリリースする際にはファイルを作るだけでなく、アップロードまでxcodeでできてしまいます。

①アーカイブ

ipaファイルとしてビルドする作業になります。
XcodeのProductからArchiveを選択して、ビルドを行います。

その時にArchieveが選択できない事象が起こることがありますが、エミュレータや実機を選択しているとなるので、「Generic iOS Device」を選択するとArchieveを選択できるようになります。
問題なくビルドできれば成功です。

②Validate App

次に、アップロードするファイルに問題がないかをチェックします。
アーカイブが成功すると、ファイルをアップロードする画面が表示されます。
もし、表示されなければ、Windows→Organizerを選択すれば、表示されます。

上記のValidate Appを選択します。
選択するとオプションが表示されます。

下記は「Automatically manage singing」を選択しました。
証明書やApp IDsを紐づけてくれるので、手動で行うより楽です。

Validateを選択し、SuccessFullyになればアップロードします。

ここで失敗するのはビルドのバージョンがあがっていない(更新の時)などがあるようです。

➂Distribute App

ここまでうまくいけばあとはアップロードするのみです。
Distribute Appをクリックして、オプションを設定します。

製品版であれば、「iOS App Store」を選択、開発版であれば、「Development」、リモートでのテスト用では「Ad Hoc」を選択など、用途によって選択します。

ここではUploadを選択します。

次からはValidate Appでも選択したオプション選択になるので、用途に合わせて、選択していきます。
ただ、「Automatically manage singing」は意識的に選択しました。

最後に、Uploadを選択すると、アップロードが開始され、成功すれば、successfully uploadedと表示されます。

Androidより手順が複雑で大変な印象ですね。
しかも、他にも証明書やアプリの登録など手順がまだまだあります。
それに関しては、他でまとめたいと思います。

参照

[iPhone] アプリ申請のためXcodeでアップロードする

　 Tweet
Qiitaで続きを読む

投稿日：2019-05-22T20:15:37+09:00

WebViewとネイティブのメリットデメリット

App内で動作する簡易ブラウザ(WebView)と通信からUIまでアプリ内で完結するネイティブアプリのメリットデメリットをまとめてみました。

■WebViewのメリット・デメリット

メリット

コストが安い
Web上にコンテンツがあり、それを流用したい場合、新規で開発することなく同じコンテンツを表示できます。

アプリストアへの申請・審査の不要
ネイティブアプリの申請や審査が不要になります。
※ただし、部分的なWebView表示の場合ネイティブと変わらないので審査は必要です。

アプリアップデートの不要
アプリの保守をする必要がないため、アプリ自体のアップデートがありません。
※仕様が変更された時は、アプリの動作を変更する可能性があるため、一概ではないです。

デメリット

課金ができない
Apple Store審査ガイドラインの規約違反になり、リジェクトされる恐れがあります。
※Webブラウザでの課金は可能(リンクをブラウザへ飛ばす必要あり)
引用：Apple Store審査ガイドライン：3.1.1 App内課金

レスポンシブ対応
画面解像度に応じたUI設計の対応が必要。
Webの表示をそのまま、アプリに適応させると表示崩れが起こる可能性がある。

脆弱性

自社以外の外部アクセス

URL直打ちで、自社ではないサイトにアクセスできる場合、悪用される恐れがある。
外部アクセスできるサイトに制限を設ける必要がある。

端末内のファイルストリームにアクセスできる

「file://」で始まるURI(※URLではない)でアクセスすることで、端末内部のファイルにアクセスすることができる。
アクセスログからユーザー情報が漏洩されてしまう。

iOSは、Cookieを保存しない

アプリが終了するとCookieが消えるので、永続化する必要がある

XSSの恐れ

攻撃スクリプトを入力できてしまう。
サニタイジング(無害化)する必要がある。

通信エラー場合の表示
通信エラー場合のWebView画面を表示する前に、レスポンスチェックを行い、ネイティブの別画面を表示させる。
WebViewは通信した結果の表示なので、真っ白になったり、URLエラーになったりしてUI的に作りが悪い。

環境によっては表示が遅い
Web通信が伴うため、通信環境によっては表示が遅い場合があります。

導線が不可能
WebViewの誘導はできない。

■ネイティブ画面のメリット・デメリット

メリット

Webではできない画面設計・操作設計ができる
アプリ内のUIを使用するため、自由に画面設計を行うことが可能

導線設計が可能
アプリに誘導できる

セキュリティ
URL直打ちではないため、外部のサイトへアクセスさせることはないです。

デメリット

コストが高い
iOS / Androidの開発者が必要
開発言語が異なるため、それぞれの開発者が必要

アプリストアへの申請・審査
ネイティブアプリの申請や審査が必要です。

アプリアップデートが必要
保守でアプリ修正があった場合は、アップデートが必要

課金
App内課金を(30%)手数料(30%)が発生する

引用

https://appbu.jp/webapps-nativeapps
https://ja.developer.box.com/docs/android-security-guidelines
https://appkitbox.com/knowledge/android/20130819-84
https://teratail.com/questions/100872
https://mexess.blog/2018/08/03/post-304/
https://qiita.com/noboru_i/items/240ffcb2036f3b5cbc3b
https://qiita.com/noboru_i/items/bc39d95638e9e55437fa#cookie%E3%81%AE%E8%A8%AD%E5%AE%9A
https://qiita.com/i_nak/items/be0fac91bdc68aa165db
https://backapp.co.jp/blog/11594/
https://support.ebis.ne.jp/search_service/15033/

　 Tweet
Qiitaで続きを読む

投稿日：2019-05-22T18:42:11+09:00

AutoLayoutとStackViewを駆使して、縦と横で異なるレイアウトを設定する。

iOSアプリを開発しているとき、縦と横でレイアウトがちょっと異なるアプリを作りたいときがあります。
ほとんどはAutolayoutを適切に設定すればなんとかなりますが、下記イメージのように、部品の位置が変わったり、縦のときは２行、横のときは１行にしたいなどの場合があり、設定に悩みます。
縦イメージ
横イメージ

今回、AutoLayoutとStackViewを駆使すればなんとかなったので、その設定方法を説明します。

まず縦画面状態で部品を配置します。
まだAutolayoutは設定していません。

配置後、画面下の部品をStackViewに入れていきます。
縦StackView
- 横StackView
- - View
- - View
- - View
- 横StackView
- - View
- - View
- - View

赤い警告がでていますが、一旦無視で進めます。

画面下部のVary for Traitsを押し、Heightを選択し
AutoLayoutを設定していきます。
こうすることで、縦モード時のみ有効になる制約を設定できます。

続いて横モード時のみ有効になる制約を設定していきます。
Orientationを横にし、Very for TraitsはHeightを選択します。

外側のStackViewのAxis設定に、HeightがCompact時はHorizontalに設定します。
こうすることで、横モード時は横並びのStackViewにすることができます。

一通りの制約設定とStackViewの設定が完了しました。

動かしてみたところ