白い悪魔No.0843、
遅延書き込みを覚えました。

まあ、レベルの低い話です。

今までは一定周期ごとの割り込み処理で、その手の動作の代用をしていましたが、、

その割り込み周期が何回目か? という管理に変数を使っていたんです。

アプリ内で漢字とか使えれば良いのですが、変数名って考えるのが面倒なんです。

英語でそれっぽい言葉にしても、、

ーーー

原因不明の不具合が発生したことがあります。

あり得ない動き方をアプリがしたんです。

その条件で、その処理を行う事はあり得ないという処理が、、

原因を突き止めるまで2、3時間掛かりました。
ーーー

同じような名前、長ったらしい名前を使っていると、
コンパイラー側が判断できなくなって別の処理を実行してしまうというバグが、、

つまり、そういう問題を事前に防ぎたいのなら、
短い変数名、関数名でプログラムを書け、、

そう言われても、、
後々から分かるように変数名を付ける訳です。

低い言語力を使って、、

変数名や関数名に漢字が使えたら、、どんなに楽なことか、、
ーーー

アップルが用意するシステムは信用していません。

仮にコンパイルが通ったとしても、正しく動く保証はありませんし、

次のバージョンアップでコンパイルエラーが発生するリスクがある訳です。

そんな危険な賭けは出来ませんが、、
ーーー

Xcode内で、漢字の検索は出来ません。

つまり2バイトコードには対応していないという事です。

私の場合、英語版を作っているので、そちらの文字列を検索してアプリを修正します。

白い悪魔No.0842、
無料版と有料版を並行して作っています。

機能限定版とフルセット版、、

以前は、ノーマル版と、特殊用途に対応したチューニング版という関係でしたが、

今回は、機能限定版とフルセット版という位置づけで対応しようと思っています。

ーーー

アプリ内部では何をやったら良いか、開発効率を優先する方法はと考えると、、

機能をパッケージ化して、ブロック単位で交換、チューニング出来るのが楽だと思っています。

ーーー

最悪の場合、中身は同じで、ユーザーインターフェイスの部分だけ、その機能の選択部を殺せば良いんです。

ただ、それだとあまりに無用心です。

ユーザーインターフェイスを経由せずに、内部データを書き換えられたら、その機能が動いてしまうので、

無料版は、その機能をつかさどるユニットを未実装にしてユーザーインターフェイスでも使えなくするのが、一番楽かなと思っています。

ーーー

まあ、今更ですが、、後の祭りですが、、

共通パーツ、特殊パーツと厳密に区分けしていなかったので、今からそういう作業を行います。

同時期のアプリでも微妙に、個別機能のバージョンや記述が異なり、相互交換しても現状は動作しません。

また、動いたとしても、、どれだけ信頼性があるか、、

ーーー

自業自得です。

日頃から、そういう作業を厳密に行っておけばよかった、、

自分が撒いた種です。仕方ないですね!

白い悪魔No.0841、
私は技術が無いので自分の出来る範囲で対処します。

アプリ開発も、自分が欲しい情報だけを仕入れて作っている訳です。

参考書も買いましたが、使いませんでしたね、、結局、、そしてそこに書かれていることが今でも使えるのか、、疑問です。

アップルが用意したswiftという開発言語でアプリを開発している訳ですが、毎度毎度、天才にしか判らない様な謎仕様の変更をしてくれることにより、

当座、今自分が使う機能以外は覚えても意味が無いと言う状態が続いています。

天才集団を自認する割には、目先の事しか考えていない節があり、、その場対応で仕様がコロコロ変わる訳です。

ーーー

勉強する価値がないものをしても意味がない勉強はする気がありません。

私にはそういう余裕が無い訳です。

プログラム技術は、始めた当初からあまり変わっていないと思っています。

最近の問題は、変数の名前の付け方、関数の名前の付け方、、そしてViewControllerから、どうやってデータを追い出すか、、です。

ーーー

必ずViewControllerに書かないといけない記述があります。

そういう部分に限って、コピペでどんどん行数を増やして書く様なハードウェア寄りな記述なんですが、

私としては、1つの機能として、ソースファイルを分割したい訳です。

ーーー

分かり切った記述、今は考慮しなくても良い記述は別ファイルにして機能別に管理したい訳ですが、私が知る限りではそれが許されていない訳です。

結果、1つの機能をハードウェア寄りの記述と、論理部に分けなければなりません。

ーーー

それが頭で判っていても、気持ちが乗らない訳です。

実体化させる部分の処理は必ず残る訳です。

頭では割り切れなくても、それをやらなければならないのが今の状態です。

アプリを改良し続けていると、必然的に機能が増えます。 開発者が増やす気がなくとも、、

メインの機能をサポートするための機能を拡充しないと売れないからです。

何か問題が起こるたび、それをフォロする機能が機構が増えます。

ーーー

私も、こじんまりとしたアプリとして作って来ましたが、機能だけでは売れないのでデザインにも力を入れ続けた結果、、肥大化の一途です。

自分の頭で処理出来ることは限られています。

既に作った人間の理解の範囲を超えており、部分的にその記述を頭に入れて作業をするしか無いのが実情なんですが、、その際に余分なものを見える箇所に置きたく無いんです。、、ですが置かざるを得ないのが実情です。

基本的に自分が理解できるのは、パソコン画面に表示される範囲だけです。

それ以上、記述が長いとその機能の全貌を理解することが困難になります。

ガチガチに最適化して、行数を減らしたとしても、

メンテナンス出来ないような記述では困ります。

結果、平易な記述で簡潔に書くことが見通しの良いプログラムになる訳ですが、それは行数が増えるということです。

下手に、関数化して機能を飛ばしまくると、、何をやっているのか判らなくなります。

こういうところのバランスの取り方が下手です。

早急にアプリをリリースしたいと云う気持ちばかり先走ってしまい、最近、疲れ気味です。

取り敢えず、動く様にしたアプリも所々、自分が思い描いた動作とは違ってました。

まあ、不具合でその機能が正しく動かない訳です。

そして、触ってみると、1日、外に出て触っていると足りない機能も判ってくる訳です。

不具合対応と、設計改良の日々は、当分続きそうです。