Android版の開発始めました

久しぶりの投稿

最近、iOS版でリリースしたアプリのAndroid版の開発に着手しています。

Androidは2.x系主流のころ以来です。

いまのところの感想としては、、、


Androidまじホビロン＾＾


まず、IDEとしてAndroid Studioを選択しました。
チームのみんな新しいもの好きですし、すんなり決まりました。

Android Studio自体はなかなか快適。

最近eclipseを触っていないので正確ではないですが、Android Studio > eclipseな感じ。


それとAndroid4.x以上対応にしました。


これは、現段階で噂レベルですが、Googleが公式に4.x系以上しかサポートしないという暴挙に出てくれたのも追い風になってます。


ここまではいいです。


もくもくと開発していて、随所で思うこと、

UI開発がまじホビロン＾＾

随所ではまり、はまる根本的な原因が端末サイズがバラバラであることを感じています。

Activity Fragment View

役割は全然違いますが、どれもViewに結びつく可能性があることは同じです。
ですが、Viewへのアプローチの仕方が違いすぎてはまることが度々あります。



比べるとiOSのUIは作りやすかったなぁ。。。

【iOS8 対応】editActionsForRowAtIndexPathで標準メーラーのようなedit modeを実現するために

iPhoneの標準メーラーに搭載されているUIで
各cellをスワイプすると「削除」とかボタンがにゅるっと出てくるのありますよね？

あれがiOS8からuitableviewのdelegateメソッドとして使えるようになりました。

tableView:editActionsForRowAtIndexPath

基本的な使い方は、ブログで多く取り上げられていますが、

-(NSArray*)tableView:(UITableView*)tableView editActionsForRowAtIndexPath:(NSIndexPath*)indexPath {

UITableViewRowAction *deleteAction
= [UITableViewRowAction rowActionWithStyle:UITableViewRowActionStyleDestructive
title:@"delete"
handler:^(UITableViewRowAction *action,NSIndexPath *indexPath) {

// ﾎﾞﾀﾝ押したときの処理

}

// ﾎﾞﾀﾝの数はここで決まる
return @[deleteAction];

}

// これないとダメ
-(void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle
forRowAtIndexPath:(NSIndexpath *)indexPath
{
 
}

以上が基本的な実装です。


が、これには欠点があります。
iOS7です。

現時点ではiOS7にも対応させなさいよ、っていうオーダーが多いと思います。

そこで対応方法をちょっぴりはまったので記載しておきます。


まず、iOS7でもこの状態でボタンが出てきます（なぜ？ｗ）。

ただ、ボタンを押してもUITableViewRowActionのブロック内にきません。

どこいった？

ここで活きてくるのが、//これないとだめ　って書いた
tableView:commitEditingStyle:forRowAtIndexPath
ここです。

これは本来、uitableviewのedit modeをYESにしたときに通るところなんですが、
今回の実装方法でボタンを押したときにも通ります。

ここはiOS8では通りません。


なので、ブロック内と同じアクションを書いておけばOKです。



さらに、特定のセルだけこのスワイプしてボタンが出るようにする場合は、
iOS7 8どちらも対応させるには、editActionsForRowAtIndexPathで
セルの判別しただけではダメで、

tableView:canEditRowAtIndexPath
でセル判別しないといけません。


tableView:editActionsForRowAtIndexPath
これがなんでiOS7で動くかなぞです。。。

ぞっとした一日(Transfer AppとKeyChain)

無事にアプリをリリースできたのですが、
初日に諸事情によりアプリを別のアカウントに移さないといけないことになりました。

調べてみたら、Transfer AppというiTunes Connectにそなわった機能で、
お手軽にアプリのアカウントを移せるとのこと。

いやーよかったよかった。。。





数日後、アプリのバグ改修等でアップデートのため、
最終チェックをTest Flight。

あれ？

チュートリアルから始まったぞ？

？？？


いろいろ調べた結果、ユーザーを特定するkeyが消えてます。


？？？


ここからさらに調べた結果、Transfer Appすると
Team IDが変わり、Team IDが変わると、アプリのAppIDPrefixが変わり、
KeyChainを使用しているともろもろ取れないぞ、と。

ほぉほぉ。

それならKeyChainのkeyに無理やり前回のAppIDPrefixぶちこめばいいじゃん。


・・・


それはセキュリティの問題でできませ～ん
とぅいまてーん。


絶望。。。


結果、３人がかりで１日試行錯誤し、ウルトラC級のアイデアにより危機回避できました。
ちなみに解決策は、たまたまユーザーユニークの値をUserDefaultに保存していたので、
そちらから逆算しKeyChainを新規AppIDPrefixで保存するという方法。

ちなみにちなみに、めっちゃ調べた結果、
Transfer App後のKeyChainの純粋な復帰は不可能です。
（Appleにも電話しましたｗ）

Facebook Paper

多分に影響を受け、感銘を受けました。
FacebookのUI研究チームが全力で作ったアプリだそうです。

http://blog.brianlovin.com/design-details-paper-by-facebook/

ここにPaper UIのなにがすごいかがまとめられています。


個人的に細かくチェックしてみましたが、
何点か気付かないものもありましたね。

「気付きにくいところに細やかな配慮」

これは元来「日本人」の特性であり美徳であると思います。


それはさておき、エンジニアっぽいことも記述。

https://github.com/facebook/pop

ここにPaperの一部アニメーションの技術があるのですが、
どうやらUIDynamicsを使用してるっぽいですね。




Paper的なの実装してーなー。。。

IFTTTのJazzHandsを使用したチュートリアルサンプル

使ってみました。

所感ですが、

できることできないことを把握して、これを使う前提でチュートリアルを組むなら

申し分ない出来です。

が、さらにリッチに動くものを作るとなると自前で

scrollviewdidscrollを利用して実装したほうがいいかもしれません。

とはいえ、そこまで複雑でないアニメーションであれば、

IFTTTAnimationを実装しても、scrollViewのdelegateをオーバーライドして実装すれば

応用が効きました。

実際やってみたのは、ページ単位で自動発生するアニメーションをios7から実装されたUIKitによる

キーフレームアニメーションで実装し、同じオブジェクトにIFTTTAnimationをセットしても

特に問題なく動きました。

viewのalphaやらx座標やらが結構ややこしくなってくるので、そこらへんをしっかり管理すれば、

簡単なアニメーションと組み合わせて非常に効率よくチュートリアルを作れるんじゃないでしょうか。

１年もしないうちにこのUIが古臭くなる恐怖を覚えつつ・・・。

他社の通信の解析。自分メモもかねて。

チームメンバーにスーパーハカーがいます。

その方の共有なのですが、
他社のアプリがどういう通信を行っているか解析する方法(httpsは不可)
です。

1.ここを参考にMacをアクセスポイント化します。 http://weekly.ascii.jp/elem/000/000/136/136392/ 

２.テスト端末をアクセスポイント化したマックのWiFiにつなげます。 

３.Wiresharkをインストールして起動＆Analyze開始 

https://www.wireshark.org/download.html

すげーｗｗｗ

これで今はやりの白猫解析を行ってもらった結果

- 素材DLとゲーム処理は別サーバーに分けている 

- ゲーム処理はAWSのTokyoリージョンで処理 

- 素材はAkamaiのCDNを利用 

- 暗号化はHTTPSを使わずに独自の暗号化処理を用いている(おそらくSSLによる負荷を気にしての措置) 

- Nginxは使っておらず直接Apacheにアクセスしているっぽい。たぶんPHPなんだろうな。

めっちゃ勉強になります！

Facebookとかが公開IDをどうやってつくってるのか

http://qiita.com/daisy1754/items/98a6e6b17d8161eab081

ここにまとまっているんですが、
プチすごいのがFacebook。

一種の発想の転換ってやつだなって思いました。

一般的なのはInstagramあたりのやり方なんでしょう。
また、さらに簡単なのもあって、
phpならuniqidというメソッドを使ったあれやこれやでしょう。

ただ、せきゅりてー的にどうなんとかあり、各社独自のプログラム組んだりするわけです。

これは裏側に、
リアルタイムに独自のロジックでユニークかつランダムな文字列を生成しなければならない
という事情がありまして、負荷とかできるだけかからないように作らなければならないんです。
（これが意外とやっかいちゃん　理由は最下部で）


そこでFacebookの手法。

リリース前とかに一気に３００万件とかかぶらないID作っておけばいんじゃね？

ユーザーいねーから負荷かかってもいーじゃんね。



その発想はなかったわー。



まさにこれを実装しているんですが、
ぱぱっと作って３００万件レコードつくってみたら
ロングフリーズ発生してそのまま帰ってこなかったのはナイショ。




ちなみに、ユニークかつランダムな文字列を負荷がかからないように作るのが
なぜやっかいちゃんかというと、

123abc　という文字列から3つランダムに取り出して並べる

って作業をします。

すると、 b2a という文字列が出来ます。

これをテーブルAに登録しておきます。

テーブルA：[b2a]

さて、もう一人ユーザーが増えました。

また例の文字列つくらにゃあかんですね。

さっきのロジックで作りましょう。

3ba　という文字列が出来ました。

登録。

テーブルA：[b2a,3ba]

順調、順調。

またまたユーザー登場。

b2a　という文字列出来た。

とうろ・・・　できねー！

かぶってますね。

これ回避するために、かぶってるチェックしなきゃあかんすね。

これは二人目のときからどげんかせんといかんやつだったのですが、
二人目が 3ba　作った時に一回テーブルAにアクセスして
3ba　かぶってない？大丈夫？
って聞かないといけません。

セーフならそのままいっちゃってー
アウトならもっかいランダムで作り直すわ。

これが１００万人目とかなったら。。。
イメージできました？
大変そうです。


細かく言えばいろいろあるんですが、
ざっくりこういうことなんでやっぱFacebookの発想おもろいです。