仕様の検討

[ofl]

不明瞭な点をここに記入。

[ofl]

ログインボーナスの流れ、

クライアント側で本日初めてのログインかどうかをチェック => サーバーにpoints/add

で良いか。 サーバー側でチェックすべきか（本日初めてのログインか？、１ポイント以上追加されていないか？）

[ofl]

トーク３往復の判定

1. ３往復したという判定の基準
2. 端末側、サーバー側どちらで判定するか

[ofl]

「いいね」にメッセージは不要か？

[ofl]

相手との状態「いいね、相手からいいね、マッチング、ブロック」はどこに保存すべきか？

[ofl]

検索条件設定について 条件が多すぎてindex化しずらい。

[ofl]

「性格」「趣味」など複数選択可能なものをどうやって保存/検索するか。 =>ビット演算が使えるか

[Araki]

ログインボーナスの流れ →システムが絡むのでツッチーと相談します。

トーク3往復の判定 →これもツッチーと相談します。

いいねにメッセージは不要か？ →不要です。

いいね、相手からいいね、マッチング等ステータス管理 →どこのテーブルに保存するかツッチーと相談します

検索条件 →検索条件を絞り込んだ方がよろしいでしょうか？

性格、趣味等複数選択の保存検索 →ツッチーと相談してみます。

以上、よろしくお願い致します。

[ofl]

「いいね」は一人に対して一回限りか？

[ofl]

アプリ起動中に新着メッセージを知らせる仕組みは、apnで良いか。 （別案: クライアント側から一定間隔でpull request、long pollingなどつなぎっぱなしの状態にする等）

[ofl]

検索条件を絞り込んだ方がよろしいでしょうか？

いくつか方法は考えられると思います。

1. indexをはらずに力づくで検索
2. indexを貼る（保存にかかる時間が長くなる） => プロフィール自体はそれほど頻繁に修正されるものではない。 => ただ、ポイントやログイン日時などが頻繁に更新される。
3. プロフィール部分は別テーブルにする
4. サーバー側の検索項目を減らしてアプリ側でフィルタリング
5. 他に良い方法はないか調査

[ofl]

メッセージには何らかの制限を設けるか (例：一人の相手に一方的に連続して◯◯回は送れない、または何分以上あけないと送れない。)

設けるとすればサーバー側で制限するようになるか。もしくは端末側だけで大丈夫か？

[Araki]

いいね →1人に対して1回限りです。

アプリ起動中の新着メッセージ →ツッチーと相談します

検索条件 →頂いた選択肢の中でどれが良いか検討してみます。

メッセージになんらかの制限を設けるか？ →前提として、相互にいいねになるとメッセージできるようになるが、男は基本相手のメッセージに対して返信ができないので、「トーク」を使用すれば無制限にメッセージのやり取りができるようになります。 トーク使用後は無制限にメッセージのやり取りができるようになるので、特に制限を設ける必要はないです。

[ofl]

ユーザーのリストを取得するときにすべてのカラムの値が必要か？

ID、ニックネーム、メインの画像URL、住所、自己紹介ぐらいが必須で、あとはそのユーザーの詳細が必要なときに取得するようにすれば、一回の通信でより多くのユーザー情報を取ってこれる。

[ofl]

メッセージに禁止用語を設けるか

[ofl]

セッションに期限を設けるか。

[ofl]

非表示は相手にわかるようになるか？ =>なっていないと、相手は無駄にトークを使ってしまうことになるが良いか？。 非表示は端末側のみの設定か？ =>サーバー側で把握していないと、Push通知がいってしまう。

[ofl]

ユーザーの一覧の「全て」だとお気に入りとLikeが混ざって表示されているので、一つのモデルにした方がよいかも。

[uniom]

ログインボーナスについて ・ログインボーナスはサーバー側でチェックするよううにしたいです。（チートを防ぐため）

トーク３往復の判定について ・トーク３往復の判定の基準は双方が3通以上送ったときに成立し、サーバ側で判定します。

「いいね」にメッセージは不要か？ ・「いいね」にメッセージは不要です。

相手との状態「いいね、相手からいいね、マッチング、ブロック」はどこに保存すべきか？ ・「いいね、相手からのいいね」はlikesテーブル「マッチング」はmatchesテーブルに保存してください。 ・ブロックの仕様はなくなったのですが、仕様書に残っていました。申し訳ないです。

「性格」「趣味」など複数選択可能なものをどうやって保存/検索するか。 ・「性格」「趣味」など複数選択可能なものはuser_charactersテーブル、user_hobbiesテーブルに保存してください。

アプリ起動中に新着メッセージを知らせる仕組みは、apnで良いか？ ・apnsで良いです。

検索条件について ・検索は「indexを貼る」でお願い致します。ポイントやログイン日時にindexを貼らなければ、それらの更新時間は長くならないと思われますがいかがでしょうか？

メッセージには何らかの制限を設けるか？ ・男性は無課金の場合、一通のみ相手に送信、または返信することができます。 ・男性の場合、課金しないと2通目は送れません。 ・サーバー側でコントロールしてください。

ユーザーのリストを取得するときにすべてのカラムの値が必要か？ ・ユーザーのリストを取得するときには課金情報など、ユーザに表示しない情報以外はすべて取得できる必要があります。

メッセージに禁止用語を設けるか？ かけます。docomo,softbank,ezweb,au,lineとこれらの大文字とひらがな、カタカナを禁止にしたいです。 ・メッセージ禁止用語はあとから追加、更新できるようにしたいです。

セッションに期限を設けるか？ ・セッション期間はもうけませんが、アプリ起動時とフォアグランド復帰時にセッションを確認します。

ユーザーの一覧の「全て」だとお気に入りとLikeが混ざって表示されているので、一つのモデルにした方がよいかも。 ・非表示、ブロックの仕様はなくなりました。 ・ユーザの一覧は「すべて」は無しで、「マッチング」「相手から」「自分から」「お気に入り」の4つでお願いします。

[ofl]

写真に順番は必要か？ 必要とすれば「並び替え」機能は必要か (上位の写真をいったん削除することで並び替えをするのであれば、created_at順でも良い)

mainの写真は常にorderが1か だとしたらorderだけでも良くないか

[ofl]

サーバー上でのポイントの収支

収入

1. ログインボーナス
2. In App Purchaseによる購入
3. 他ボーナス？
4. 他のサービスとの連携による追加？
5. 他のユーザーとのやり取り？

支出

1. points/consume

[ofl]

女性会員にとってポイントは特に必要のないもの？

[ofl]

都道府県で県名を返すことは必要か？それとも0〜46(1〜47?)の数字で良いか？

[ofl]

県名同様に値がリストの中のいずれかであるものについては数字で良いか。 学歴 体型 年収 休日 同居人 タバコ お酒

[ofl]

最終ログインの日時はverifyの時に更新するので良いか？ それとも全ての操作で更新が必要か？

[ofl]

「お知らせ」には運営からの通達と「いいね」したユーザーからの自己紹介のようなものが混ざっている。

1. Infoモデルを作成する(user_id, target_id, message)。
2. 「いいね」した時にプロフィールの自己紹介をコピーしてinfoを作成するか？
3. 「未読」の状態はサーバー側でも保存するか？。

[ofl]

相手を画像から選ぶ場合の画像のリストはメイン画像のみか？。 ユーザーの一覧時にはすべての画像URLも必要か？

[ofl]

「いいね」の一日の上限はサーバー側でチェックするか？

[ofl]

トークポイントはサーバー側で把握する必要があるか？

[ofl]

予定している端末側で認証したFBのアクセストークンを受け取って、ユーザーを検索してなければ、作成というサインインの仕組みは、FBのトークンが通常2週間、最長でも2ヶ月後には失効してしまうので、一度ログアウトもしくはセッションを破棄されると再度アクセストークンからユーザーを探すことができなるという点でまずい。

=>セキュリティの観点からもサーバー側でOauthログインしてもらう方が望ましい。

=>端末側でもOauthが必要になると重複してFBにログインすることになり混乱や敬遠されてしまう。

[ofl]

ユーザーのステータス（アカウント停止中など）が必要か？

また、ログイン後、すぐにお相手探しの対象となるのか、それともプロフィールの必須項目を記入しないとリストに上がってこないようにしておくのか？。

[uniom]

・写真に順番は必要か？ 必要ありません。（created_at順になります） 並び替え機能も必要ありません。 mainの写真かどうかの情報は必要になります。

・サーバー上でのポイントの収支 収入は1．2．の他にTapjoyというリワード広告プラットフォームによるポイント獲得があります。 支出は1．のみになります。

・女性会員にとってポイントは特に必要のないもの？ 「いいね」と「トーク」でポイントは消費されます。 基本的には男性と同じメニューです。

・都道府県で県名を返すことは必要か？それとも0〜46(1〜47?)の数字で良いか？ 都道府県コード（１〜47）で返してください。

・県名同様に値がリストの中のいずれかであるものについては数字で良いか。 FacebookのAPIを参考に、IDと文字列の配列として返してください。

・最終ログインの日時はverifyの時に更新するので良いか？ 全ての操作で更新を行ってください。session idのverifyは全ての操作で行う必要があると思っています。

・「お知らせ」には運営からの通達と「いいね」したユーザーからの自己紹介のようなものが混ざっている。 「いいね」した時にプロフィールの自己紹介をコピーしてinfoを作る必要はりません。 「メッセージが来た」や「いいねが来た」、「マッチングがされた」、「Facebookの公開」がわかればいいです。 「未読」の状態はサーバ側でも保存します。

・相手を画像から選ぶ場合の画像のリストはメイン画像のみか？。 メイン画像のみです。

・ユーザーの一覧時にはすべての画像URLも必要か？ すべての画像のURLが必要になります。

・「いいね」の一日の上限はサーバー側でチェックするか？ サーバ側でチェックをお願いします。

・トークポイントはサーバー側で把握する必要があるか？ ポイントでトークを購入できます。ポイントはサーバ側で管理する必要があります。

・認証について なるほど。仕様の変更になりますが、FBのアクセストークンをユーザ検索につかうのではなくて、uuidのようなアプリ内で独自のIDでユーザの検索を行い、FBのアクセストークンはFBへのアクセスのみに使用するようにするのはいかがでしょうか？

・ユーザーのステータス（アカウント停止中など）が必要か？ プロフィールの必須項目を記入しないとリストに上がってこないようにしておく必要があります。 アカウント停止中以外にも、ステータスを設定する必要があります。 アカウント作成、プロフィール入力中、プロフィール入力完了、いいねボタン押下、課金など各種アクションでのステータス遷移（コンバージョンファンネル）を 公開測定（コホート分析）を行う際に活用したいと思っております。

[ofl]

uuidのようなアプリ内で独自のIDでユーザの検索を行い、FBのアクセストークンはFBへのアクセスのみに使用するようにするのはいかがでしょうか？

それはそれで良いかと思いますが、FBの認証を使ったほうが、端末を変えたり複数の端末でも同じユーザーとして利用できる点は良いかと思います。 上で端末、サーバー両方でFBの認証と書きましたが、サーバー側でしてアクセストークンを端末に渡すようにすれば、両方で認証してもらう必要はないかと思います。

各種のアクションでのステータス遷移を 公開測定を行う際に活用したいと思っております。

これはログを取るということでしょうか。

[uniom]

サーバ側でFB認証する弊害はありませんでしょうか？なければそうのような方式でOKです。

これはログを取るということでしょうか。

ログを取るという意味です。ステータスの変更だけではうまくいかなさそうなので、ログ用のテーブルを作る必要がありそうですね。

[ofl]

FB認証する弊害は、アプリ側からFacebookのAPIを直接呼び出すときにtokenの有効期限が切れていた場合の処理でしょうか。 サーバーを通じてFacebookを操作するか、サーバー側でいったん認証をし直してもらわなくてはいけません。

iOSでサーバーサイドでのFB認証の実装の参考となる事例を探したんですけど見つかりませんでした。 ただ、自分はTitanium mobileでアプリを作っているんですが、同じ事をしたことがあるのでObjective-Cでももちろん可能です。

流れとしては

1. CoupliingServerの認証URLにUiWebViewもしくはSafariでアクセス。
2. サーバーは秘密鍵等のパラメーター付きでFBの認証画面にリダイレクト。
3. ユーザーに認証してもらう。
4. FB側にあらかじめ登録したCoupliingServerのcallback urlにリダイレクトされる。
5. CoupliingServer側でユーザー検索/作成を行なってsession_idやfaceebookのtokenを返す。
6. UiWebViewの場合callback urlが表示されたらjavascriptでその内容を読み取ってアプリ側に保存する。
7. (試してないのですが、Safariの場合、ユーザーにリンクを押してもらってsession_id等の内容をurl schemeを使ってアプリに送る。)

サーバーを通じてFacebookを操作するようにすればfacebookのアクセストークンを端末に保存する必要はないので、より安全です。

[ofl]

ポイントの換算

いいね = 10pt トーク = 50 pt 初期値 = 300pt ? ログインボーナス = 10pt?

女性にもログインボーナスは有り？ いいねポイントは30が上限という制約は無しか？。

[uniom]

普段仕事でiOSアプリの開発をしているのですが、FB認証はすべてクライアント側で済ませてしまっているので、 今回はその方法で行きたいです。

[uniom]

女性にもログインボーナスは有り？

ありです。

いいねポイントは30が上限という制約は無しか？。

無しです。

[ofl]

「いいね」「お気に入り」の対象はこれまでどおりユーザーで変わりないか？

[ofl]

https://github.com/Araki/CouplingServer/commit/c75daf4d4480ca646bb8501f9ff90d766e3f4afb でapn_on_railsの記述を消しているが、それは使わないということか？

関連するテーブルは削除しても良いのか？ apnを送るために必要なデバイストークンはユーザーテーブルに保存するのか？ デバイストークンはいつ保存されるのか？

[ofl]

普段仕事でiOSアプリの開発をしているのですが、FB認証はすべてクライアント側で済ませてしまっているので、 今回はその方法で行きたいです。

ではaccess_tokenはユーザーテーブルに保存せずに、sessionのcreate時には必ずFBにアクセスして、そこで返してもらったfacebook_idを手がかりにユーザーを特定するということではどうでしょうか？

[ofl]

userが作成/編集できるグループの数は１つだけか。

[uniom]

「いいね」「お気に入り」の対象はこれまでどおりユーザーで変わりないか？ 変わらないです。

でapn_on_railsの記述を消しているが、それは使わないということか？

違うライブラリを使おうと思ったからです。 デバイストークンはユーザテーブルに保存してください。 保存のタイミングはアカウント作成時です。

ではaccess_tokenはユーザーテーブルに保存せずに、sessionのcreate時には必ずFBにアクセスして、そこで返し> てもらったfacebook_idを手がかりにユーザーを特定するということではどうでしょうか？

はい、sessionのcreate時にFBにアクセスします。そこで得たFB idとアクセストークンをサーバに投げて保存します。 sessionは期限を設定しないので、ユーザがログアウトしない限りアプリ側とサーバサイドで通信できます。 ユーザがログアウトしたらsessionを破棄し、またFBの認証をし、session createを行います。 アクセストークンが切れたらsessionを破棄し再度、FBの認証をし、session createを行います。

アクセストークンはFBの情報を取得するのに必要になります。

こんな感じでよろしいでしょうか？忌憚のない意見、ありあとうございます。

userが作成/編集できるグループの数は１つだけか。

現在の仕様ではひとつだけです。

[ofl]

グループに男女が混合されることはあり得るのか？ ない場合はグループに男女の項目を設けて良いか?。

[uniom]

グループに男女が混合されることはないです。 すいません、あとＦＢのアクセストークンの期間を最長の60日間で設定してください。

[ofl]

あとＦＢのアクセストークンの期間を最長の60日間で設定してください

これについてはサーバー側というよりアクセストークンを取得するときにリクエストの仕方を設定しなければならないようですがどうでしょう。 http://fb.dev-plus.jp/column2/column2_20/

[ofl]

APNについて

通知されるタイミング

1. メッセージが届いた
2. いいねされた

3. 運営からの通知?

   メッセージの未読数はをバッジで知らせるべきか？ メッセージ以外の通知の場合バッジはどうするべきか？

[uniom]

ＦＢのアクセストークンの期間の件はクライアント側の話でした。 申し訳ございません。

通知されるタイミングの件について はい、そのタイミングでＯＫです。

メッセージの未読数+いいねされた未読数数+運営からの未読通知の合計数 がアプリのバッジとして表示される方向でいきたいです。