4D」カテゴリーアーカイブ

Macで4Dのプロジェクトを署名付きでビルドする アプリ配布編

内容が多いので、準備編とアプリ配布の2回に分けることにした。4Dはv17.1。

4)4Dプロジェクトをビルドして、署名付きアプリを作成

4DにADCのキーを入力して、「署名付きビルド」を実行。

図 4Dのアプリケーションビルドでアプリケーションの「認証名」を入力
図 「DC_Build」フォルダができて、その中の「Final Application」というフォルダに署名付きのアプリができる

5)「xx_Build」フォルダにできたアプリ「A」(xx.app)を複製して「B」(xx.app)を作る。

図 一つ上の「DC_Build」フォルダに複製を作ったところ、左がB、もとのがA

6)アプリ「B」を実行してデータファイル群を作成

「B」を実行すると、4Dとしてはアプリと対になるデータファイル(.4DDファイル)が見つからないため、作成するかどうかダイアログを表示する。これを抑制する手段がない。このダイアログが表示される前にメソッドを実行することができないのだ。アプリの配布形態は自由、方法はいくつもある中で、エンドユーザにこのダイアログを見せるかどうかが大きな分かれ目となる。ユーザにこのダイアログを操作させる場合、好きな場所にデータファイルを保存することができる、というメリットがある。一方で電話やメールでのサポートはやりにくくなる。もう一つ重要なのは、ここで作成した場合のデフォルトフォルダは.appのパッケージの中だということ。パッケージの中に.4DDファイルを作成してしまうと、将来アプリがバージョンアップした場合にユーザの.4DDファイルを誤って消してしまう確率が高くなる。

図 4DDファイルが見つからない場合は、自動的にこのダイアログが表示されてしまう

[作成]をクリックして、「B」と同じフォルダ内にデータファイル群「C」(.4DDファイルなど)を作成。

必要な初期設定データがあればここで.4DDファイルに取り込む。ウチでは起動時に自動的にResourcesフォルダから取り込むようにしているので、「B」を実行すれば初期設定データは自動で登録される。「C」ができたら「B」は削除。4Dアプリは一度実行すると中身が変化してしまうため、「B」は署名情報が不完全なアプリ、つまりネット経由で配布しても起動できないゴミアプリに成り下がってしまうのだ。

7)アプリフォルダ作成

配布したいフォルダ(この場合「会計ジロウ」)を作成、「A」と「C」と「お読みください」「会計ジロウについて」を入れる。一つ上に親のフォルダ(この場合「DC100_mac」)を作っておくとよい。ユーザがdmgファイルをマウントしたときにフォルダをドラッグできて便利。

8)ディスクユーティリティで.dmgファイルを作成

フォルダから作成。イメージフォーマットは「ハイブリッドイメージ(HFS+.ISO/UDF)を選択。ここで圧縮してはいけない。


図 ディスクユーティリティで新規イメージをフォルダから作成
図 dmgファイルのイメージフォーマットは「圧縮」ではなく「ハイブリッドイメージ」で作成

9)codesign -s

.dmgファイルに署名する

例:

codesign -s “Developer ID Application: Jirokichi and Company (7N7LW3N8XG)” /current_projects/4D会計ソフト/prj_v17_dcc/DCv104_mac.dmg

【注意】実際にこのコマンドを使うときは、”Developer …”のところをご自分で取得したキーに置き換えて実行してください。

10)zip圧縮

ようやくここで圧縮してファイルを小さくする。ここまで圧縮はしていない。途中で圧縮してはいけない。

11)サイトにアップロード

12)別のMacでダウンロードして実行

参考:
codesign -s “Developer ID Application: Jirokichi and Company (7N7LW3N8XG)” /current_projects/4D会計ソフト/prj_v17_dcc/DCv104_mac.dmg 

Macで4Dのプロジェクトを署名付きでビルドする 準備編

内容が多いので、準備編とアプリ配布の2回に分けることにする。

このところ毎週、多いときは毎日のようにこの手順を実行している。道具と手順が多めで、慣れていても間違える時があるし、あとあと誰かに伝えるときにまとめ直すのも大変そうだから今のうちにブログに書いておく。

署名付きビルドを達成する道順は1つではない。アプリの出荷形態によっても異なる。うちの4Dアプリはデータファイルをバンドルして出荷する形が主流で、データファイルはアプリの横に置くようにしている。これはアプリのアップデートの際に、ユーザがデータファイルを識別しやすいと考えたからである。

4Dアプリは起動すると、On Startupメソッドが実行される前にデータファイル(.4DDファイル)を必要とする。もしデータファイルが認識可能なフォルダにない場合、作成するかどうかのダイアログが表示されて、ユーザが任意の場所にデータファイルを作成してしまうかもしれない。これを避けるために出荷時のファイル構成にデータファイルを加えておき、そこに起動時に必要な最低限のデータを格納しておく。例えば郵便番号とか、デフォルトの設定とか。

この出荷形態を前提に署名付きビルドの手順を示す。

用意するもの

  • ビルドしたい4Dプロジェクト
  • ビルドマシン:今回はMacBook Pro (13-inch, 2018)、macOS Mojave

ADCがらみは一度取得すればマシンを変えない限りずっと使える。ライセンス付き4Dは1年間有効のデベロッパー契約を結んでいる。

  • 開発者アカウント(ADC(developer.apple.com)、iTunes Connect)
  • ADCから発行された「Developer ID Application」
  • 4D Developer License付きの4D

キーチェインアクセス、ディスクユーティリティー、ターミナルは、macOSに同梱されているので、ドックにドラッグしておくとよい。

  • 「キーチェインアクセス」アプリケーション
  • 「ディスクユーティリティー」アプリケーション
  • 「ターミナル」アプリケーション

1)iTunes Connectにログインして、開発者のキーを取得

2)キーチェインアクセスでビルドマシン固有のキーを作成

3)ターミナルで「xattr -c -r」を実行して拡張属性を取り除く

ビルドする前に、4Dのプロジェクトが入っているフォルダーの中身のファイル全部の拡張属性を取り除く。

拡張属性はファイルをネットからダウンロードした際にmacOSが自動的に設定するもの。ビルドに必要なファイルの拡張属性がすでに取り除かれていた場合はこの手順は不要。

ビルドマシンですべてのファイルを作成している場合は問題にならないが、たとえば次のようなファイルが含まれているときは要注意。別のマシン(ビルドマシンではないmac)で作成してネット経由でもらってくる、というのはよくある話。

  • アイコンファイル .icnsファイル
  • Resourcesフォルダ内のファイル 各種設定ファイルをこのフォルダに置く場合
  • Componentsフォルダ内のコンポーネント ビルドマシンでコンパイルしておくと良い
  • 「お読みください」

署名付きビルドが失敗した場合は、次のコマンドでプロジェクトに含まれるファイルの拡張属性を疑ってみる。

  • xattr -p
  • xattr -d

Macで4Dのプロジェクトを署名付きでビルドする アプリ配布編」


会計ジロウ法人 発売開始について

ブログ 会計ジロウ法人 発売開始について

2018年3月に発売開始した会計ジロウですが、青色申告版「会計ジロウ」に加えて、法人版「会計ジロウ法人」を販売開始することができました。関係者の皆様、ご協力ありがとうございました。

青色申告版は消費税を「税込」でしか扱うことができませんでした。このため課税事業者で青色申告している方にはお使いいただけませんでした。法人版は、税込入力方式は青色版と同じですが、消費税を税抜で決算書を作成できる機能が実装されています。課税事業者、非課税事業者のどちらの場合でもお使い頂ける仕様になっています。決算書の形式は青色とは異なりますが青色申告の個人事業主の方にもお使いいただけます。なんといっても最大の特徴は消費税の自動計算&シミュレーションです。

治郎吉商店では、従来から税込入力、税抜決算書で法人税を申告してきました。簡易課税を検討することもできますが適用していません。売上が1千万円以上5千万円以下なのです。当社の場合、会計ソフトには次のような機能が必要と考えました。(Aクラス)

A1)金額を税込で確認できること
A2)税抜のBS、PLを確認できること
A3)消費税計算書

このほかに目標とした機能として次があります。(Bクラス)

B1)複数年のデータを一つのファイルに保持して、過去の仕訳を確認できる
B2)「あとで確認」の機能を設けて、未確定な仕訳があることをわかるようにする
B3)経営分析のために損益推移表を出力できるようにする
B4)BS、PL、損益推移表の項目は編集することができる

今回のリリースには間に合いませんでしたが次のもあります。(Cクラス)

C1)減価償却費の月額を自動仕訳

これらのほかに、会計ソフトとして必須な機能があります。(Zクラス)エクセルのテンプレートでは実装できない機能です。

Z1)借方貸方の合計があっていない伝票は登録できない
Z2)借方貸方の合計があっていない開始残高は登録できない
Z3)借方貸方の合計があっていない仕訳データはインポートできない
Z4)勘定科目は科目コードで指定、選択画面で選択も可能

4D v17のオブジェクト、v15プロジェクトからの移行時の注意

4D v17のオブジェクト、v15プロジェクトからの移行時の注意

オブジェクト型を使う際に気をつけたいことに遭遇したので記す。今回はv15以前からのプロジェクトをv17に変換したケース。

当社では「JCL4D」という共通ライブラリを用意していて、v15以降でサポートされたMETHOD xxコマンドを使って、プロジェクトに読み込んで利用している。JCL4Dは各メソッドをテキストファイルに書き出して、GitHubにて管理している。

最近このJCL4D v17版を作成した。以下「JCL4Dv17」にはフォームをリサイズする機能が含まれている。ユーザがウインドウをリサイズした際に、4Dの拡大/縮小的な動きではなく、ボタン、リストボックス、フィールドの縦横が拡大/縮小、フォントサイズも大きくなったり小さくなったりする、ズームのような機能だ。ユーザがリサイズした際のズーム比率や、フォーム上のオブジェクトの座標を覚えておいて、あとでセットするために、オブジェクト型の変数を構造体のように使って実装した。この機能をv15から変換したプロジェクトにも読み込もうとしたところ、今回のケースに遭遇。

データベース設定の互換性のところに次のオプションがある。v15から変換したプロジェクトでは、このチェックは外れている。

□ オブジェクト記法を使用してオブジェクトのプロパティにアクセスする

JCL4Dv17はこのチェックがついていることを前提にしているので、どの道チェックすることになる。チェックしてからメソッドをインポートすれば問題は起こらなかった。うっかりチェックを外した状態で、自社製インポートメソッドJCL_A_method_importを実行すると、オブジェクト参照のところに変なゴミが入る。外部テキストファイルからメソッドを読み込んでMETHOD SET CODEするメソッドだ。問題の箇所を一部抜粋したのが次のコード(A)。

このコードでは、親メソッドから第三引数にオブジェクトのポインタをもらって、そのフィールドを参照している。「$inObjPtr->rowsHeight」となっていたコードにドット(.)が挿入されて「$inObjPtr->.rowsHeight」になっている。もとの外部テキストファイルのコードは次(B)。


C_POINTER($3;$inObjPtr)  //リストボックス情報オブジェクト
$inObjPtr:=$3

  //行の高さ
C_LONGINT($rowsHeight)
$rowsHeight:=($inObjPtr->rowsHeight)*$ratio
LISTBOX SET ROWS HEIGHT(*;$inListbox;$rowsHeight)

データベース設定で「オブジェクト記法を使用してオブジェクトのプロパティにアクセスする」にチェックしてから、あらためて外部テキストファイルからメソッドを読み込んでMETHOD SET CODEしてみたのが次のコード(C)。

「$inObjPtr->」の後ろのプロパティ名が認識されて、カラーシンタックスが正しく適用されている。ドットは挿入されていない。

「$inObjPtr->」は実体であるため、実体にドットを付けてobject.propertyという形に勝手に変更されてしまったのだろうか。METHOD SET CODEの仕様なのか、別のコマンドによるものか確認はしていない。

いずれにしてもv17以降では、そもそもオブジェクト型の変数は、もともとポインタのようなものだから、引数に渡す際にポインタにする必要がない。C_TEXTやC_LONGINT型の変数と同じように、オブジェクト型のまま渡せば良くて、参照渡しなのでプロパティに値を代入して戻すこともできる。

だから上記のコードも次のように変更するべきだ。

【注意】この表記はv15以前ではサポートされていない。

4D v17のオブジェクト、v16プロジェクトからの移行時の注意

4D v17のオブジェクト、v16プロジェクトからの移行時の注意

v16からv17に移行したプロジェクトの場合、データベース設定の「互換性」に次の項目がある。

1)オブジェクト記法を使用してオブジェクトのプロパティにアクセスする
2)オブジェクトではISO日付フォーマットの代わりに日付型を使用する

v17で新規作成したプロジェクトにこれらの項目はない。
オブジェクト型の変数はv15から使えていて、その当時は次のコード1のような使い方だった。

コード1:
C_OBJECT($obj)
OB Set($obj;”sl_id”;String(1))

$sl_id:=Num(OB Get($obj;”sl_id”))

ところがv17では次のコード2のように使う。

コード2:
C_OBJECT($obj)
$obj:=New object
$obj.sl_id:=1


$sl_id:=$obj.sl_id

両方とも使ってみたが生産性が違う。単なる表記の違いではなく機能が違う。コード1では、オブジェクトのプロパティに”sl_id”のように文字列を指定しているが、ダブルクオーツで囲むためカラーシンタックスが働かない。カッコ、ダブルクオーツ、セミコロンで囲まれているためか、フィールド名が違っていても気づきにくい。また、一部サポートされていないデータ型があるため、当社では上記のようにすべて文字列としてプロパティに値を代入していた。その結果としてオブジェクト内部ではデータ型は失われていたことになる。型チェックは働かない。

コード2では、ドットに続く表記はフィールド名になる。カラーシンタックスが働く。オブジェクト内部でデータ型が維持される。型チェックが働く。いいことしかない。

OB Setの記述を見つけたら、今のうちに全部置き換えておこう。OB Setは、コードの見た目も良くないし、v15からの実装という新しめのコマンドながら、すぐに博物館行きになりそうだ。ちなみにOB Setでセットされたプロパティの内容は、ドット表記でも参照できるし、その逆も可能だが、混在はやめたほうが良い。たいした手間ではないのでドット表記に統一しておくことをおすすめする。