開発用Apple IDの２ファクタ認証設定、このメールアドレスは利用できません！？
2/14に、Appleから全世界の開発者あてに「アプリ開発時に使うApple IDは、今後2ファクタ認証の設定が必須になるからね。2/27までにやっといてよ」とメールがきました。
うわー、めんどいなー、と。
おそらく、みなさんが普段使用しているApple IDはもう２ファクタ認証の設定をしている、いつの間にかしていたのではないかと。iOS11以降からうるさくなってるし、機種変のときやら機会も多くあるので設定済みになっていると思います。私も普段使いの分は設定済みです。
でもですね、開発用のApple IDって、「普段使い用とは別に新規で作成する」というのが伝統というか、デフォルトなんですよ。確かAppleも初期の頃は推奨していたような。そうすると、わざわざiCloudにログインしたこともないし、２ファクタ認証の設定もしているはずもない。そもそもApple Developerサイトにログインする時しか使いませんからね。だからこその上述の注意喚起メールということなのでしょうけども。
仕方ないなー、とMacで、普段のApple IDをサインアウトして、ログインし直して（コレがそもそもめんどくさい）、設定しようとしたら...メール認証が通らない！
「このメールアドレスは利用できません。他のアドレスを指定してください。」
いやいやいやいや、意味がわかんない。
普段、Apple Developerのサイトにはログインできてるアカウントだよ？これ、年会費１万数千円払ってるヤツだよ？？途中までログインすすんで、メールに認証コードも送られてくるのに、最後にハネられるってどういうこと？
あせってググりまくるも、この状況にぴったりくる解決策がなかなかヒットしない。なんどやってもダメ。これまでのこのAppleに悩まされた経験から、これは固執しても時間を無駄にするだけのパターン。一旦1日空けて、素直にサポートにヘルプをメールで要請したほうがいい、と。
で、翌日、やはり状況は同じで、サポートにメール。
その後、でも気になって何度か検索を続けていたら、
「他のApple IDの連絡先に設定してるとダメ」との情報が...。
「！！これだ！！！」と直感しました。
急ぎ、個人Apple IDを管理サイトで確認すると、ビンゴ。修復用というか万一のための登録に、開発用Apple IDをひもづけていました。これが原因。
いや、これはそうしたくなるのが人情やん？
自分で持っている２つのアカウントで、トラブった時の修復用にそれぞれひもづけたくなるもんちゃうのん？？
でもグッとこらえ、またドキドキしながら紐付けを解除し、あらためて開発用Apple IDで設定をすすめると...
「通った！！」
いやー、参りました。
そうそう、皆さんもご自分のApple ID、電話番号を複数登録できるので、スマホの番号だけでなく、ご自宅の番号も登録しておいたほうがいいですよ。スマホは機種変、番号変更もするので、それがなくなった時が悲惨ですから。SMS必須ではなく、自宅電話でも音声で６桁の認証コードが流れてきますので。最初はビビりますが、カンタンなのでオススメです。
５年はがんばってみてください
やっと道具をきちんと道具として、目的のために使いこなせるようになってきたな〜、と実感できたので覚書。
少し前に、動画をアプリに入れて配布したい、とのご相談がありました。
「え？YouTubeではダメなんですか？」
「検索することが手間で、見てもらえなくて。」
これまでYouTubeに動画をアップしてきたものの、あまりICTが得意ではない方々には届いていない、とのこと。このニーズを伺ってはじめて、YouTubeを閲覧する行為はICT活用の中でも相当簡単ははずであるという「主観」を反省するとともに、とはいえ、果たして効果が出るかはかなり懐疑的、という思いを同時に持ちましたが、
「ま、しのごの言ってる間に、ちゃちゃっと作ってみて、まずはやってみましょう！」
と応じました。内心、動画を閲覧するアプリを作った経験は無かったので少し不安はあったのですが、できないことはないはず、とOKを出しました。
そして、とにもかくにも動画ファイルを再生するには何が必要なのか基礎知識を調べるところから開始。Webでヒットするいくつかのコードを試しながら、基礎となる部分を固め、エラーを解決しながら、ひとまず動画再生を確認し、あとは操作まわりを思うように書いて約半日ぐらいでおおよそのアプリが出来上がり、その完成後に冒頭の感想をもったわけです。
これまでははじめての技術を相手にすると、だいたいが検索にヒットしたコードがうまく動かず、エラーの対処に相当な時間がかかっていたのですが、今は直す部分の予想が立てられるようになり、また、イメージした操作や機能をサンプルの基本に足しこむこともだいたいできるようになってきました。ひととおりのことを経験した感覚です。
iOS/Androidのモバイルアプリのプログラミングは、とにかく散漫な知識が多く要求されるので、目先のことを実現するためにふりまわされがちで、体系的にマスターすることが難しいです。相当時間、それらの枝葉の部分と付き合うと、その背後にある統一的な技術と技術をつくった根底にある思想が見えてきて、その思想を会得することができれば、一気に枝葉の技術を幹につなぐことができる、という感覚ですが、それまでが本当にツラい。５年ぐらいかかってやっとこの位置か、という感想です。
ようやく、プログラミングはそれ自体が目的ではなく、プログラミングはPC/スマホを道具として使いこなすための技術であって、それで「何を実現するか」にまで意識が向くようになった、もっと言えば余裕が持てるようになった、と実感しております。まだまだ勉強せねばならんことは山積みですけれども。
【iOS】画面サイズに合わせてボタンの幅調整 〜コードでAutoLayoutの制約を制御
いよおおおおし！！
やっと、やあ〜〜っとずっと悩みだった
「iPhoneの画面サイズに合わせてボタンの幅と間隔が調整される」
ために必要なコードと仕組みが理解できました…。
ずっと学ぶのを避けていたAutoLayoutの「制約」ルール、とにかくstoryboardでの操作がわかりにくくて。さすがに屈するしかないか、とあきらめかけていたところ、なんとかコードで制御する術を理解することができ、一気に眼前がひらけました。
戦闘力アップ！
これでiPadでもiPad Proでもどんな画面サイズもかかってきやがれってんだ！
https://github.com/tadakazu1972/FireEmergencyiOS/blob/master/FireEmergency/ViewController.swift
【iOS】Core Dataのクセがすごいんじゃあ
っだあああ！
キツイぞ、クセがキツ過ぎるんじゃああ！！
…すいません、ようやく、iOSでデータベースに保存した結果をテーブルに表示させる基本が理解できましたもので。
Swift2.2で、Core Data使って。
いや〜とにかくCore Dataのクセがひどい。
新しい概念をこねくりまわしすぎですわ。
Androidで作ったプログラムのiOS版で、同じようにSQLiteが使えるはず、としばらくウロウロして調べると、結局どうもCore DataはSQLiteを下支えに使っているということが判明し、SQLiteに固執して下手にサードパーティライブラリに手を出してロックインしてしまったあげくiOSのアプデで悩まされる未来よりも、本家Apple推奨技術で持続可能性を確保するほうがよかろう、とCore Dataに手を出したら…こいつがとんでもなくクセのかたまりでした。
【Android】新作、開始。
ホント、ぼちぼちと、です。
完成はいつになるやら予想もできません。
というか、ゲームシステムもまだ頭の中ででききっておらず、「どうしよっかな〜」という状態です。
まあ、この時期が一番楽しい時期なのかもしれません。
基本的にはサイドビューで、今回は前作のハイドライドのように画面切り替え方式ではなく、ちゃんと４方向１ドットスクロールをさせたい、と。
で、スクロールさせるためにはこれまではプログラミング的にはズボラかまして「マップ全体の配列を一気にすべて描く。表示されないところも含めて。」という暴挙に出ていたのですが、SurfaceViewを使うため描画速度がそれでは負荷がかかりすぎてゲームにならん、ということもあり、きちんと表示させるところだけを描画することを実現させています。
一時はあきらめかけたのですが、試行錯誤した結果、10x10の配列描画に加え、上下左右４辺を１列づつ追加で描画すれば実現できたので、泥臭い方法ですが「基本的に動けばいい」と思っている私としては満足しています。
SurfaceViewにこだわったのは、RPG(?)にするつもりなのでテキスト描画が多いのと、前作でやったようにダイアログを多用するUI設計ですので。
これだけ端末の解像度がいろいろになると、UIは固定ピクセルではやっとられんのですよね。
GLSurfaceViewの描画速度は魅力的ですので、テキストとUIが同時に使えればいいんですけども。
イマドキのプログラミングはクセがすごいんじゃぁ〜
iOSのアプリを作ってから半年以上経ち、そろそろObjective-Cの毒素も抜けてきた頃合いなので心機一転、今こそ食わず嫌いで避けてたSwiftに乗り換えるべく勉強すべし、とAppleのチュートリアルをペチペチ打ち込み始めてみたのでした。
実はSwiftが世に出た当初に敬遠していた理由としては、JavaScriptやRubyやPythonなどイマドキの言語の書き方になっていたことが大きかったのでした。「なんでいなんでい、どいつもこいつもオブジェクト指向になりやがって。所詮プログラムなんてメモリに値をぶっこんで、ポインタぶん回してナンボのもんじゃい！制御はオイラに任せやがれってんだこのやろォ！」と昔気質を気取っていたのですが、必要に迫られJavaScriptで小さなWebアプリをいくつか作り、イマドキのモダン（高機能）ブラウザの恩恵を受けた後ではすっかり馴染むカラダになってしまっていて、「あ！この書き方、楽ぅ〜。なんかJavaScriptっぽくない〜？」と逆に親近感を覚える変わりようなのでした。
ただ２点ほど、どうしてもしっくりこないクセがあります。１つ目は「？」の使い方。Optional型というもんなのですが、これは文字通り使い方が「？」なのでして。プログラマーが予期しないバグを防ぐための方策であり、効能が認められるからこそ採用されたのでしょうが、いかんせん学習し始めの頃はこの見慣れない「?」と、冗談のごとく対で使う「！」の記号の用法がイマイチどんな場面で役に立つのか実感が無く、いちいち「いるの？いらないの？」と悩まなければならない面倒くささだけが先に立ってしまい、頭に「入ってこない」のです。「あぁ〜、助かったぁ〜」という成功体験でもあればいいのでしょうけども、学習し始めの頃はそんな混みいったプログラムを書くこともないので、一向にありがたみがわかる気配がありません。
２つ目はAutoLayoutの使い方。iPhoneもさすがに画面サイズがバラバラになってしまい、なんとかそれに対応しようとしている努力はわかるんですけども、まあいきなりデザインしようとする画面が「正方形」なのは直感的では無く、違和感ありまくりですし、配置するボタンなど部品の位置をコントロールするために「制約」という考え方が気色悪い。人間、やはり部品を「そこに置きたいねん！」と思う「足し算」の思考が自然なのに、「えーっと、こうしたらあかんでぇ〜」と「引き算」の思考を積み重ねるのはなんともしっくりこなくて。これはAndroidのxml直書きの方がわかりやすいかなぁ。
ということで、そんなSwiftの気晴らしに、とAndroidのアプリも３ヶ月ぶりにやってみるか、とこの土日にAndroid Studioのアップデートもしつつ立ち上げ、まっさらな気持ちで今までおろそかにしていた根本的な部分からじっくり書き始めてみると、こちらはこちらでどえらいクセがあることに今更ながら思い知らされまして。UIスレッドっていうんですけど、長くなったのでこちらはまたの機会に。
感謝、ただひたすらに感謝の気持ち。
なにやら巷ではドラクエビルダーズが時間泥棒でたまらんとか。
面白さの秘訣は、やはり「創造」にあると思うんですよね。
私もその「創造」のオモシロさにとりこになっている人間で、この３ヶ月間はずーっとドラクエとまでは言わずとも、RPGそのものの「世界を創造するオモシロさ」にとりつかれておりました。
そして今日、ようやく完成と相成りました。
今はただ、感謝の気持ちでいっぱいであります。
私がこの「創造」を楽しむことができたのは、ホントに多くの人の努力のおかげだからです。
Javaを作った人、AndroidのOSを作った人、APIを作った人、開発環境のAndroid Studioを作った人、個人でも無償で使えるように公開してくれ、さらにはアプリの配布もさせてくれるGoogle。
そして、開発企業だけでなく、これらの技術が個人でも無償で使えるほどまで、モバイル端末を普及させた数多くのユーザー、消費者。ここまで爆発的に市場が広がらなければ、開発環境は高価でとても一個人が趣味で手を出せるものにはなっていなかったでしょう。いや正直、30年前には想像もつかなかった時代になっていますよ。
そういった理由で、感謝の気持ちなのです。
ありがとう、「創造」を楽しませてもらえて。
ちっちゃいプログラムですけど、RPGできました。
