How to store android.location.Address (or Location) to DB

976 views
Skip to first unread message

Alex Ciarlillo

unread,
Apr 17, 2011, 3:20:33 PM4/17/11
to ORMLite Users
Looking to store android.location.Address to a SQLite database using
ORMLite. I know ORMLite can persist Serializable items (as a BLOB I
believe) but I think the only way to get something Serializable from
an Address is to write it into a Parcel. Then I took a look at Parcel
here: http://developer.android.com/reference/android/os/Parcel.html
and it says it should not be used for general purpose Serialization
mechanism. So I am just wondering what the best practice for doing
this would be. I do not want to store the Address in contacts,
strictly in my SQLite database. I am currently doing this with my own
Address class (very simple) but would prefer to use the built in
Android class for this.

thanks

jc

unread,
Apr 18, 2011, 10:38:57 AM4/18/11
to ORMLite Users
> ...I am currently doing this with my own
> Address class (very simple) but would prefer to use the built in
> Android class for this.
>
Using Serialization of objects that are defined outside of your
control opens your app up to issues if those objects are ever
changed. It's not really worth the risk. Using your own Address
object will be better off over time and you can choose how to manage
it. I would recommend just storing it to your own table, but if you
really have a reason for using Serializable then you need to use
"@DatabaseField(dataType=DataType.SERIALIZABLE)" for whatever field is
used to define your object.

Alex Ciarlillo

unread,
Apr 18, 2011, 10:52:46 AM4/18/11
to ORMLite Users
Okay thanks. I guess I will stick with what I'm doing for now. I was
just hoping to be able to use the built in android data types wherever
possible. I am working the the GPS and maps, so I was hoping to avoid
converting my 'custom' address class to the appropriate android
equivalent. Just seemed like an unnecessary step.

I also tried defining the data table config programmatically (as
opposed to with annotations), but since android.location.Address
actually extends Parcelable, there are no defined fields in the class
to base the table on. My general idea looked something like:

private DatabaseTableConfig<Address> buildAddressTableConfig() {
ArrayList<DatabaseFieldConfig> fieldConfigs = new
ArrayList<DatabaseFieldConfig>();

Field[] fields = Address.class.getFields();

for(int i = 0; i < fields.length; i++) {
// get the field name and add a new field config to the array
}

DatabaseTableConfig<Address> tableConfig = new
DatabaseTableConfig<Address>(Address.class, fieldConfigs);
return tableConfig;
}

But that's a no go. It may be possible with
Parcelable.describeContents(), but this has been a big enough headache
and I need to move on.

Thanks for the input

Gray Watson

unread,
Apr 18, 2011, 12:53:38 PM4/18/11
to ormlit...@googlegroups.com
I second jc's warnings about Serializable in general although as long as the serialized-id is not changed then future compatibility usually works.

However, I'd like to comment on how to do by-hand configuration of fields. You don't have to use reflection. You can just list the name of the field:

http://ormlite.com/docs/class-config

I've just added a String constructor for the DatabaseFieldConfig which will make it easier to wire in the next version.
gray

Alex Ciarlillo

unread,
Apr 18, 2011, 1:27:14 PM4/18/11
to ormlit...@googlegroups.com
Yes I see now that reflection was the wrong approach here. I looked at the source for Address (http://hi-android.info/src/android/location/Address.java.html) and found the field names so I may give this another try. There are a few other inherent issues such as the fact that the address lines are stored as a HashMap<String, Int> and there is a Bundle (i.e. HashMap<String, Object>) for extras. These are probably not insurmountable issues, but for now I think trying to wiring all this up will add too much complexity to my app which is still evolving and undergoing frequent and wild refactoring. I am happy to know that this would be the preferred way of doing this, which is the answer I set out for originally, but for now I think I will stick with simpler approach of using my own class.

Thanks for the input and help on this. If I do get around to wiring this up to work properly I will definitely post an example to help others. I'm sure I can't be the only one who would like to a store a native Android class in a database through an orm.

Just so I'm on the right page here... the HashMap could be done using a Foreign Collection correct?

For the Bundle (http://hi-android.info/src/android/os/Bundle.java.html) I would have to do a by-hand configuration for Bundle and use it as a Foreign Object and then define a Foreign Collection for its HashMap. Just not sure if it would interfere with the Parcel/unparcel stuff of the Bundle.

Seems like a lot of extra tables and overhead... but not impossible I guess.
Reply all
Reply to author
Forward
0 new messages