2013/10/31

[ble]知りたいところだけ調べる (1)

NFCのことばかり書いているが、それだけじゃいかんよなあ、とも思う。
インターネットは苦手なので、近距離通信を強みにしようではないか、というわけで、BLEを調べることにした。
まあ、知りたいところだけ調べるだけなんだけどね。

BLEは、Bluetooth Low Energyの略らしい。
規格としては、Bluetooth4.0(今のところ)。
BLEは、3.0までの規格とは互換性がない。

Bluetooth SMART : BLEのみ対応
Bluetooth SMART READY : BLEにも、それ以前のにも対応
Bluetooth : BLEより前のに対応

うーん、SMARTとSMART READYはいいとして、従来のタイプは「Classic」と呼んだりするらしい。
なら、SMART Classic、とかにすればよいのに、そうはならんらしい。

なんとかならんもんか。。。

2013/10/27

[ios]タブ

Xcode5で、アプリを作るときに「タブのアプリ」を選んでおけば、自動的にタブが表示される。
まだよくわかってないけど、StoryBoardで線をつなげれば(Segue?)、それがそのままタブに反映されるようだ。

でも、減らしたいときもあるではないか。
増やしたいこともあるだろう。
そうなると、StoryBoardだけでは制御できず、ソースファイルをいじくることになる。
検索したら出てくるだろうと思ったのだけど、なんか程よい記事を見つけることができていない。
キーワードが悪いんかねぇ。

ドキュメントを読み返していて気づいたのだが、iOSのタブは「タブ追加」ではなく「タブ設定」なのだ。
addViewではなく、setViewというところだ。
だから、追加とか削除とかではなく、設定したいように設定する、ということらしい。

暫定で、こんなサンプルを作ってみた。
・UITabBarControllerの派生クラスを作る
・StoryBoardでは、その派生クラスを遣うように設定する
・AppDelegateで、UITabBarControllerの派生クラスと、見せたいUIViewControllerのポインタを持つようにする。
・各UIViewControllerのinitWithCoderで、selfをAppDelegateに保存してもらうように書く。
・setViewControllersで、各UIControllerViewを追加するなり削除するなり。

UITabBarControllereの派生クラスを作っているのは、AppDelegateにselfを渡すため。
たぶん、StoryBoardで作っているインスタンスを取得する方法があるんだろうけど、わかってないのよねぇ。
ああかっこうわるい。

2013/10/21

tapee

ふらふらネットを見ていたら、NFC関係の広告があったので開いてみた。

tapee
http://www.hayato.info/tapee/index.html

「たっぴー」と呼ぶようだ。
無料のと有料のとあるみたい。
「NFCマーケティングサービス」と書いてあるので、あまり私と縁がなさそうではあるが、いつかこのブログに集客して広告収入で生きていく道を選ぶ日が来るかもしれない。

とかなんとか理由を付けて、無料のやつを試してみよう。


いくつかやることはあるのだが、大きくは以下だ。

  • tapeeのアカウントを作る(ブラウザ)
  • マーケティングしたいサイトを管理する設定をする(ブラウザ)
  • NFCタグに焼く(Android端末)

 

アカウントを作る

ここから作る。
https://nfc-tapee.appspot.com/registeruser?backurl=login

右上に言語選択があり、Japaneseも出てくる。
私は気付かずに登録したが、登録確認のメールが英語でやって来た。
もしかしたら、Japaneseにしていると日本語のメールが来るのかもしれない。

サイト管理

ログインすると、サイト管理画面が開く。
とりあえず、グループ名を適当につけて「更新」。

下に、「サイト名(*)」とあるので、そこも適当に名前を入れる。
「サイト管理者」は、そのままでいいようだ。
そして右側のボタンを押す。。。と思う。もうやってしまったので、忘れてしまった。

そうすると「タグ管理」という画面に移る。
「新規追加」を押すと、「タグ情報」画面に遷移する。
ここでは、(*)と書いてあるところだけ打ち込めばよいらしい。
「タグ名」は、よくわからんが文字列でよいようだ。
下にある「追加」を押すと、URLを打ち込めるようになる。
後の欄は・・・よくわからんのでデフォルトのままにしておいた。

これで「保存」とすると、「タグ管理」に戻る。
タグ名とURLが出てきたが、タグIDは空欄だ。

タグ焼き

これは、Androidアプリからやる。
https://play.google.com/store/apps/details?id=com.hayato.tm&hl=ja
このリンクでいいのかな・・・。

アプリを立ち上げて、アカウント情報を入力してログインする。
そうすると、グループ名とサイト名が出てくる(たぶん。私は全部「hiro99ma」でやったので、区別がつかん)。
タップすると、今度はタグ名とURLが出てくる。
タグ名をタップすると、タグ情報が出てくる。

image

右側の「Write Tag」をタップすると、青い画面に遷移する。
下の方に、書き込み後にロックするかどうかのチェックがある。
今回はお試しなので、ロックしない。
そして、タグをかざす。手元にあったのをかざすと、書き込んで、また上の画面に戻った。
大切なのは、その画面で下に出ている「Save」をタップすること。
そうしないと、焼いたときに付けたTag IDがサーバに登録されないのだ。


さて、かざしてみよう。
・・・・うん、一瞬tapeeのサイトに飛んで、焼いたURLが開くようだ。
まあ、情報を集めるのだから、そういう手段しかないわな。

本領発揮はこれからだ。
もう一度、ブラウザのサイト管理画面を見よう。
「タグ統計の表示」をクリックすると、こんな画面が出てくる。

image

ぴょこん、と出ているのは、さっき私がタップしたやつだ。
これは日単位だが、このグラフの下には最近60分間の情報も出てくる。

「デバイス統計」ってのもあって、タップした端末の名前・OS・携帯通信会社、の統計情報が出てくる。
まあ、私は携帯電話じゃないからか知らんけど「Google」って出てきたがね。
あとね、Nexus7(Android4.3)でやったのだけど、4.0.xって見られた。
なんじゃろうね?


あとは、tapeeのサイトを見た方がよかろう。

少し気になったことが。
NFCタグとかって、道ばたに勝手に貼ってよいものだろうか?
ほら、電信柱とかだったら規制があるではないか(最近は電柱自体少ないけど)。
まあ普通はよくわからないタグに携帯をかざしたりはしないだろうし、そもそもNFC自体そこまで知名度が高くないだろうから、かざそうと思わないだろうがね。

やっぱり、ポスターがちゃんとあって、そこに「かざしてね」って書いておかないと、やらないだろう。
博多駅とかだと、デジタルサイネージというか、柱に立てかけてある液晶画面に広告が出るようになっている。
あそこにFeliCa Plugみたいなのと連動するようになったしくみをつけて、広告にあわせて変化できるようになっとかんとな。
そしたらそれはそれで、広告の切り替わりタイミングにはどうするか、なんて問題も出てきそうだ。

2013/10/13

[rpi]画面に何か出してみよう (2)

もうちょっと、がんばろう。

$ fbset

mode "1680x1050"
    geometry 1680 1050 1680 1050 16
    timings 0 0 0 0 0 0 0
  
rgba 5/11,6/5,5/0,0/16
endmode

 

この部分。
1ピクセルは16bitなんだけど、その16bitがどういう成分かの説明になっている。
順番に、赤が5bit、緑が6bit、青が5bit、透過は無し。
いわゆる、RGB565、という形式だ。

さて、ここでいつも迷うのが、エンディアンだ。
2byteとなると、データの上位バイトと下位バイトというものが出てくる。
上位バイト→下位バイト、となるか、下位バイト→上位バイト、となるか、だ。

まあ、やってみよう。

#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#define FB      "/dev/fb0"
#define WIDTH   (1680)
#define HEIGHT  (1000)
#define PP      (2)
int main(int argc, const char *argv[])
{
        int fb;
        int loop;
        const data[] = { 0xf8, 0x00 };
        fb  = open(FB, O_RDWR);
        if(fb == -1) {
                perror("cannot open fb.");
                return -1;
        }
        write(fb, data, 2);
        return 0;
}

0xF8、0x00の順に書き込み。
ビットで書けば「 1111 1000 0000 0000」なので、ビッグエンディアンだったら赤になるはず。

・・・青いピクセルが画面左上に出てきた。
ってことは、リトルエンディアンか。

data[]を0x00、0xF8に入れ替えて・・・
?? 画面に何も出ないぞ??
・・・恥ずかしいミスを修正しました。

#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#define FB      "/dev/fb0"
#define WIDTH   (1680)
#define HEIGHT  (1000)
#define PP      (2)
int main(int argc, const char *argv[])
{
        int fb;
        int loop;
        const unsigned char data[] = { 0x00, 0xf8 };
        fb  = open(FB, O_RDWR);
        if(fb == -1) {
                perror("cannot open fb.");
                return -1;
        }
        for(loop = 0; loop < WIDTH; loop++) {
                write(fb, data, 2);
        }
        return 0;
}

そういえば、Cって型無しでもコンパイルエラーにならないんだったな。
intで処理されていたのでだめだったのだ。

それはさておき、実際に使うんだったら、

const unsigned short data = 0xf800;

みたいにするだろうし、RGB565(r, g, b)みたいなマクロを作っておくか、カラー番号を作っておいてテーブルにしてしまうとか、そんな感じになるんじゃなかろうかね。

[rpi]画面に何か出してみよう (1)

Raspbian、というのが私が使っているOSの名称のようだ。
SSHが使えるのが便利だから、これを使っていくことにしよう。

「画面に何か出してみよう」と書いたものの、Raspbianが入ったSDカードを入れると、HDMIから文字が出力されるので、既に何かは出ていると思う。
終了~。

・・・では面白味がないので、自分の意思で何か出してみることにする。


きっと、画面出力用に何かライブラリがあると思うが、ここは基本に返ってフレームバッファを使うことにする。

私の認識では、フレームバッファってのはVRAMみたいなもので、ここにデータを書くとOSというかドライバが上手に画面へ転送してくれるというものだ。

では、試しに。

$ ls /dev/fb*
/dev/fb0

フレームバッファは/dev/fb0みたいだ。
ここに何か転送してみる。
/etc/bash.bashrcというファイルがあるので、これを使おう。

$ cat /etc/bash.bashrc

これをたたくと、コンソールに文字がずらずら出たと思う。
では、これをフレームバッファに出力してみよう。

$ cat /etc/bash.bashrc > /dev/fb0

画面の左上に、ゴミが表示されたんじゃないかと思う。
bash.bashrcの中身がフレームバッファに書き込まれたので、それをドライバが出力してくれたのだ。

bash.bashrcはテキストファイルだけれども、それはテキストかどうかを人間が決めただけであって、コンピュータからすると「データが入ったファイル」に過ぎない。
だから、ゴミっぽいものが表示されるのだ。

じゃあ、画像ファイルならよいかというと、そうでもない。
「/usr/share/lxde/wallpapers/lxde_green.jpg」というファイルがあると思うので、それで試してみよう。

$ cat /usr/share/lxde/wallpapers/lxde_green.jpg > /dev/fb0

ゴミの量が増えたと思う。
画像ファイルも、所詮は取り決めた形式で収められたデータに過ぎず、コンピュータからすると「データが入ったファイル」なのだ。


じゃあどうしたら思い通りに表示できるかというと、コンピュータが期待する形式でデータを出力すればよい。

画面にゴミが出ていると思うので、一度クリアしておこう。

$ clear

では、もう一度bash.bashrcをコンソールに出力してみよう。

$ cat /etc/bash.bashrc

画面に文字がずらずら出たことだろう。
では、今度はフレームバッファの内容をファイルに保存してみよう。

$ cat /dev/fb0 > screenshot.raw
$ ls -l screenshot.raw
-rw-r--r-- 1 pi pi 3548160 Oct 13 01:16 screenshot.raw

うちだとこんな感じになったが、ファイルサイズは人によって違うと思う。
では、もう一度画面をクリア。

$ clear

そして、さっきのファイルをフレームバッファに出力。

$ cat screenshot.raw > /dev/fb0

bash.bashrcの出力などが画面に表示されたんじゃないかと思う。
フレームバッファの出力していた内容をファイルに保存し、それをもう一度出力し直したから当然と言えば当然なのだが、そういうことなのだ。

もうちょっとだけ実践をしておこう。

$ fbset
mode "1680x1050"
    geometry 1680 1050 1680 1050 16
    timings 0 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/16
endmode

これがうちの画面サイズだ。
では、さっきのscreenshot.rawファイルサイズ(3548160byte)を考えていこう。
きっと、画面サイズの定数倍になってるはずだ。

3548160 / 1680 = 2112

・・・ならんやん。
私の予想では、さっきのfbsetの結果に「16」って出てるから、1ピクセルが16bit=2byteなんだろうと思ったのだ。
だから、1680 x 1050 x 2、になるはずだったのだ。
うーん。


調べてみよう。
Raspberry Piのいいところは、セルフコンパイルができるところだな。
調査にはもってこいだ。

fbtest.c

#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#define FB      "/dev/fb0"
#define WIDTH   (1680)
#define PP      (2)
int main(int argc, const char *argv[])
{
        int fb;
        int loop;
        const data[] = { 0xff };
        fb  = open(FB, O_RDWR);
        if(fb == -1) {
                perror("cannot open fb.");
                return -1;
        }
        for(loop = 0; loop < WIDTH * PP; loop++) {
                write(fb, data, 1);
        }
        return 0;
}

$ gcc -o fbtest fbtest.c
$ ./fbtest

うん、画面の一番上に、白い線がぴーっと1ラインだけ引かれた。
何をするプログラムだったかというと、0xFFというデータを 1680x2バイト分フレームバッファに書き込むものだったのだ。
もし1ピクセルが2バイト以上であれば、線は右端まで届かずに終わっただろうし、横幅が1680ピクセルじゃなかったら、はみ出して次の行に表示されるなり短いなりしただろう。

じゃあ、次。

#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#define FB      "/dev/fb0"
#define WIDTH   (1680)
#define HEIGHT  (1050)
#define PP      (2)
int main(int argc, const char *argv[])
{
        int fb;
        int loop;
        const data[] = { 0xff };
        const empty[] = { 0x00 };
        fb  = open(FB, O_RDWR);
        if(fb == -1) {
                perror("cannot open fb.");
                return -1;
        }
/*
        for(loop = 0; loop < WIDTH * PP; loop++) {
                write(fb, data, 1);
        }
*/
        for(loop = 0; loop < HEIGHT; loop++) {
                int loop2;
                for(loop2 = 0; loop2 < PP; loop2++) {
                        write(fb, data, 1);
                }
                lseek(fb, (WIDTH - 1) * PP, SEEK_CUR);
        }
        return 0;
}

左端に白い線が出たと思う。
2byteだけ0xFFを書き、(横幅-1) x 2byteだけスキップ、という動作を高さ分だけ繰り返すプログラムだ。
これはこれで、間違っていなさそうだ。

 

つまり、/dev/fb0で保存したサイズが実画面よりも大きい、ということでいいのかな。
横幅は変わらなさそうだから、

3548160 / 1680 / 2 = 1056

つまり、実画面は1050ピクセルだが、保存は1056ピクセル分行っている、ということか。
あるいは何か別の用途で使ってるメモリなのか。

まあ、あまり気にしないでおこう。

[rpi]GUIアプリはどうやってつくるのか

Raspberry PiでPaSoRi RC-S370が動かせたこともあるし、GUIアプリの作り方も調べておきたい。

まず思いついたのは、Qt。
http://qt-project.org/wiki/Qt-RaspberryPi

と、ここでふと思ったのだが、私はどのプラットフォーム上で動かしたいのだろうか?
前回はRasberianで動かしたのだけど、どうなんだろう?
条件は、このくらいか。

  • libusbが動く
  • USB接続のキーボードとマウスを標準的な入力として見てくれる

マルチで動くウィンドウシステム上である必要は特になく、むしろシングルでフルスクリーンの方が望ましいかもしれん。
よい例えが思いつかないが、ATMみたいなイメージだ。
アプリが1つしか立ち上がらないような組込みシステムを動かしたいところだ。


話が逸れた。
組込みのGUI環境を使いたい、という理由を探しているようだ、私は。

検索すると「GENWARE」が出てきた。
まあ、これは有料なのだが・・・GAIOさんじゃないんだ。。。
次にGEALってのが出てきたけど・・・ITAccessさん。NetFrontとかもあるが、まさか・・・。
そしてQt。
PEGも出てきた。
10年以上前、仕事で使うGUI環境を探していたときと、あまり変わってないような気がする。
(Qtは候補にならなかったけど。)

しみじみしても仕方ないのだが、プラットフォームの性能が上がり、GUIが動くか動かんかぎりぎりの環境が淘汰され、汎用のGUI環境が動くくらいのプラットフォームが普通になってきた、ということなのかな。
力を入れるのは、貧弱な環境でいかにそれっぽく見せるか、ではなく、安くてそこそこパワーがある環境を持ってきて、それ自体をやりくりするパワーを減らし、もっとデザインなどに力を入れるようになったのかね。

わかってたつもりではあるけど、自分で文字にしてみると、ちょっとショックな感じだ。
自分の知っている環境がなくなってきたというショックではなく、確実に私が時代に乗り遅れているということがわかったというショックだ。


歳を取ると、昔を思い出していかんな。
家でやるんだから、取り残された自分を楽しむのもよいし、取り残されないように新しいことをやるのもよし、だ。

私としては、あんまりリッチな環境はきつい。
理由は簡単で、見栄えで勝負できないからだ。
負けるのは嫌いなので、負けにくい環境にしたいではないか。

イメージとしては、Lotus 1-2-3 R2.3Jくらいか。
あるいはWindows 3.0Aか。
MS-DOS5.0くらいかもしれんが、とにかく、CUIっぽいけど影がついてる、くらいのやつ。
できれば、画像くらいは表示できた方がよい。

となると、まず思い出すのはMicroWindows。
http://www.microwindows.org/
スクリーンショットを見ると、私の記憶よりもかなり普通のウィンドウを表示しているな。

富士通さんもやってて、オープンソースになったものがあるようだ。
http://www.widestudio.org/ja/index.html

いやー、探すだけでも難しいわぁ。

2013/10/12

RC-S390で遊ぶのはあきらめた(自力では)

さて、RC-S390が手に入ったので、ちょっと遊んでみようかと思った。
なに、PaSoRiは今まで扱ってきたから、Bluetoothさえ何とかなればいけるんじゃなかろうか。

・・・うん、ちょっと自力では無理そうだ。
努力してなんとかなるものと、ならないものがあると思うが、今回は後者だと思う。
うーん、SDKが出るまで保留か-(一般人向けに出るかも不明だが)。

RC-S390来たる

RC-S390が届いた。

アップで。

image

 

PaSoRi三姉妹。

image

 

うちのiPad miniから使える。
なお、アプリは「iPhoneのみ」なので、あせらないよう。

imageimage

456円??
いきなりバグか・・・と思ったが、本当にそんだけしか入ってなかった。

残念ながら、nimocaとかSuicaのチャージには対応していない。

 

なお、iOSアプリには2つあり、1つがPaRoRi、もう1つが楽天Edyだ。
片方のアプリがRC-S390をつかんでいると、もう片方からは使えないとか、そういうのはあるみたいだ。

んで、私はEdyはカードとしてではなく、おサイフケータイとして持ってる。
だから、チャージなんかはそっちっでやればいいので、今回はやらない。

 

さあ、お遊びはここまでだ。

2013/10/11

[rpi]Raspberry PiでPaSoRi

こんな記事があった。

http://enjoy-rfid.blogspot.jp/2013/10/raspberry-pi-nfc.html
Raspberry PiでNFC

Raspberry PiにACR-122Uを付ける例だ。

むーん、PaSoRiが負けてなるものか!

というわけで、作った。
Raspberianだっけ、標準っぽいOSでビルドして動かすやつだ。
PaSoRiは、RC-S330かS370(S380などは対応してない)。


libusbを使ったのだが、なかなかPaSoRiとの接続ができなかった。
デバイスとしては検出はできたのに、claimで失敗していたのだ。
dmesgしてわかったのだが、kernelにPaSoRiが取られてしまっていたのだった。
最近のkernelは、NFCデバイスをわかってるんだねぇ。
原因がわかれば、対処を探せる。
まあ、そのままkernelとかにまかせるのがいいんだろうけど、やり方を知らないのでね。

http://abc002.blogspot.jp/2013/06/raspberry-pi-nfc.html
sudo vi /etc/modprobe.d/raspi-blacklist.conf
----
blacklist pn533
blacklist nfc
----

 

あとは、いつものようにlibusbを使ってやるだけだ。
udevがないとビルドエラーになるので、先に入れておく。

sudo apt-get install libudev-dev

 

今回は、libusbxを使う。

wget http://downloads.sourceforge.net/libusbx/libusbx-1.0.17.tar.bz2
tar jxf libusbx-1.0.17.tar.bz2
cd libusbx-1.0.17
./configure
make
sudo make install

 

ここら辺は、githubに置いてる私の適当ライブラリだ。
Raspberry Pi用に、Makefileとサンプルを作り直した。

cd ..
wget https://github.com/hirokuma/libhknfcrw_c/archive/master.zip
unzip master.zip
cd libhknfcrw_c-master
make -f Makefile.rpi

cd examples/rpi
make

実行は、sudoでやる。
そうせんと、アクセス権がなくてusbが開けんかった。

sudo ./getuid

今回は、NFCIDを取ってくるだけのサンプル。
PC/SCなんてしゃれたものじゃないけど、組込み用途ならこのくらいでよかろうもん。

2013/10/04

RC-S390のことを勝手に考える

http://www.sony.co.jp/Products/felica/business/products/RC-S390.html

まあ、断ってから考えても仕方ないのだけどね。
(どうでもいいが「ことわる」って、これでいいよね? →「事・割る」が原型らしい(広辞苑))

 

まず、BLE対応したiOS6以降が対応、とのこと。
あまり詳しくないが、iPhone5とかiPad miniとかはBLEなのかね?
まあ、ここは私の知識が不足しているので、悔しいが飛ばそう。

特長は「iOSデバイスに対応」とある。
「iOSデバイスのみ対応」とまでは書かれていない
なので、将来的には別の、例えばAndroidデバイスでも対応できるかもしれない。

そもそも、無線やん。
ハードウェアが対応できないならともかく、お話しできるデバイスが搭載されているのであれば、通信できないはずがない。
なので、ちゃんと仕様が出れば、組込機器からも使用することはできるはずだ。
(R/Wとして)

 

Bluetooth機器とペアリングしてから使うことになるけど・・・スピーカーみたいにタッチしてペアリングってわけにはいかんのかね。
いや、iOSデバイスではなく、Androidとかでやるときだ。
R/Wだから、それをやるためにはいったんカードエミュレーションしないといかんけど、そのトリガがないよなぁ。

でも、きっとそこまで考えられてるんじゃなかろうか。
ほんとかなぁ・・・。
気になる・・・

えーい、買ってしまえ!!

HIGのお勉強 (1)

iOS7向けのHIGが日本語で出てきた。

と、通っぽく書いてみたが、最近まで「どいつもこいつもHIG、HIG」みたいな感じで、何を指しているのかすらわかってなかった。
ようやく、iOS(だけか知らんが)のHuman Interface Guidelineを指すことがわかった。

せっかくiPad miniを持ってることだし、知っていて損もないだろうから、勉強がてら書いていこう。


iOS7向けの設計 (1)

まず、この章から始まっている。

  1. 控えめであること
  2. 明瞭であること
  3. 奥行きを与えること

これが基本方針らしい。
ふむ、コンセプトを決めて、あとはそれに沿って肉付けをしていくのだな。

ここで標準の(だと思う)天気アプリの違いをスクリーンショットで見せているのだが、うーん・・・。
iOS7の方は空色の背景に白文字なので、読みづらい。
iOS6の方が、黒っぽい背景色になっているので「明瞭」と感じた。

まあ、その辺の説明も読み進めると書いてあるんだろう。

 

内容を尊重する

  1. 画面全体を有効に活用する
  2. 質感や本物らしさを考え直す
  3. 半透明なUI要素を使って、奥に何があるか見えるようにする

ここでいう「内容」とは、「ユーザが扱う情報内容」を指している。
日本語としては「ユーザが見たい情報」ということにもなるのかしら。

天気アプリの説明が1つ出てきた。
さっき「空色の背景」と書いたのは、実は「現在の天気情報」なのだ。
既存概念に私が凝り固まっているためか、あれが天気を表しているとはわからんかった。

主観的なものだと思うが、私にとってはわかりづらかった。
まあ、これは日本の天気予報番組の影響が大きいかもしれない。
天気というのは「アイコンで表すもの」というイメージが私にはあるのだ。
画像で表されると、なんだかわからなくなってしまう。

そんなわけで、天気アプリだと正当に評価できないような気がするので、そこについては触れないようにしよう。
(ちなみに「画面全体を有効に」は、背景に天気の画像を出していることを指している。)

 

もう1つの「質感や本物らしさを考え直す」は興味深い。
特に「考え直す」というところ。
「今までそう思ってたかもしれないけど、ほんとにそう?」というわけだ。

例で書いているのは「ベゼル、グラデーション、ドロップシャドー」で、多用すると重たくなってしまう、とのこと。
ベゼルは「枠」らしい・・・が、よくわからん。
ボタンとかを枠で囲むけど、ああいうやつか?
私としては、領域がはっきりしている方が安心するのだが、それが「考え直す」要素なのかもしれん。

というのも、私の世代だと、最初に見たウィンドウシステムが「Windows 3.0A」という人がまあまあいるんじゃなかろうかと思う。
いや、Lotus 1-2-3とかのメニューかもしれない。
基本的に8色くらいで、あまりごてごてしてない画面だけど、ウィンドウっぽくしてあるようなやつだ。
あれがすり込まれていて、現代の人々のニーズに合っていないという可能性は否定できん。

ただ、3番目の「半透明」は、肌に合わない。
半透明とかしたら、HWがやってくれたとしても描画速度落ちるやん、とか考えてしまう。
・・・そこがだめなのか?
でも、描画速度うんぬんよりも、磨りガラスっぽいのが苦手なのもある。
見えるなら見える! 見えないなら見えない!
はっきりしてほしいのだ。

まあ、そういうデジタルっぽい考えの人達ばかりがデザインしているからこんな世界になっちまって・・・ということを主張しているのかもしれない。


と、なるべく善意的にとらえながら読み進めてみた。
もちろん、まだまだ長いのだが、こんな感じで読んでいこう。

相手の言うことをそのまま鵜呑みにする必要もないし、無条件に反発することもなかろう。
私は、輪郭がきれいに見えるフォントよりも、ピクセルフォントのようにきっちり見える方を好む性格なので、デザインについてもそういう見方になっている。
(だって、ぼやっとしたものって、目が疲れるやん・・・)

 

まあ、新しい主流のデザインは、そういうのができる人に任せればいいや。
私の役目としては、「いやいや、最近はこんなのが流行ってるんですよ」と、流れに竿を差すようなことを言うことなんだろうね。
そう思って、ここを読み始めたってところだ。

2013/10/01

RC-S390の個人開発はできるのか?

iOS端末で使うことができるというRC-S390。
あまり興味はなかったのだが、電脳羊さんのところでSDKが出るようだという記事を見た。

たしかに、そう書いてある。

別途準備予定のソフトウェア開発キットとの連携により、iOS※1に対応したFeliCaのアプリケーション開発が可能です。

うむむむむ。

私もSDKが出るのは読んでいたのだが、RC-S390は「サービス事業者向けに提供する」ということだったので、個人向けはないんじゃないかなー、という気がしているのだ。

でも、私の予想は当たらないことで有名だから、できればはずれて個人でも開発できてほしい。
まあ、買うとしたら、SDKの内容が発表されてからだな。