2013-03-18 10 views
13

私は、Androidアプリケーションでオブジェクトの階層をシリアライズおよびデシリアライズすることに成功しました。GSON逆シリアル化後のオブジェクト構築の完了

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

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

私がこれまで考えてきた方法:彼らは不完全な状態にしている場合

  • オブジェクトを持つがRuntimeException(またはそれ以上の適当なものを)投げます。つまり、初期化メソッドが呼び出されなかったときに何らかの作業を行うように求められた場合です。

  • シリアライズ可能なビットを別々のデータモデルオブジェクトに分けます。つまり、シリアル化できないものを取り出します。 GSONデシリアライゼーションの後、それらのデータオブジェクトを使用して自分の「実際の」オブジェクトを構築します。これは幾分GSONを使用する利便性を奪うようです。

  • GSON用のカスタムデシリアライザを作成して、これらのオブジェクトの特殊な作成を処理します。

答えて

5

として、私は通常、私のアプリケーションを設計するので、私はおそらくあなたが好む場合は、シリアライズ/デシリアライズされたする必要があります何が本当に単なる古いデータ、またはのPOJOで、第二のアプローチを取るだろう。私が望むことを行うためにシリアル化APIをカスタマイズ/設定する必要がある場合は、シリアル化されているものを単純化する傾向があるため、シリアル化APIに特別な設定は必要ありません。

したがって、私はより複雑なデータモデルがありますが、その一部はシリアル化/逆シリアル化されません。よりシンプルなPOJOのセットを概念的に別のデータモデルとして抽出し、シリアル化/デシリアライゼーション。これは実際には2つのデータモデル間のマッピングに特別なステップを必要としますが、それは通常は非常に簡単です。

第3のアプローチが望ましい場合は、the Instance Creator featureにも注意してください。これは、デシリアライズプロセスのカスタマイズに役立つもう1つの有用なフックです。

+0

多くのありがとうございます。 JSONファイルを新しいアプリケーションに読み込むと面倒になることがあります(JSONファイルが新しいアプリケーションに読み込まれると面倒になることがあります)クラス構造が変更されたvesion)。永続化の目的で、アプリケーションクラスを「モデル」クラスのツリーにマッピングすることは、このすべてを解決する良い方法のようです。愚かな質問ですが、実際の作業クラスとデータモデルクラスを区別するために使用する用語は何ですか? – Trevor

+0

ViewModel、PersistenceModel、SerializedModel、JsonModel、IntegrationModel、またはServiceModelなどがあります。 –

8

チェックアウトhttps://github.com/julman99/gson-fire

は、私はポスト直列化とポストデシリアライゼーションのようなケースを処理するためにGsonを拡張ライブラリ作られている

また、それは私がGsonで時間をかけて必要に応じてきた他の多くのクールな機能を持っています。

関連する問題