最近は、「統計メモ帳」のサイトのモバイル対応をしています。当初は、ユーザー エージェントによる振り分けで対応しようと思っていたのですが、作業中にレスポンシブ Web でもできるのではないかと言うことに気づいて、テストしたら問題がないようなので、Bootstrap を使って、レスポンシブ Web でモバイル対応を進めています。

統計メモ帳だけで、テンプレートが60ページあるので、もし振り分けにしていたら、テンプレートが120ページになったということで、後の管理を考えると、できるだけレスポンシブ Web で対応した方がいいと思っています。

自分が管理で一番大変だと思っているのは、テンプレートの修正や CSS の管理です。今回もまだ50ページ以上のテンプレートの修正作業が残っていて、かなり大変な作業です。プログラムの部分は、Visual Studio が結構優秀なのと、ソースは Git に入れてあるので意外とスムーズにいっています。

CSS には、デザイン能力も必要ないし、変数も関数もないのでプログラムの能力も必要ないしで、3ヶ月も勉強すれば誰でもできると思われていて、webコーダーは最底辺の職種になっています。そのためかどうかは分かりませんが、CSS の管理はあまり考えられていなかったと思います。しかし、CSS には、名前空間がないので、そのクラスがどこで使われているかを調べるのに手間がかかります。だから本当は命名規則をきちんとしておくことが非常に重要です。

Bootstrap を実際に使ってみて感じたことは、普段に使うコンポーネントを一通り作ってくれて、そのコンポーネントに名前をつけてくれたということが偉大だと思います。CSS のクラスの名前にデファクトスタンダードを作ったということは大いに評価すべきで、以後の管理は少しは楽になると思います。

Bootstrapは、所詮はコンポーネントの集まりで、利用する人の能力によってどうにでもなります。Bootstrap は、カスタマイズをするのが難しく Bootstrap 臭がするからダメだという人は、CSS をカスタマイズする能力がない人です。自分のようにデザイン能力がない人間が使えばしょぼいデザインのものしかできません。

レスポンシブ Web では、以前は Google アドセンスを入れるのが難しかったのですが、レスポンシブ広告ユニットが使用できるようになっているので、それほど問題なく導入することができました。

「統計メモ帳」のサイトが、1月は月間で6万PVを超えることができました。11月から約1万PVの増加です。

それは良かったのですが、1月の末にウェブマスターツールで「http://ecitizen.jp/ でモバイル ユーザビリティ上の問題が検出されました」というメッセージがきました。それで、ウェブマスターツールで検索クエリを見てみると、下の図のようにモバイルからの検索が半分を占めるようになっていました。

統計メモ帳では、セッションの割合ではモバイルからのアクセスは29%しかなかったので、モバイルからのアクセスを考慮していなかったのですが、モバイルからのアクセスを見逃していたようです。

それで、統計メモ帳でもモバイル対応の作業を始めました。今までは、モバイル対応に jQuery Mobile を使っていたのですが、今回は、Bootstrap を使おうと思っています。統計メモ帳では、jQuery Mobile のモバイル的なデザインはあまり必要ではなく、グラフと表がうまく表示できればいので、Bootstrap の方が軽くできると思っています。

また、Bootstrap を使うといっても、単純にレスポンシブにするというのではなくて、データ量をPC用よりかなり減らさないといけないので、ユーザー エージェントによる振り分けもしようと思っています。

Xamarin.Forms は、iPhone と Android の両方のアプリが一つのソースで作れるという魅力的な開発ツールです。それで、アプリを作ろうと思って試してみました。

自分にとっての一番の問題点は、Xamarin.Forms の画面表示が意外と遅いことです。Grid と Label を使って、カレンダー1年分の表示をする下の図のようなプログラムを作って、Nexus 5 で表示させてみたら、ボタンを押してから表示されるまでに3秒以上かかりました。iPhone 5s だとそれよりはかなり早くなりますが、それでも1秒以上かかっている感じです。

今回のカレンダーだと日付だけですが、実際のアプリにするためには、さらに色を変えたりアイコンを追加したりする処理が必要なので、日付だけでこれだけ時間が掛かってしまうと厳しいと思います。

ところが、WebView を使って HTML の Table でカレンダーを作ってみると、今度はほとんど遅延せずに動作します。Grid+Label より WebView の方が遙かに早いようで、Android では特にその傾向が強いように見えます。

なお、プログラムは、GitHub の方に SpeedTest として公開していますので、興味のある方は実際に試して見てください。

Xamarin.Forms の Grid+Label を使った画面表示が遅い原因を調べてみると、stackoverflowに Why is Xamarin.Forms so slow when displaying a few labels (especially on Android)? という質問があって、どうも Label の表示が遅いようです。

stackoverflow 方では、40個のLabelで、表示に 100ms 以上かかり、Android の場合は約300ms かかるとなっています。今回のカレンダーの場合は、約460個のLabelをつかっていて stackoverflow の約10倍なので話としては一致しています。

stackoverflow には、改善策も書いてあます。Xamarin.Forms で処理を速くする方法としては、UI にはできるだけネイティブを使えばいいようです。

自分の場合は、Web の方を主力にしたいので、UI にネイティブを使うのは時間的にはかなり厳しいです。それで、当面は WebView を使ったハイブリッドアプリを検討していこうと思っています。そして、Xamarin.Forms の処理が早くなることに期待したいと思います。

今年初めてのブログなので、今年の抱負とかを書こうと思ったのですが、昨年の後半はスマートフォン・アプリを作ろうと思っていろいろ検討してきたので、そのメモをしておきます。

Cordova

PhoneGap といった方が有名ですが、HTML+Javascriptの技術を使って、iPhone/Androidのネイティブアプリケーションの開発が可能になります。以前に使ってみたときには、デバッグがしづらいと思っていたのですが、Microsoft から Visual Studio Tools for Apache Cordova が公開されて、開発がすごく楽になっています。Webアプリにプッシュ通知だけをつけたい場合のように、少しだけネイティブの機能を追加したい場合には適していると思います。

Visual Studio Tools for Apache Cordova は、VS の　Express ではインストールできません。しかし、昨年の11月に個人や5人以下の企業向けに Visual Studio Community 2013 が公開され無料で利用できるので一度試して見るといいと思います。

Xamarin

Xamarin は、C#やF#といった.NET系の技術を用いてiPhone/Android のアプリ開発を可能にするクロスプラットフォームツールです。Xamarin 自体は、各プラットフォームの API の薄いラッパーで、アプリのUIを作る場合には各プラットフォームのことを知っていないと作れないのでかなり苦労しています。Model の部分は共通で使えるので、アプリ側で多くのロジックが必要な場合には適していると思います。

昨年の5月に公開された Xamarin.Forms は、UI 部分も共通化しようというもので魅力のある製品ですが、実際に使ってみるとまだまだベータ状況という感じがしています。製品として早く成熟して欲しいと思っています。

Swift

iOS のソフトらしいヌルヌル動作するアプリを作りたければ、Apple 純正の Swift を使うのがいいようです。C# を知っていれば Objective-C よりはモダンになっているのでかなり取っつきやすいと思います。Apple が Swift を公開したことに対して、また独自の言語を開発してという非難をする人がいますが、iOS の特徴を生かすための言語が必要というのはやむを得ないことだと思います。

ベストな開発環境を確認するのはその環境を熟知していないと無理なので、結局は自分の能力や作りたいアプリの特徴に応じてだいたいのところで選択するしかないというのが実態のようです。今年は、Webアプリのスマートフォンアプリ版を作りたいと思っていますが、最初は、Xamarin から始めようと思っています。最終的にはどうなるかはわかりませんが、ぜひ公開できるようにしたいと思っています。

Xamarin から始めようと思っているのは、現在は ASP.NET MVC で Web サイトを作っているためです。Cordova を使うためには、Razor が使えなくなって、HTML + CSS + JavaScript だけで画面を作る必要があります。そういう制作方法に変更してもいいとは思うのですが、Xamarin であれば、WebView で Razor も使えるので Web アプリと iOS/Android アプリの共通部分を増やせるのではないかと思っています。

「Rubyで経済指標自動巡回プログラム作成しました。 - 人生、徒然なるままに。」というブログをみて、このブログの筆者は、.Net や Java を使えるのに、なぜ、新たに勉強してまで Ruby を使ったのかということに興味があったので、同じようなものを C# で作り、GitHubで公開(https://github.com/awoni/GetMarketCalendar)してみました。

今回のプログラムでは、データの取得には HTTPClient を使って直接 Url をたたいて該当ページのHTMLを取得しています。一方で、Ruby の方では、「フレームワークとしてCapybara、レンダリングドライバー・javascriptドライバーとして poltergeist, PhantomJS」を選択しているそうで、プログラムでボタンをクリックして取得したデータをもとに解析しています。今回のデータの場合は、HTML のみで必要なデータが取得できましたが、JavaScriptを使ったインターラクティブな Webページが増加しているので、Javascriptが動作する環境でブラウジングしてデータを取得する必要がある場合も多くなってくると思います。

Html のパースには、Html Agility Pack を使っています。LINQ を使って記述していますが、意外と簡単にパースすることができます。

データの保存については、データベースではなくて、そのままで API として使いやすい Json で保存するようにしてみました。 Newtonsoft の Json.NET でシリアライズしています。設定ファイルについても、Json にしてみました。

その他に NuGetのパッケージとしては、NLog を使っています。Html のパースルーティンでは、どの程度までエラー処理をすべきかが問題になりますが、画面の変更に対応しようと思うとプログラムがどんどん複雑になってくるので、自分としては、プログラムは余り複雑にせずに、画面の変更によるエラーに早く気づくようにした方がいいのではないかと思っています。NLog をログのメール送信にも対応しているので、こういう点に関しては便利だと思います。ただ、今回公開しているプログラムでは、時間の関係でとりあえずの状況なのですが、実際にアプリケーションを作る場合は、ログをどうとるかは結構重要だと思っています。

C#で実際に同じようなプログラムを書いてみて、実務的にいえば C# は十分優秀だと思います。LINQ や 今回は使っていませんが await async による非同期処理は便利です。ではどこが Ruby より劣るのかということを考えてみると、ブログの筆者のいう「rubyは面白いらしい」ということに尽きるのではないかと思います。それに、日本では情報量の差も大きいと思っています。

C#がどうすれば面白くなるかはよくわかりませんが、ブログの作者が巡回プログラムを作る動機になった「Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例」という本は、amazon.co.jp の「ソフトウェア・開発言語」で7位にランクされています。クローラーは意外と興味がある人が多いようなので、自分もクローラーであれば結構ネタはあるので、時々ブログに書いてみようと思っています。