![見出し画像](https://assets.st-note.com/production/uploads/images/11481611/rectangle_large_type_2_890b1a04014e59d7c18fccbbeb29b4b0.png?width=1200)
ユーザー管理方法検討 (ゲームみたいなニュースサービスを作ってみる 8)
前回のふりかえり
どうも、gokeです。
前回は見た目の部分を試しに作ってみました。
これは「全体をふわっと作ってみる」をやってみた状態です。
作りながら「ちゃんとやるにはここはこうすべき」という課題が見えてきたのでちょっと整理してみます。
ちゃんとやるのに必要なことの整理
前回のプログラムでは
1. ニュースを取得する
2. ニュースをそれっぽく表示する
という2つのステップを同時に行なっていました。
実際にゲームっぽくしていくには
1. ニュースは事前に集めておく
2. 集めたニュースをユーザーによって出し分けする
というステップが必要になりそうです。
そのため、
1. ニュースを集めておくプログラム
2. ニュースを表示するプログラム
の2つに分けて作っていくことにしました。
ニュースを集めておくプログラム
ユーザーがアクセスしなくても裏っかわでGoogleのAPIを叩いてニュースをDBに集めておいてくれるプログラムです。
前回のプログラムから必要な部分を切り出してこんな感じで作りました。
一部、セキュリティに関わる部分は伏せてます。
<?php
$news_arr = get_news(50);
foreach($news_arr as $news){
$body_text = $news['body'];
$datetime_updated = $news['updated'];
//ここでDBに保存する処理。記載は省略します。
}
function get_news($max_num = 50){
$api_url = 'https://news.google.com/news/atom/headlines/section/topic/NATION.ja_jp/%E5%9B%BD%E5%86%85?ned=jp&hl=ja&gl=JP';
//---- APIにアクセス、結果をsimplexmlに格納
$contents = file_get_contents($api_url);
$xml = simplexml_load_string($contents);
//記事エントリを取り出す
$data = $xml->entry;
//記事のタイトルを取り出して配列に格納
for ($i = 0; $i < count($data); $i++) {
$list[$i]['body'] = mb_convert_encoding($data[$i]->title ,"UTF-8", "auto");
$list[$i]['updated'] = $data[$i]->updated;
}
//$max_num以上の記事数の場合は切り捨て
if(count($list)>$max_num){
for ($i = 0; $i < $max_num; $i++){
$list_gn[$i] = $list{$i};
$i++;
}
}else{
$list_gn = $list;
}
//配列を出力
return $list_gn;
}
?>
このPHPをサーバーサイドで動かすとDBに記事が保存されていきます。
DBの設計の詳細は省略しますが
・記事のID
・記事のカテゴリ
・記事の内容
・記事の更新日時
を保存するテーブルを作って記事を保存していきます。
とあるユーザーがはじめてページを訪れたときには「更新日時」を確認してもっとも最近の記事を表示する、というような処理です。
ニュースを表示するプログラム
とりあえず記事は自由自在に手に入れることができるとして、
それらをどうやって表示するかをもう少し詳細に定義します。
1. 表示しようとしているのが誰なのかを認識
2. そのユーザーがまだ見ていない記事を表示
3. 見た記事には印をつける
4. ユーザーになんらか経験値をつける
ここまで考えると(はじめから薄々感じていてはいますが)アプリにしたほうがいいような気がします。今後アプリにすることも意識して作っていきましょう。
コラム:Webサービスのアプリ化
アプリ化することを意識、とはどういうことでしょうか?
Webサービスをアプリにするもっとも簡単な方法は、そのままWebページをアプリに埋め込むという方法です。
厳密には「Webサービスをアプリに埋め込んだだけのアプリは認めない」とappleが言っているのでアプリ固有の体験を追加しなければいけなかったりはします(プッシュ通知など)。
ともあれ「ウェブでもアプリでも使えるサービス」にするときには「クロスプラットフォーム」を意識する必要があります。
例えばブラウザに何かを保存する仕様にすると、アプリ(違うブラウザ)で開く場合にその設定が引き継げないという問題があります。これを回避するためには例えば「データはDBに保存して、メールアドレスによるログインでユーザーを識別する」のような処理が必要になります。
とはいえ、ミニマムで作ることを考えるとあんまりゴリゴリにやるのは得策ではありませんので可能な限り手間は省きたいです。
具体的な作戦
アプリ化を意識するとサーバーサイドにユーザー情報を保存しておくべきなのですが、ミニマムで作ることを考えると一旦この変は忘れることにします。
何が起こるかというと「ブラウザで利用してくれていたユーザーがアプリが出たからアプリで使おう」と乗り換えたときにブラウザでの設定がアプリに引き継げない。
ということです。
ですがそもそもそこまでヘビーに利用してくれるユーザーがわんさかいる想定で作らないほうがいいのでここは一旦飛ばします。(仮にそういう状況になったとしても、あとでいくらでもリカバリーは可能です)
ということで、ユーザー=ブラウザとすることにしました。
元々の想定ではユーザーはパソコンでは使わない、スマホで使うという想定なのでこのサービスはいつでも同じブラウザで開かれるだろうという仮説です。
具体的にはユーザーがアクセスしてきたらブラウザにcookieを保存します。
そのcookieをDBにも保存してユーザーの識別とします。
そのcookieを持っているユーザーにはそのユーザー用のコンテンツを表示して経験値的なものをDBに保存していくという感じです。
ユーザーのDBはこんな感じにしようと思います。
・ブラウザに保存されているcookie = ユーザーID
・ユーザーが興味があるカテゴリ
・登録日
・最後に確認した記事のID
これらは全部ブラウザに保存してもいいのですが、
それだと簡単に改ざんされてしまう可能性があるのでサーバーサイドで処理することにします。(サービスの内容的に改ざんされても問題ないのですが)
ちょっと長くなりそうなので次回は一気に作っていこうと思います。
この記事が気に入ったらサポートをしてみませんか?