2014年、App Inventorクローン「AppyBuilder」で作ったハンディーターミナルアプリが11年目に
確か、開発当時のOSバージョンは「Android 4.4：KitKat」
あれから11年、2025年最新OS「Android 16」の私のPixcelでも問題なく動きました！
すげー
ありがたい
ほぼタダで作った自作アプリ
何年使い続けられるかな？
と思ってたが、恐ろしく長期に、しかも安定して動いてくれてる！
Dear Mr. Hossein Amerkashi,
AppyBuilder作ってくれてありがとう
IT経費、すごく節約できてます！
「AppyBuilder」最強・最高です
SQLite、zip、ftp拡張が最高に便利！
「AppyBuilder」無くなって残念。
Offline版、今でも使ってます。
最新版、待ってます。
なお、Android 16のSQLiteは、Android 15と同じ
version 3.44
2014年12月、it経費節約のため自作したAndroidスマホ用「なんちゃってハンディターミナル」アプリ
使い始めて１１年目、いまだにちゃんと使えてます！
ありがとう
Mr.Hossein Amerkashi
先日、ハンディターミナル用スマホが１台故障。
形部商事のハンディターミナルシステム
世界的にも珍しい
ハードウェア使い捨て！
早速、１万円以下で２・３年落ちのスマホをYahooフリマ検索
で、これを買いました「2023年製・1ヶ月使用・Android13」
税込5000円、アプリ500円クーポン使って税込4500円！
4500円のハンディターミナル
激安過ぎませんか！？😁
これなら、あと５年は使えそう
アプリ開発・改造代＋ハードウェア代＋保守費用10年分、it経費５００万円くらい節約できたのでは！？
it経費、頑張ればかなりの金額、節約できますね！
でも、年齢とともにit技術のキャッチアップが辛くなってきた。
気力も激減
2014年12月に完成した自作ハンディターミナルアプリ
めでたく１０周年
私のPixcel 7aに 、出来立てホヤホヤ
最新バージョン「Android 15」が降ってきたので早速テスト
１０年前のアプリ、最新Androidで動くかな？
「お願い、お願い、お願い、動いてください」と、
思いつくすべての神様に拝みながら実行！
その結果
無事、動きました
あと２・３年は、使えそう！
Dear Mr. Hossein Amerkashi,
AppyBuilder作ってくれて
ありがとう
IT経費、すごく節約できてます！
「AppyBuilder」最強・最高でした。
SQLite、zip、ftp拡張が最高に便利！
「AppyBuilder」無くなって残念。
Offline版、今でも使ってます。
最新版、待ってます。
なお、Android 15のSQLiteは
version 3.44
| Android | SQLite | bulk insert |
|---|---|---|
| 4.4.2 | 3.7.11 | 最大500件 |
| 5.1 | 3.8.6.1 | 最大500件 |
| 6.0.1 | 3.8.10.2 | 上限なし |
| 7.0 | 3.9.2 | 上限なし |
| 9.0 | 3.22.0 | 上限なし |
| 10.0 | 3.22.0 | 上限なし |
| 11.0 | 3.28.0 | 上限なし |
| 12.0 | 3.32.2 | 上限なし |
| 15.0 | 3.44 | 上限なし |
Android Upgradeの度にやってるSQLiteのバージョンチェック
以前作ったVersionCheckアプリをAndroid 12でも実行
最新OS：Android 12のSQLiteは
version 3.32.2
| Android | SQLite | bulk insert |
|---|---|---|
| 4.4.2 | 3.7.11 | 最大500件 |
| 5.1 | 3.8.6.1 | 最大500件 |
| 6.0.1 | 3.8.10.2 | 上限なし |
| 7.0 | 3.9.2 | 上限なし |
| 9.0 | 3.22.0 | 上限なし |
| 10.0 | 3.22.0 | 上限なし |
| 11.0 | 3.28.0 | 上限なし |
| 12.0 | 3.32.2 | 上限なし |
ハンディターミナル開発を始めた2014年当時、「外部データインポート機能」の開発はとても難しかった！
SQLite versionは、Bulk Insert最大500件制限のある「3.7.x」。
プラス、ファイルを１つにまとめる「ZIP機能」、「FTP機能」がありませんでした。
インポートは、対象データを500行毎に刻み、Bulk Insertファイルを数十個作成！
そのファイルを、イントラWEBサーバへアップロード。
それを、アプリからFOR NEXTでファイルの数だけwebgetしてSQL実行！
すご～く、すご～く、
煩雑で、手間で、そして不安定でした
ネット掲示板で見つけた投稿
since version 3.8.8,the number of rows in a VALUES clause is no longer limited by SQLITE_LIMIT_COMPOUND_SELECT.
version 3.8.8以降「最大500件」のリミット撤廃
コードを書かなくてもアプリ開発が超簡単にできる最強の開発環境
AppInventor+SQLite extension
これから勉強を始める人は、とてもラッキー
モバイルデータベースアプリ開発
スゴ～く、楽ちん！
(がりがりコード書くよりは)
誰でも簡単にハンディターミナルアプリが作れるよ
まぁ、私は本家MITではなくAppyBulder Personal派
[AppyBulder Personal]
[本家MIT App Inventor]
先日、Android 11にアップグレードされた僕のGoogle「 Pixel 3a」
SQLite versionを調べてみました。
SQLite 3.28.0
歴代手持ち端末で調べたバージョン一覧がこれ
Android 11 SQLite 3.28.0
Andoid 10 SQLite 3.22.0
Android 9.0 SQLite 3.22.0
Android 7.0 SQLite 3.9.2
Android 6.0.1 SQLite 3.8.10.2
Android 5.1 SQLite 3.8.6.1
Android 4.4.2 SQLite 3.7.11
バージョンアップの度、SQLite versionを調べるようになったきっかけがこの投稿
SQLite 3.8.8から
1ファイルで処理できるbulk insert数500レコード上限が無くなった！
since version 3.8.8,the number of rows in a VALUES clause is no longer limited by SQLITE_LIMIT_COMPOUND_SELECT.
５００レコードを超えるデータを扱うアプリを作る場合
SQLite version 3.8.8の前と以後で
プログラミングの手間が大きく変わりました！
3.8.8以降の開発、とても楽！
これから始める人、羨ましい！
Android 4.4.2端末で実行するとSQLite 3.7.11(500行上限あり)
Android 5.1端末で実行するとSQLite 3.8.6.1(500行上限あり)
Android 6.0.1端末(=Nexus7)で実行するとSQLite 3.8.10.2(500行上限なし！！！)
Android 7.0端末(=Zenfone AR)で実行するとSQLite 3.9.2(500行上限なし！！！)
「Pixel 3a」Android 9.0はSQLite 3.22.0
Andoid10アップグレード後再実行してもSQLite 3.22.0
「Pixel 3a」Android 11はSQLite 3.28.0
2020年6月30日「AppyBuilder Termination」直前、駆け込みで行った自作ハンディーターミナルアプリの改造。
[[ai]AppyBuilder termination(2020/7/1)]
変更点は、SQLite versionでbulk insertファイルを切替える
[[ai]SQLite versionでif文の分岐処理をするには(2020/6/11)]
3.8以下なら旧「500行ファイル」
3.9以上なら新「10000行ファイル」
この仕様変更でms-Access製「bulk insert生成プログラム」にも新機能
「10000行ファイル生成」
このプログラミング、結構時間がかかりました。
実は私、独学の我流vbaプログラマー
私のvbaプログラムは素人プログラム
１つのプロシージャに
長々（=だらだら）と色んな機能を書いてます
今回は心を少し入れ替え
3種類のbulk insertファイル生成機能をサブルーチン化
次期SQLite仕様変更で最大数が変わっても、変数を変えるだけで簡単に対応出来るように作り直しました。
見た目もスッキリ
やれば、僕にも出来るじゃん！
[vb] Private Sub btnMAKEbulkFile10k_Click()call MakeBulkITEM (10000)
call MakeBulkSHOP (10000)
call MakeBulkRIREKI (10000)
End Sub
[/vb]
余談ですが、ずっと素人プログラムしか書けない言い訳は
プログラムを作るのも
改良するのも
操作するのも作者の私だから
本に書いてる「綿密な仕様設計」「プログラムの可読性」より
空いた時間に取り合えず作って即実践投入
を続けた結果。
100個以上作っても初心者みたいな書き方しか出来ません（泣）
永遠の素人
情けない
AppyBuilder製(App Inventor+SQLite)自作ハンディーターミナルアプリに久々の新機能！
[AppyBuilder]bulk insert 10,000行に対応
今は最大500行なので20分の1にインポートファイルを減らせる
SQLite 3.8.8(=Android 6.0.1)以上でbulk insert一括インポート500レコード上限が撤廃
[[ai]SQLite bulk Insert 500レコード制限が無くなってる！(2019/6/11)]
[[SQLite]Bulk insert最大レコード数は約270,000行(2020/5/29)]
僕のPixcel3a(Android10 & SQLite 3.22.0)でテストすると約270,000行の一括インポートに成功しました。
新しく作ったプログラムがこれ
動きは単純
１：Android端末のSQLiteバージョンを取得
２：3.9以上なら新上限数のbulkファイルをインポート
３：3.8以下なら従来の500レコード上限のファイルをインポート
テスト用プログラムを本番アプリへ移植するの簡単だと思ってたのに・・・・
ガーーーン、動かない！
270,000行でエラー
200,000行でエラー
150,000行でエラー
100,000行でエラー
80,000行でエラー
50,000行でエラー
30,000行でエラー
20,000行でエラー
最終的に1ファイル10,000行にしたらエラーが消えました。
20万行予定が1万行に！
残念、20分の1
テストは、1個のテーブルへ1個のbulkファイルで27万行のインポートに成功。
実アプリでは、3テーブルへ複数ファイルを同時インポート処理。
これが最大レコード数激減の原因かな?
まぁ、毎回作る約1000個のbulk insertファイルが数十個に減るので良しとするか
ちなみに、インポート時間も10分の1くらい早くなりました！
次はbulk insertファイル生成プログラム(ms-Access)の改造だ
まだまだ、やる事いっぱい!
久しぶりで自作ハンディーターミナルアプリを改良中
[[ai]SQLite bulk Insert 500レコード制限が無くなってる！(2019/6/11)]
[[SQLite]Bulk insert最大レコード数は約270,000行(2020/5/29)]
今開発してるのは
SQLite versionでマスターファイル名を切り替る
対象ファイル名を
(最大数500行制限撤廃後)
version3.8.8以上なら1ファイル200,000行のbulk insertファイル名を指定(新規開発)
(version 3.8.8より古い場合)
1ファイル500行(現行システム用)bulkファイル名を指定する
これが思った以上に面倒なの！
開発中のコードがこれ
１：僕のPixcel 3a(=Android10)でsqlite_versionを実行
SQLiteの返事がこれ
(sqlite_version() 3.22.0)
２：バージョン以外の文字列を取り除くreplaceブロックで掃除
「(sqlite_version() 3.22.0」をNULL
「)」をNULL
これでバージョン部だけになりました
3.22.0
ここからがメイン処理部「バージョン比較」
version 3.8.8より古いの？新しいの？
文字列比較では
3.8.8>3.22.0になってしまう！
文字列3.8xxxは3.2xxxより大きいから
数値比較でも
3.8>3.22になり正しく動かない
試行錯誤を繰り返し完成したコードがこれ!
versionの1桁目と2桁目を別々に保存
別々に比較する
まずversionの保存コードがこれ
メインのIF文
1桁目を比較
ver.4以上なら200000行ファイル
ver.2以下なら500行ファイル
ver.3なら2桁目を比較
2桁目が9以上なら200000行ファイル
2桁目がそれ以外なら500行ファイル
SQLite versionが
3.8以前ならファイル名：master500.zip
3.9以上ならファイル名：master200000.zip
実際のコードがこれ
全部つないだコードがこれ
動かすと
このコードをベースに、次は本アプリのソース書き換えです。
ベースプログラムがここまで完成してれば富士登山なら8合目！
ゴールは、もうすぐ！
その上でbulk insertファイル生成プログラム(ms-Access)の改造もしなければ・・・・
まだまだ、やることいっぱい！
余談ですが、なぜここ数日夜な夜な熱心にプログラミングしてると思います？
答え：痛風でアルコールが飲めなくなり夜もシラフだから
痛風、痛よ！
でも、お酒飲みたいな・・・
以前、ネットで見つけた投稿によると
SQLite 3.8.8で、
bulk insert(=一括インポート)最大数
500レコード制限が撤廃
[[ai]SQLite bulk Insert 500レコード制限が無くなってる！]
手持ち端末で調べると
Android 6.0.1端末(Nexus7)が上限撤廃後のSQLite 3.8.10.2
Android6.0.1以降のスマートフォンなら500行制限が無いみたい
では実際、何レコードまで一括インポートできるのかな？
早速、実験
使うのは私のスマートフォン「Pixel 3a」(Android10 : SQLite 3.22.0)
巨大なbulk insertファイルを作り徐々に行数を減らしていくと・・・
27,0709行(17,856,314バイト)までエラー！
インポートエラーでは無くアプリごとクラッシュが続きました
27,0708行(17,856,247バイト)でインポート成功！
INSERTコマンド部2行マイナスし
結果は、270,706レコード
次に、ファイルサイズでのインポートテスト
インポートに成功した270,708行ファイル(17,856,247バイト)に、無意味なtextを書込みファイルサイズ(17,856,314バイト)を増やしても上限がレコード数ならインポートできるはず！？
で、ファイルサイズが増えても
インポート成功！
と言うことで、SQLiteのbluk insert上限は、ファイルサイズ制限ではなく
レコード数制限。その上限は270,706行みたいです。
と思いきや
改めて270,709行目を書き加えて実験すると、あれ、インポート成功！
どういうこと？
バックグランドで動く別アプリの影響とか受けるのかな？
今回の実験、結論が出ない。
テストする度、最大数が変わる！
なぞだ
まぁ、ハンディーターミナル用マスターbulk insertファイル生成プログラムの作り変えは、余裕をもって1ファイル200,000行にすれば安定するのでは
新最大値:200,000行÷旧値:500＝400
これで、1ファイルに400倍のレコードが書ける！
マスターファイル生成の度、毎回1,000個近いbulk insertファイル作ってる。
これが3，4ファイルになるはず！
1,000個が4個に！
まるで夢のよう
今月、ドコモ法人契約変更で手に入れた1円スマートフォン
「Galaxy SC-02M」(Android 9.0 : SQLite 3.22.0) x 10台
利用中のAndroid4.x & 5.x & 6.0を新端末に切り替えればマスターインポートファイルを激減できる！
はずだったのに・・・・・・
こっちの方が慣れているから古いの使い続けます
という奴が大勢いるの(泣)
軽減税率導入に合わせて２件の得意先がシステム全面変更、１件が１部変更。
１人で３件の開発は無理なので１０月１１月中に２件を開発、残り１件はプロのシステム屋へ外注！
それに合わせてAppyBuilder製自作ハンディーターミナルアプリも改造しようとしたら・・・・・
ダメだ、予想通りでビルドエラー！
Kodularへの吸収が決まったAppyBuilder。
Build serverが止まってる！
Build failed! Connection refused(接続拒否)
さてと、苦労して作った僕のアプリ、Kodular吸収後も継続して改良・改造し続けられるといいけどな・・・・
ちなみにAppyBuilder本サーバ休止前、アプリ開発が続けられるようAppyBuilder Personal最新版が2019年3月に公開。
それを使えば開発・ビルドは可能です。
Kodularへ吸収後、PC上で実行するAppyBuilder Personal(ローカルサーババージョン)はどうなるんだろう？
これだけが頼り
使い続けられるといいな。
2020年は不安でいっぱい！
先日知った
SQLite3.8.8以降、bulkインポート500レコード上限数撤廃
2万行を500行ずつ小分けファイルに保存。
ファイル数だけFOR～NEXTする必要がなくなりました。
今ならマスターインポートプログラム、劇的にシンプルに作れるはず！
先月、試しに作ったのがFTPを使ったこれ
これでも十分シンプルですが・・・・
よく考えるともっとシンプルになるはず！
HTTPでbulkファイルをダウンロードすればいいんだ
使うコンポーネントは「Connectivity：WEB」
完成したプログラムがこれ
驚くほどシンプル！
バカみたいにシンプル！
細かな検証はしていませんが、GotTextイベントでのBulkインポート！
Gotは過去形！
なのでファイルダウンロード完了後のSQL実行だと思います。
テストファイル2万行、普通にインポート出来ました。
FTP・ZIP・FILEコンポーネントが無かった5年前に作った初回バージョンの100分の1のシンプルさ！
便利な時代になったな・・・・
素人でもモバイルデータベースアプリ簡単に作れるよ！
半月板を痛め休日なのに自宅でAppyBuilderの勉強中
暇だからハンディーターミナルアプリの市販品作ってみようかな・・・
使えそうなTableView extensionを本番アプリへ導入したい。
でもこのextension、カラム(=項目)1個増やすだけでレイアウトがすぐ崩れる！
カラム(=項目)の多い本番アプリでTableView extensionを使うには、
まずカラムを減らす方法を探さねば！
AccessのIsNull、IIF、choose的なもの
SQLiteに有るのかな？
で、見つかったのがこのページ
[値がNULLだった場合は指定した別の値を返す(ifnull関数, coalesce関数)]SQLiteではcoalesce関数を使うらしい
では早速テスト
目標は
JANコードがあれば表示、
無ければitemcd(=商品CD)を代わりに表示
なお、テストは「DB Browser for SQLite」を使用。
最初、AppyBuilderで勉強を始めましたが何度やっても失敗！
検証しやすいよう「DB Browser for SQLite」に変えました。
テストデータがこれ
SQL文がこれ
select
itemcd,jan,coalesce(jan,itemcd,’NoCODE’),itemname
from m_item
うううう動かないよ
JAN未登録商品で、代わりのitemcdが表示されない！
なんで？
そして１時間、右往左往・・・・・・・
あ、原因分かった！
元データが違うんだ！
(‘328030′,”,’立石園 さみどり’,0),
ではなく、こっちだ！
(‘328030’,NULL,’立石園 さみどり’,0),
ブランクで無くNULLじゃないと動かないのね！
早速、bulkインポートデータを’’(=0桁文字列)からNULLへ書き換え再インポート。
未登録欄がNULLになった！
ゴールが見えてきた
やっとcoalesce関数の使い方がわかりました
あれ？
本番アプリは、みんなブランク！
この場合、どうすればいいんだ？
また検索のやり直し！
NULLでなくブランク(=文字数0の文字列)の場合をネット検索し見つけたページがこれ
[カラムの値に応じて異なる結果を返す条件式の記述(CASE句)]このページを参考にSQL文を作成
select itemcd,jan,
case jan when ” then itemcd || itemname
else jan || itemname
end as CD_NAME
from m_item;
うまく動きました！
複数カラムをCASE ELSEとダブルパイプ｜｜で1つにまとめられたら本番アプリにTableView extension導入できそう！！
SQLite、奥が深い！
SQLite、スゲー面白い！
2014年夏「ハンディーターミナルアプリが自作できないか？」とネットをウロウロし辿り着いたのが下記のページ。
[SQLite Bulk Data Load–Hossein Amerkashi’s Blog(2014/5/6)]
「AppyBuilder(旧名Ai2LiveComplete)」開発者Hossein Amerkashiさんのブログ。
僕のハンディーターミナルアプリは、このページを参考に開発しました。
このページの注意書き：
Bulk insert into SQLite database has a limit of 500 rows. If you intend to insert over 500 rows, you’ll have to break your insert statements.
１度にインポート出来るのは500行。
それ以上なら、500行のファイルを複数用意しろ
レコード数1万行超の「商品・得意先マスターインポート機能」開発に、すご～く苦労しました。
500行ごとに分けbulk insertファイルを作る
今使ってるBulk Insertファイル生成プログラムがこれ（MS-Access製）
前処理完了後に次の処理を始める為、目視で確認しながら各工程のボタンを押すアナログな仕様。
1000個近いbulkファイルを取り込むハンディーターミナルアプリ側プログラムもかなり複雑。
この500行の壁がなくなれば開発が楽になるのになと思っていたら・・
新しいSQLiteには500行制限が無いそうです！
google検索で見つけた投稿がこれ
since version 3.8.8,the number of rows in a VALUES clause is no longer limited by SQLITE_LIMIT_COMPOUND_SELECT.
version 3.8.8以降、行数での制限は無くなった！
早速、確認
まず、SQLiteのバージョンの調べ方を検索
select sqlite_version();
SQLite version確認用アプリを作成
では、確認
Android 4.4.2端末で実行するとSQLite 3.7.11(500行上限あり)
Android 5.1端末で実行するとSQLite 3.8.6.1(ぎりアウト、500行上限あり)
Android 6.0.1端末(=Nexus7)で実行するとSQLite 3.8.10.2(500行上限なし！！！)
Android 7.0端末(=Zenfone AR)で実行するとSQLite 3.9.2(500行上限なし！！！)
うふ、僕の新スマホ「Pixel 3a」
Android 9.0端末で実行するとSQLite 3.22.0(500行上限なし！！！)
追記2020/5/23：Andoid10アップグレード後再実行してもSQLite 3.22.0でした。
では、実験
生成プログラムで作られたbulk insert文の500行目を501行目にコピペ
PRIMARY KEYの商品CDは存在しない番号、商品名は分かりやすく「501行目だよ」に変更
501行目、インポート出来るかな？
僕の元愛機Zenfone AR(=Android7.0(SQLite version3.9.2))でテスト！
すごーい、インポート出来た！
ちょっと感動
苦労させられた500行制限が無くなってる！
Android 5.1端末でギリだめだったので、社内のスマホが全てAndroid 6以上になれば500行リミテーションは完全に無視できる！
数十個の得意先マスタが、1ファイルに！
数百個の商品マスタも、1ファイルに！
インポート周りのプログラムを７割削れる
でも、使えてるAndroid 4.x、5.x端末を買い換えるのはもったいないか！
しばらくこのまま・・・
今どきの企業なら必ず有るのがSQLサーバ。
御社SQLサーバの目覚めはどうですか！？
形部商事のSQLは目覚めがすごく悪いんです！
朝イチ、サーバ起動直後からの数分間が特に遅い！
システム屋さん曰く
朝イチはキャッシュが空っぽ！
SQLサーバへの問い合わせを何度かすれば
キャッシュがたまりスピードアップします。
この対策用にシステム屋さんが作ってくれたのが「GoodMoring.exe」
SQLサーバへランダム参照しキャッシュを貯めるプログラム。
実行すると受注取込みが少しスピードアップしたかな！？
売上入力は遅いまま・・・・
という事で、自分でMS-Accessプログラム「GoodMorning4SQL.accdb」を作ってみました。
そして今日、朝イチでテスト！
作ったAccessプログラムがこれ
やってることは超シンプル
キャッシュに貯めておきたいデータに
SELECT * FROM WHERE すればいいんでしょ！
ODBC接続の「商品マスタ」「得意先マスタ」「受注テーブル」「売上テーブル」を開き
対象レコードをDebug.Printでイミディエントウィンドに意味なく書かせるだけ！
これでスピードアップするかな？
朝イチはSQLサーバの反応が悪く最初の２回はTimeoutエラー！！！
僕の「GoodMoring for SQL」効果あるみたい
余談ですが、「GoofMorning4SQL.accdb」のヒントになったのが、これ
ハンディーターミナルアプリ用「マスタデータbulk importファイル生成」プログラム。
SQLサーバへ接続
max500レコードはSQLiteの仕様
全ファイル約800個が完成するのに15分くらいかかります
よく考えると、これ実行すれば、
必要データ、キャッシュに貯まるじゃん！
試しに朝イチ実行すると、SQLサーバがスピードアップ！
それからの数ヶ月、毎朝これを実行してます。
でも、各ステップ用にボタンがたくさんあり、全部のボタンを押すのが超面倒！
「GoofMorning4SQL.accdb」は、マスタファイル生成の仕組みを全部削除。
ワンボタンで、単純に４つのテーブルを参照するだけ！
明日から、これを使ってみよう
たくさん押してたボタンが１つで済む
Windows10に、スタートアップフォルダって残っているのかな?
accdbファイルってwindows「サービス」に登録出来たっけ?
最初の2､3度は必ずエラーになる。
指定時間ではなく起動後プラス１分・３分・５分・７分、間隔を開けて複数回の自動実行って設定出来るんだろうか?
2019年初チャレンジ
自作ハンディーターミナルアプリをBluetoothバーコードスキャナー対応版に改造するぞ！
いざプログラムを始めるとあっけなく完成。
本当は、4年前の開発当初に８割完成済み。
残り２割は旧Androidの仕様で作り込めなかった部分。
Android 7+ 最新Google日本語入力だと微調整のみで対応版が完成しました。
この最新バージョン(＋スキャナー)を試してもらうと、まずまずの好評価！
そのまま1台目のスキャナーは実践投入。
仕事に使えるプログラムが完成したのでスキャナーを経費として認めてもらえ自腹回避できました(バンザイ)
さて次のバーコードスキャナーを買わねば！
スマートフォンの背面に取り付け片手で操作できる薄い筐体のスキャナーは無いかな・・・
とGoogle検索すると、まさにその為用のスキャナーが見つかりました！
それが「Socket S800」
これをスマホに固定して使えば、僕のアプリは一流端末「KEYENCE製ハンディーターミナル」に近づけるかな・・・？
SQLiteが使えるApp Inventor系サービス「Makeroid」に久しぶりにアクセスすると・・・・・
あれ、サイトが無い！
僕のテストアプリが無い！
マジ、Makeroidサービスが終わってる！
その上、初めて見聞るサイト「Koudular」へ勝手に誘導された！
やばい、フッシングサイトなの・・・
[Koudular]
このドメイン名を急ぎGoogle検索すると、3日前のこんな投稿が見つかりました！
Why Kodular :kodular:?
Well, it took us several days to decide a new name. We finally made up a word which can suit us: Kodular
The word Kodular comes from joining two words:
Kode -> This derivates at the same time from Code. We decided to add a K to it to make it different from the normal word. We pretend to tell that we provide a pseudo-code service, so it’s better calling it using a different word but at the same time similar
Modular -> We provide a “modular coding” service. Also, we will change our products names from services to modules, in a way we will provide different modules for app development such us the Creator or the Store
We also want to say that the word Kodular in Estonian means “the core”, so we think it perfectly suits us in a way we provide the core of the introduction to coding
貧しい英語力で、ざっくり読むと・・・・
そこで決めたのが「Kodular」
コード(code)とモジュラー(moduler)型開発の造語。
CodeのCをKに変え、Modulerを繋いだのが新サービス名。
新サイトで開いた僕のテストアプリ
ネット上のサービスって目まぐるしく変化し続けるので、ついてくのが大変です。
とにかく、苦労して作った自作ハンディーターミナルアプリの開発・管理に使ってる「AppyBuilder」は末永く続いてほしいものです。
まぁ、AppyBuilderもメンバーになってる4年間で3回サービス名が変わったんですけど・・・
今日は、ネットで見つけたいSQLiteが使えるApp Inventor系サービスの中で最も気になる「Makeroid」を勉強。
[Makeroid]
「Makeroid」は、「元祖MIT App Inventor」「Thunkable」とは違い”SQLIte extension”を使うのではなく、AppyBuilderと同様にオリジナル機能としてSQLiteを実装してるサービス。
で、使った感想は
デザイン画面がこれ
紫色基調でThunkableより配色がオシャレ
その上で、AppyBuilderに負けないオリジナル機能が盛りたくさん
僕のハンディーターミナルアプリに必要な３つの機能がオリジナルで実装されているのはAppyBuilder以外ではMakeroidだけ！
その機能が、「SQLite」「FTP」そして「File：UNZIP」
勉強用に作ったテストアプリがこれ
まずは、SQL executionの勉強
「Single SQL」ブロックでcreate table、 insert、drop tableを定義・実行
「After Execution」ブロックでSQL実行後の処理をプログラム
次はQuery（＝データ抽出）
「Row Query」ブロックにselect文を書き「After Query」ブロックにSQL実行後の処理をプログラム。このテストプログラムでは、select結果表示をListView:Elements(=ソース)に指定。
で、気になった１つ目の問題点
次いで２つ目の問題点
複数の検索機能を作るには、たくさんのSQLiteコンポが必要になる！
得意先検索、商品検索、履歴検索・・・・
同一画面に組み込みたい検索がいっぱいある時、とっても不便。
綺麗な仕様とは思えない。
AppyBuilderは「SQLite RunQuery」ブロックにSQL文を直書きするのでSQliteコンポ1個で好きなだけ検索機能を同一画面に持たせられる！
次は、Screenshot機能が有ったのでお遊びで追加。
Screenshotを撮りプレビューさせるプログラムがこれ。
Screenshot画像(=png)をimageコンポーネントへ表示させた様子
んん～、Makeroidって絶対パスで書くんだ！
最後は、FTPとUNZIPの勉強。
僕のハンディーターミナルアプリでは、ZIP圧縮したマスタデータ(数百のbulk importファイル)をFTPダウンロード後UNZIP、それをインポート。受注データは、固定長に吐出しFTPアップロードする仕様。
この仕様のアプリが作れるかテストしたプログラムがこれ！
ここで３つ目の問題点
テストアプリのパス「/storage/emulated/0/」は、Nexus7用(Android 6)。
Android 7.0「Zenfone AR」では、このパスでは動かない。
これでは端末のメーカー・OSバージョン次第で動く端末が非常に限られてしまう！
AppyBuilderだと相対パスでOK
ホームディレクトリのルート(/)から書くだけ！
これ、すごく便利な仕様です！
やっぱAppyBuilderは、世界最高No.1！
本家「MIT App Inventor2」で、SQLite Extension：aix-SQLiteをさわってみました。
[MIT App Inventor]
AppyBuilder以外で、App Inventor＋SQLiteをイジるのは初めて。
書き方が違うため理解するのに右往左往・・・・
んんん～、4年間使い続け慣れてるAppyBuilderが使いやすいです。
[AppyBuilder]
まず最初「aix-SQLite」をExtensionにインポートします。
画面のアプリは、Extension開発者がテスト用に公開してくれてるアプリ(aiaファイル)。
SQLite Executeブロック
AppyBuilderは、このExecuteブロックだけで開発！
WindowsのSQLite HelperソフトでSQL文を作りコピペするのがAppyBuilder流(＝僕流)
12ヶ月をinsert後、select結果をメッセージボックに表示させると
これ以外のブロックは、使い難くて嫌い！
特に、bindParamsの使い方が分からない・・・
SQLite updateブロック
SQL文が書けない人用なのか、各値いをバラバラで指定するスタイル。
でも、SQL文が分かってないと何書いていいか分からないはずなので、逆にこれ使いにくいです！
SQLite executeブロックで直接update文を書くことも出来ます。
こっちの方が分かりやすい！
SQLite insertブロック
SQLite deleteブロック
意味が分からないのがSQLite Replaceブロック
ReplaceってUpdateとは違うのかな・・・・・
実行すると最終行にINSERTされました！
select文の結果をListbox Elements(=ソース)にするには
ListBoxを開くと
結論：
App InventorでSQLiteを使うなら、extensionではなくオリジナル機能として実装してるAppyBuilderの方が安定してるように思う。あとSQLデータベースとは別に、ハンディーターミナルアプリに必要なのが基幹業務システムとの連携。
私は、その部分をAppyBuilderのFTPクライアント機能とFile機能のZIP圧縮を使ってます。
本家MIT App InventorにはFTPもZIPもないので、私仕様のハンディーアプリは作れない！
やっぱ、今んとこAppyBuilderが断トツ1番で優秀！
僕の最強ハンディーターミナルアプリ開発環境探しは続く・・・
次は、Makeroid＋SQLiteだ！
[Makeroid]「ハンディーターミナルアプリを自作出来ないか？」とGoogle検索「App Inventor + SQLite」をしてたのが2014年秋。
その当時、唯一見つかったのが有料サービス「AL2LiveComplete(=現AppyBuilder)」でした。
あれから4年、「MIT App Inventor2」にExteision機能(=拡張用インターフェイス)が加わり、有志がSQLite Extensionを公開してくれたことで、今同じgoogle検索すると複数のサービスが見つかるようになりました。
SQLite Extension
[aix-SQLite（App Inventor extension for SQLite）—GitHub]
2018年秋時点で、SQLiteが使えるApp Inventorベースのサービスがこれ！
AppyBuilder以外に、ハンディーターミナルアプリをより快適に作れる開発環境がないか試してみました。
最初にイジってみたのが「Thunkable」！
このサービスの最大の売りが、同じプログラムでAndroid用とiOS(=iPhone、iPad)用プログラムが一度に作れるCross-Platfome！
へぇ、App InventorプログラムがAndroidとiPhoneの両方で動くなんて夢みたい！
で、早速テスト！
Android用コンパニオンAppがこれ
Android用アプリ＋iOS用アプリが同時に作れるサービス「Thunkable ✕」が公開されたのは４ヶ月前！
出来立てホヤホヤ。
iOS用コンパニオンAppがこれ
操作画面がこれ！
薄いピンクと濃い紫色が使われてる、配色がダサい今ひとつのデザイン！
Thunkable Xの「User Intarface」ブロックはたったの8個！
Cross Platformを実現するには、この超ベーシックな8個が限界なのかな？
Checkbox、ListPicker、Spinnerが無いのは困る！
ちなみにAndroid専用サービス「Thunkable Classic」の「User Intarface」ブロックは17個！
AppyBuilderGoldは26個もある！
さてと、ではテストアプリ作成開始！
あっ、そう言えば・・・
私、iOS端末持ってたっけ？
僕、Apple嫌いでiOS端末を買ったことはほぼ皆無！
丁寧に作り込まれたキレイな製品を割高プライスで買う性格ではないです！
私の金銭感覚は、程々の製品が程々の金額で売り出され、それを直ぐには買わずに我慢！
型落ちし値が下がってから買うのが私！
唯一持っていたのはFileMakerでハンディーターミナルアプリ開発の勉強用に買った5世代目iPod Touch！
FileMakerのあまりのポンコツな開発環境に嫌気がさし勉強を中止してからはほとんど使っていませんでした。
そこで、まず久しぶりに使うiPod touchのOSをアップデート！
対応可能な最新OS「iOS9.5.3」へアップ後、「Thunkable X」製テストアプリをメール送信しインストール。
んんん～、実行すると予想通り「信頼性エラー」で動かない！
厳しい「Apple Store」アプリ審査無しの野良アプリを動かすにはひと手間必要でした。
「信頼」設定しろと警告が出て止まった！
そこで、Rappidly Incを「信頼」設定！
これで準備OK！
それでは、テストアプリを実行すると・・・・（あれ？）
夢のクロスプラットフォーム開発のテスト結果は、「即クラッシュ！」
ならばAppleStoreからインストールしたThunkableLiveコンパニオンアプリを実行すると。。。。
やはり、即クラッシュ
まったく何も動かない！
ipod touchのiOS9.3.5が未対応OSなのかな？
そこでgoogle検索「Thunkable ios version」
下のページに、iOS 8以上と書いてます！
だったら、何でクラッシュするの!?
Specifically, Thunkable is compatible with all Android devices that are running Android 4.1 and above and all iOS devices that are running iOS 8.0 and above.
iOSアプリと言ってもiPod Touchでは動かないのかな?
とにかく「Thunkable X」にはExtension機能が無い上、Android用の半分近いコンポーネントが使えない発展途上の開発環境でした！
Apple製品にまったく興味がない私にとって「Thunkable X」は全然魅力的に見えないサービス！
AppyBuilderの方が、10000倍使える開発環境だと思います。
App Inventorの新機能「パーツサイズのパーセント指定」で作り変えた僕のハンディーターミナルアプリ！
私物ZenfonAR(台湾製)、買ったばかりのZTE BladeS g03(中国製)でいい感じで動いたのに・・・・
SHARP Aqueous(日本製)で、予想通りの不具合発生
前者と後者の違いは、端末下部にある３つのナビゲーションボタンが、ハードウェアかソフトウェアかの違い。
個人的に、海外製のナビボタンはハードウェアが多く、日本製はソフトウェアが多いような気がします。
「パーツサイズのパーセント指定」機能で作った画面は、ソフトウェアナビゲーションボタン分操作画面下部が見えなくなる。
それを見越し高さを縮めるとハードウェアボタンの端末で下部に隙間が空いて不格好
もともと、前バージョン開発時「パーツサイズのパーセント指定」機能が無かったので、自作のリサイズ機能を作成。
それでも、同じ問題が起きたので「画面縦サイズ任意pixelマイナス」機能を加えました。
最新バージョンは、開発環境自体が画面サイズを取得するので、画面サイズのマイナス調整ができません。
この問題とは関係ないが、MaterialDesignのタイトルバーが無駄に太いのも気に入らない
数字ボタン１列分以上あるのがもったいない！
その上で、高齢化が進む我社、文字は可能な限り大きくするよう言われてる。
やれやれ、タイトルバーの非表示を含め高さ調整のやり直しか・・・・
