17

GSON を使用して、Android アプリケーションでオブジェクトの階層をシリアル化および逆シリアル化することに成功しました。

transientシリアル化されるオブジェクトの一部には、出力 JSON 文字列の一部としてシリアル化したくないオブジェクトへの参照であるため、マークする必要がある (または別の GSON アノテーションを使用してシリアル化されないようにする) 必要があるメンバーがあります。これらの参照は、別の方法で個別に構築する必要があるオブジェクトへの参照です。

構造がデシリアライズされて Java オブジェクトに戻されると、ある時点でそれらの参照を埋める必要があります。おそらく一連の型メソッドを使用することでこれを簡単に行うことができますsetXXX()が、それが行われるまで、それらのオブジェクトは不完全な状態になります。したがって、私が疑問に思っているのは、これに対するより堅牢なアプローチがあるかどうかです。

私がこれまでに考えた方法：

  1. RuntimeExceptionオブジェクトが不完全な状態にある場合は、オブジェクトに (またはより適切なもの) をスローさせます。つまり、初期化メソッドが呼び出されなかったときに何らかの作業を行うように求められた場合です。

  2. シリアル化可能なビットを個別のデータ モデル オブジェクトに分離します。つまり、シリアライズできないものを取り出す。GSON デシリアライゼーションの後、構成内のデータ オブジェクトを使用して「実際の」オブジェクトを構築します。これは、GSON を使用する利便性を多少損なうようです。

  3. これらのオブジェクトの特別な作成を処理するために、GSON 用のカスタム デシリアライザーを記述します。

4

2 に答える 2

11

Check out https://github.com/julman99/gson-fire

It's a library I made that extends Gson to handle cases like Post-serialization and Post-deserialization

Also it has many other cool features that I've needed over time with Gson.

于 2014-02-12T18:38:53.010 に答える
6

通常、アプリケーションを設計するとき、シリアル化/逆シリアル化する必要があるものは、実際には単純な古いデータ、または必要に応じて POJO であるため、2 番目のアプローチを取る可能性があります。シリアライゼーション API をカスタマイズ/構成して自分のやりたいことを実行する必要がある場合は、シリアライズ対象を単純化する傾向があるため、シリアライゼーション API は追加の構成を必要としません。

したがって、より複雑なデータ モデルがあり、その一部がシリアライズ/デシリアライズされない場合は、そこから単純な POJO のセットを、シリアライゼーション/デシリアライゼーションに参加する概念的に分離されたデータ モデルとして抽出します。この場合、実際には 2 つのデータ モデル間でマッピングするための追加の手順が必要になりますが、これも通常は非常に簡単です。

3 番目のアプローチが優先される場合は、Instance Creator 機能にも注意してください。これは、逆シリアル化プロセスをカスタマイズするための別の便利なフックを提供できるためです。

于 2013-04-03T06:02:16.907 に答える