Workouts Diary プライバシーポリシー
BLEMessengerLite privacy policy [English Ver]
privacy policy
We will not provide information that can identify individuals to third parties. Pay close attention to the management of personal information and treat it as listed below.
Also, in order to improve the convenience of the application, we carefully pay attention to the extent that individuals can not be identified anonymously, and analyze the access. For example, when an application crashes, we send anonymously what part it crashed, and it helps to fix bugs quickly. In addition, we analyze usage rate of device and application version, utilization ratio of specific function, etc., and use it for improvement of application. (For example, prioritizing improvements of more used functions)
※ If you have any questions, please do not hesitate to contact us.
Japanese Version is bellow.
BLEMessengerLite プライバシーポリシー [日本語バージョン]
プライバシーポリシー
第三者に個人を特定できる情報を提供することはありません。個人情報の管理には細心の注意を払い、以下に掲げた通りに扱います。
また、アプリの利便性向上のため、匿名で、個人を特定できない範囲に細心の注意を払い、アクセス解析をしております。例えば、アプリがクラッシュした時、どの部分でクラッシュしたかを匿名で送信し、バグの素早い修正に役立たせております。 また、デバイスやアプリバージョンの使用率、特定の機能の使用率などを解析し、アプリの改善に役立てています。(例えば、より使われている機能の改善を優先的の行うなど)
※ご不明な点があれば、お気軽にお問い合わせください。
英語版はこちら English ver is bellow.
BLEMesプライバシーポリシー [日本語バージョン]
プライバシーポリシー
第三者に個人を特定できる情報を提供することはありません。個人情報の管理には細心の注意を払い、以下に掲げた通りに扱います。
また、アプリの利便性向上のため、匿名で、個人を特定できない範囲に細心の注意を払い、アクセス解析をしております。例えば、アプリがクラッシュした時、どの部分でクラッシュしたかを匿名で送信し、バグの素早い修正に役立たせております。 また、デバイスやアプリバージョンの使用率、特定の機能の使用率などを解析し、アプリの改善に役立てています。(例えば、より使われている機能の改善を優先的の行うなど)
※ご不明な点があれば、お気軽にお問い合わせください。
English Version is bellow.
BLEMesForMac App Private policy [English version]
Private policy
The information which can specify an individual isn't offered to a third person. Scrupulous notice is taken of management of personal information, and it's handled as I inserted in below.
Scrupulous notice is being taken of the area where an individual can't be specified anonymously for advantage convenience improvement of an application and an access analysis is being done. For example when an application crashed, I'm sending at which part you crashed anonymously and am making the correction with the quick bug useful. The usage rate of the device and the application version and the usage rate of the specific function are being analyzed and it's being used for improvement of an application. (Of improvement of the function you for example I choose and use, prior, such as I do.)
※ When there is an unclear point, please inquire any time.
Japanese version is bellow.
iOSアプリ開発をした際に思ったことまとめ
現行のアプリがWebView主体だったため、ネイティブにリニューアルするプロジェクトをやらせていただくことになった。
新規にアプリを作る上で気にしたことをいくつか書いていこうと思います。
主に自身の備忘録のため。数年後に見直して、今思っていることからどう変わったのかを確認する目的もあるためご了承お願いします。
［目次］
言語の選択
コーディング規約
ソースコード管理
クラス設計
実装
実装における留意点
やるべきではないこと
所感
＊＊＊
・言語の選択
自身が使いこなせる言語であれば問題ない。今回、経験なくとも書いたことある、というのなら良いということでSwift 4を選択した。
・コーディング規約
一人で作り上げるが、備忘録のために実装における規則を作った。場所は社内wikiにまとめた。書いていくと気づかなかったことが見えてくることもある。
・ソースコード管理
ソースコードはgit labで管理することにした。アプリ開発は切り戻すことがあるため、こまめにpushしておき、必要に応じてブラウザなりcloneなりを行う。
・クラス設計
iOSアプリにおいて注力するのがここ。これを間違うとうまくいかない。機能ごとに何の役割を担わせるのか、という視点で全体を構成しておく。異なる役割を同じクラスには書かない。設計書はあれば越したことはないが、なくともはじめに階層を作っておくだけでも理解がしやすい。ここでいう役割とは、例えばAPIアクセスや、表示処理、取得済み要素の演算など。
・実装
アプリを実装するにおいていつもやっている順序
・クラス名を決める
・見た目（xib, storyboard）にて画面を作る
・見た目ができたらライフサイクル上で何を置くかを決める（何をどのタイミングで行うか）
・登場する機能を整理、および配置する
・配置したら各々で役割を実装する
・動作確認
＊＊＊
留意点
・密結合をできるだけ行わないこと
なぜかというと、仕様変更に弱い傾向になってしまう。修正するたびに既存の処理を見直すことはすごく面倒だし工数もかかる。
反対に疎結合にしておくと、直したい機能があればその箇所だけ直せば良いし、付け足したいならユニットを取り付けるだけで済む。
・functionに引数を極力使わない
依存させる処理があるなら、別functionにまとめない。ラップする処理は見た目はいいが追いにくい。多少見た目が雑でも、分ける必要がない処理は羅列させる方がいいこともある。
extentionの場合を除く。
・共通処理の際はオーバーライドを使う
共通処理が中身が全く同じものであれば別だが、実装したい機能において似通った機能であればインプット、アウトプットが異なる場合は、オーバーライドを行うと良い。
・非推奨な関数は使わない
Xcodeで非推奨となっているステートメントは将来使われなくなる可能性が高い、というかXcodeのバージョンアップによって消えて無くなる。そうなった際にビルドエラーとなるので、目的を達成できる別の書き方により実現する。
＊＊＊
やるべきではない
ViewControllerなどの1ファイルにcontroller、model、viewをまるごと突っ込まれたソースコードを見たことがあるが、アレは良くない。
なぜ良くないかというと、処理が追いにくい。
処理を追うためには識別するものがあるとわかりやすい。その識別するものの例として、modelやviewを別クラスとして定義しておく。それらがcontrollerから分離されていたら参照ができる。controllerから参照することによって別物として捉えることができるため、実装者が処理の流れを理解しやすい。
＊＊＊
所感
MVCモデルを考える上でなぜ必要なのかを理解することにより、変更が容易に可能なプロジェクトをつくることができる。
目の前のことだけに集中して行き当たりばったりなやり方はその場ではやり過ごすことができるとしても、あとあと苦しむことになる。
全体を見渡してやるべきことを起こした上で実装を進めると、スムーズに開発を進めることが出来る。
天気情報アプリ Mac版リリース！
概要
天気情報配信 iOSアプリを先日リリースし、APIをMac版ネイティブアプリにも使える！と思ったのでMac版に応用しリリースしてみた。開発にあたって試行錯誤したことを書きます。
実装スキルを向上したい方向けに書いていますが個人主観が強いため、参考にならない場合もあります。あしからず。
リリースしたアプリはこんな感じです。
作る上で気をつけたこと
いつも気にしているところをいくつか取り上げてみる。
役割毎に処理を分割し再利用をするため、できるだけ疎結合にすることを心がける。チェーン状（密結合）になってしまうと、処理が前後で依存してしまうため他処理への流用がしにくくなり、関数化する意味がない
できること、できないことを早めに判断し、必要に応じて別の手法で解決するよう心がけることで無駄な調査をやめる。できないことにいつまでもこだわってしまうと、時間を浪費してしまうため実現したい機能が作れなくなる
なるべくStackOverFlowは見に行かず、Apple Swift APIを参照しながら実装を進めた。理由としては、サンプルコードを実行するわけではないので、ピンポイントで調査できるため
ハマったこと
環境設定画面の見せ方でハマった。最初はsegueのshowで画面遷移を実装していたが、showを使ってウィンドウを表示してしまうと、クリック毎にウィンドウが生成されるため見栄えとしてはよくなかった。AsSheetを用いるといい感じのUIになったため、採用し解決。
Macアプリ制作の難易度的には
本業ではないため完全に主観だが、iOSアプリ開発主体の身からしたらMacアプリ開発の言語はiOSと同じなため、なんとかなる、といったところ。
ただ、APIはiOSと比較して非常に不親切な作りとなっている。かゆいところに手が届かない。
Macアプリに関してはそんなに開発者多くないせいか、言語に対する開発のしやすさの面でいうと、開発しにくい印象。
本アプリの開発環境は以下のとおり
- IDE : Xcode9.1
- 開発言語 : Swift4.0
- 対象デバイス : MacOS
- OS : MacOS 10.13.4 High Serria
- Core : FMDB
- APIラッパーライブラリ : Alamofire
- ソース管理 : Github
- API : PHP、Apache、MySql
- サーバ : CentOS
- リリース対象 : MacAppStore (MAS)
所感
どちらかというと技術記事読みながら、というよりもApple Swift 各種APIを参照しながら、足りないものはApple Referenceを見にいくやり方が自分には一番しっくりくる。
そうしていくと、壁に当たることもあり、適宜トライ＆エラーを繰り返す。見つけたTipsは技術サイトなどに投稿し、書き溜めておいて同じところで時間を使わないようにしておく。
アプリの紹介
よろしければダウンロードしていただけると嬉しいです！
↓ここから↓
