ボクココ

熱海で開発するブログ

初めての iPhone アプリリリース

iOS

ついに iPhone アプリをリリースした。既に Android アプリで2万ダウンロード突破中のアプリの iPhone版だ。 2つのプラットフォーム対応ということで、特設サイトも作った。このトップ画像が個人的に気に入っている。w 今のところ日本語、英語、フランス語、ドイツ語に対応。国別のiOSのシェアの高い国に絞って国際化した。

Unleashed Revolution

Swift の勉強を本格的に始めたのが11月の上旬で、そこから3週間でリリースまでこぎつけた感じ。Swiftは本当に素晴らしい。Android 出身の自分には以下の本がとても役に立った。

Migrating to Swift from Android

Migrating to Swift from Android

これで既存のObjective-C のコードでも Swift から呼び出せるようになって、外部ライブラリも使えるようになった。あとは細かいSDKの使い方を作っていく過程で学んでいった感じ。ちなみに今回は以下のライブラリを利用した。

platform :ios, "8.0"
pod 'FontAwesomeKit/IonIcons'
pod 'MRProgress'
pod 'MMPickerView', '~> 0.0.1'
pod 'MessageBarManager'

それに加えて、 Alamofire っていうHTTP通信ライブラリ。これはSwiftのライブラリだからCocoaPod には書けなかった。

初めてで一番苦労したのは、リリース周り。 iOS アプリのリリースの準備って本当に複雑で、かなり意味不明だった。 まぁ一回がんばってなんとか動かせればそのあとは同じ作業だからなんとかなるかもしれないが、あれは Apple は改善すべきだと思う。 あと最終ビルドの所の意味不明なエラーで半日は費やしたな。そこらへん Android にはない辛さだった。

まぁともかく、一般的に iPhone アプリの方が多くダウンロードされるって言われているので、今後このアプリがどのように成長していくか、楽しみ!


っと、このアプリは練習用の位置づけ。これからはコネクシィのiPhone アプリを本気で作っていく! ただいま絶賛画面設計中。

電子書籍による最先端技術学習のススメ

技術を学ぶとき、皆さんはどのように学習しているだろうか?

本屋へ行っていろいろ物色して選んだり、他人から本を借りたり、Amazonで買ったり。最近はオンラインで学習できるリソースも増えてきている。

ただそれらはもうそれなりに普及した後の技術であり、割と基本的なことしか書かれていないことが多い。大抵の「良書」は、海外から翻訳されたものだったりする。やはり技術の中心は英語圏の国だ。

そうなると、日本語で書かれた本は、基本的に英語の本が出版され、その本を翻訳者が評価し、翻訳されて校正されないと日本語の本は出版されない。このタイムラグは半年くらいあったりする。

技術の世界で半年って言ったらなかなかの遅さだ。やはり技術者たるもの、最先端をいきたいところ。

ではどうすればいいか。

電子書籍の登場

電子書籍のおかげで技術者が新しい技術を学ぶ際の一つの革新が生まれた。今までは海外の本をAmazonで注文すると3週間くらいかかってしまっていた。その頃にはもう読むモチベーションがなくなっていたりするものだ。

電子書籍なら最先端の本をいつでもダウンロードできる。また最近の技術書なら大抵電子化もされているので、欲しい本が電子化されていないといったパターンも少ない。

英語で読むのが辛いってのはあると思うけど、英語の技術本を読むとわかるけど、基本的な単語しか使ってないから本当に読みやすい。ニュースとかと比べてはいけない。てかそもそも技術者で英語が全く読めないってのはかなり致命的だ。問題が起きた時にStack Overflow とかそれなりに読めないと問題解決にかなり時間がかかることになる。てことで諦めて英語はちゃんと勉強したほうがいいと思う。

しかも電子書籍なら通常の本より安く買える。ちょっと宣伝っぽくなってしまうが、Kobo 書籍検索はそんな技術者のために作られたサイトだ。通常より2〜3割引で電子書籍を買うことができる。

Kobo 書籍検索

あなたの気になる技術を発売の新しい順でソートしてみてほしい。日本ではまだ発売されていない興味の惹くタイトルを見つけることができるだろう。

iOS と Android アプリの違いを正しく理解しよう

今回は割りと基本的なことで、エンジニアに限らずデザイナーやプロデューサーも知るべき内容だ。

というのも、仕事でスマホアプリ開発をしていると、iPhoneしか持っていなくてAndroid の知識がろくにないプロデューサーやデザイナーと組んで、Android開発者はiOSのようなUIを作らなければならなくなった、というケースがかなりあるからだ。

そういうのをなくすためにも、各プラットフォームでのデザインガイドラインは必ずチーム間で共有すべき点だ。それをしないと何がいけないのか。

それは、ユーザーエクスペリエンスを損なうからとかっこよく言えばそうなる。つまり、Androidユーザーで他のアプリでは当たり前だったデザインが、そのiOSっぽいandroidアプリを利用すると違和感を感じてしまうという点にある。Androidユーザーで下タブのあるアプリは普通はない。だからAndroidしか利用しないユーザーはそのアプリに対して違和感を感じるだろう。下タブがあった時点でそれはユーザーエクスペリエンスを損なっていると言えるのだ。

参考資料

iOSAndroid もそれぞれちゃんとドキュメントを作って公開している。

iOSヒューマンインターフェイスガイドライン: UI設計の基本事項

Material Design | Android Developers

Android の Material Design はまだ新しいので日本語ドキュメントはない感じ。あと先日 Google はこんなのも出版した。

The Secrets to App Success on Google Play - Google Play の書籍

終わりに

これを一回読んでおくと読んでおかないとで、デベロッパーとしての自信もだいぶ変わってくると思う。アプリ開発してますと言って、誰かから「デザインガイドライン読んだ?」と聞かれた時にドキッとしないようになろう。

もちろんそれだけに限らず、無意識に感じてた各アプリの共通項がちゃんと明文化されているので、頭の整理として読むことをお勧めする。かく言う自分も今ちゃんと読んでいる段階だ。

Rails アプリ開発中のDB内容確認における注意点

これは原因がわかりにくいのでメモ。

問題概要

DBの値を更新したはずなのに、 rails console でその変更が確認できない

問題詳細

rails console はご存知 irb で 各 Rails のモデル操作のテストができる優れもの。よく使う方は多いと思う。今回は別ウィンドウでこの rails consoleを立ち上げ、別ウィンドウで rails serverを立ち上げていた。

rails server 側でDBの中身を書き換えた後、 rails console から User.all.to_a とかで出力しても、買えたはずのデータが変わっていないという事態に陥った。

原因

これは Rails が裏で rails console のクエリの結果をキャッシュしているようだ。

rails server 側でDBの中身を書き換えたら、 rails console は一旦再起動してアクセスしないと変化が確認できないっぽい。

これは原因の特定がとてもわかりづらく、結果として無駄な時間を消費する羽目になるので、今後 railsアプリ開発をする方は注意していただきたい。

Google Mobile App Developer Panel に参加してみた

今日こんなメールが届いた。

f:id:cevid_cpp:20141120003359p:plain

読んでみると、どうやらAndroid デベロッパー同士のコミュニティーの場のようだ。何かしら有益な情報がメールでくるかもしれないと思い、登録してみた。

これは Google Play に登録している人限定っぽいのでURLは乗っけられないけど、20$払ってGoogle Play デベロッパーになれば誰でも入れる気がする。

実に長いアンケート項目に答えたら、こんな感じのページに入った。

f:id:cevid_cpp:20141120003653p:plain

このコミュニティの一番いいところは、Google の中の人とより近くでコンタクトが取れるということだろう。今まではGoogle に問い合わせたくてもなかなか対応してくれないケースが多かったし、日本のフォーラムで問い合わせても、「開発チームに連絡します」ってだけで具体的な進展があったことはあまりなかった。

もちろん英語必須ではあるがこのようにAndroidデベロッパー向けの公開コミュニティがあることで、今後のAndroid 開発がよりよくなることを期待している。何かAndroid開発での問題が解決できないときはここを利用してみようと思う。

Express + ejsで i18n

Node.js ネタ。 Heroku でシンプルなんだけどちょっと動的なサーバサイドを持つwebサイトを作りたいといったときに Node.js は便利。 こういう時 PHP とか Ruby なら Sinatra とか選択肢があると思うけど、Node.js のアクセスを捌く力を知ってからはできるだけシンプルなやつはNode.js を使うようにしてる。 Heroku に上げるのもめちゃめちゃ簡単だしな。

ということで 今回なんで動的にしたかったのかというと、国際化対応のサイトを作りたかったからだ。ユーザーのブラウザの言語に応じて同一URLで内容を書き換えるようにした。

他のブログ漁ってみると、express のバージョンが低いやつで i18n してたり、 jade っていう独自のHamlみたいなHTMLテンプレートエンジン使ってたりと自分に合うのがなくて自分でちょっと頑張った。

Express プロジェクトの作成

もう npm とか Express とか Node.js とか入れてある前提

express -e  myapp
cd myapp
npm install

コード修正

package.json

{
  "name": "application-name",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "node app.js"
  },
  "dependencies": {
    "express": "3.4.8",
    "i18n": "*",
    "ejs": "*"
  }
}

app.js

var express = require('express');
var routes = require('./routes');
var http = require('http');
var path = require('path');
var i18n = require('i18n');

var app = express();
i18n.configure({
  locales: ['en', 'ja', 'fr', 'de', 'ko'] ,
  directory: __dirname + '/locales',
  cookie: 'mycokie'
});
// all environments
app.set('port', process.env.PORT || 3000);
app.set('views', path.join(__dirname, 'views'));
app.set('view engine', 'ejs');
app.use(express.favicon(express.favicon(__dirname + '/public/favicon.ico')));
app.use(express.urlencoded());
app.use(express.methodOverride());
app.use(i18n.init);
app.use(app.router);
app.use(express.static(path.join(__dirname, 'public')));

app.get('/', routes.index);
http.createServer(app).listen(app.get('port'), function(){
  console.log('Express server listening on port ' + app.get('port'));
});

そんで locales/ja.js とかを作って、以下のようなjsonを作る。

{
  "locale": "ja",
  "title": "マイアプリ"
}

views/index.ejs で以下のように使える

<%= __('title') %>

この書き方が割と自分が慣れ親しんでいるので、ejs を選んだ。HTMLテンプレートエンジンといえばこの書き方だよな、って個人的に思っている。w

所感

これだけで 国際化対応のウェブサイトを作れちゃうんだから、何かWebサイトを作るなら世界を見据えていきたいところ。そっちのほうが夢があるじゃない!

てな感じで今回は 以下のページを作りました。 iPhone アプリでたら随時報告します。

Unleashed Revolution

このサイトは日本語、英語、韓国語、フランス語、ドイツ語に対応しています。Google 翻訳とかじゃなくて、以下のようなやり方で翻訳しました。

アプリを無料で他言語対応させる方法 - ボクココ

Swift で xib でレイアウトされたモーダルを出す

iOS

iOSのモーダルは Android でいうActivity#startActivityForResult みたいなやつ。一旦別画面で何かやってもらって、その結果を呼び出し元で取得するようなケースで使える。

ネットで調べてもサンプルがObejctive-C ばかりだったので、Swift での実装方法をまとめてみる。

ViewController の作成

NewFile から Cocoa Touch Class を指定し、親がUIViewController, Also create XIB file にチェックを入れる。

f:id:cevid_cpp:20141115135908p:plain

ModalViewController のセットアップ

作成したModalViewController は以下のような感じになる。

protocol ModalViewControllerDelegate {
    func modalDidFinished(text: String)
}

class ModalViewController: UIViewController {
    
    var delegate: ModalViewControllerDelegate! = nil
    
    override func viewDidLoad() {
        super.viewDidLoad()
    }

    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
        // Dispose of any resources that can be recreated.
    }

    @IBAction func onCloseed(sender: AnyObject) {
        self.dismissViewControllerAnimated(true, completion: nil)
        self.delegate.modalDidFinished("closed")
    }
}

ここで protocol で ModalViewControllerDelegate を定義しているのは、これを呼び出し元ViewController のコールバックオブジェクトとして登録するためだ。 このコールバックオブジェクトを iOSの世界では delegate と呼ぶらしい。

今回はこのプロトコルを実装した 呼び出し元ViewController を delegate として登録し、終了時に modalDidFinished を呼び出して値を呼び出し元に返している。

呼び出し元 ViewController

モーダル呼び出し元の下準備をする。

class ViewController : UIViewController, ModalViewControllerDelegate {
   
    let modal = ModalViewController(nibName: "ModalViewController", bundle: nil)
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        self.modal.delegate = self
    }

    @IBAction func onModalOpen(sender: AnyObject) {
        self.presentViewController(modal, animated: true, completion: nil)
    }

    func modalDidFinished(text: String) {
        println(text)
    }
}

self(ModalViewControllerDelegateオブジェクト) を modal の delegate に代入する。

ModalViewControllerDelegatemodalDidFinishedを実装する。ここが Modal呼び出し後に呼ばれるコールバックだ。

ModalViewController 初期化時に nibName を指定しないと xib ファイルで作った View が描画されずに真っ黒になるので注意。

終わりに

両者の間で色々と実装しなければいけない所が多々あって最初はわかりにくいかもしれないが、これは Android アプリ開発でも同じようなことをよくやるケースが多いので、マスターしておきたいところ。