Meaningless Drivel is fun!*
The moose likes Web Services and the fly likes Few questions on web services + local storage for Android app Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "Few questions on web services + local storage for Android app" Watch "Few questions on web services + local storage for Android app" New topic
Author

Few questions on web services + local storage for Android app

James Gibbs
Greenhorn

Joined: Feb 21, 2013
Posts: 29

I'm building a new android app which will display a list of custom objects which will be comprised of a small image (50kb(ish)) and a few text fields. So looking at under 100kB per object/item, 50-200 items in total.

The item will be updated every few days with new items and any modifications to older ones. Obviously these will sit on a server of mine somewhere for the app to poll manually + use google cloud messenger to update the app when needed.

Now my fist question is what's the best web service to use in this scenario? XML? SOAP? I've only had experience of XML so far, but I'm wondering if there might be something better out there. Obviously I want to respect users bandwidth while making the app responsive.

On the device itself what is going to be the best way of storing this data, XML? MySQL?

Also say if I have 200 items at 100kb each, so 20MB, I assume storing the entire collection of objects iin memory is going to be out the question?
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41106
    
  45
SOAP has become unfashionable due to its overhead. Consider using a RESTful WS that transports JSON (Android has a JSOn API built in).

Storing it in memory is tricky, as Android may decide to kill your app at any given moment. Either use the built in SQLite DB, or store the raw JSON in internal or external storage: http://developer.android.com/guide/topics/data/data-storage.html. The latter is what I would do.


Ping & DNS - my free Android networking tools app
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4167
    
  21

Just to add an alternative to the great advice Ulf gave:

Have a look at MQTT, a very lightweight messaging protocol developed by IBM (but with a very good open source implementation). It is an alternative to the Google Messaging System to push messages to the phone, but does not lock you into the Google account/Android platform. It also allows a fairly large payload so you could send your data as the message to reduce overall network traffic. The cycle goes from:
1) Source->GMS: Signal new data.
2) GMS->Phone: You have new data.
3) Phone->Source: Give me new data.
4) Source->Phone: Here is your new data.

And becomes:
1) Source->MQTT: Here is new data.
2) MQTT->Phone: Here is new data.

It also is platform agnostic, so you have an Android app today, but if you later need to use iPhone/iPad or Windows Phone 8, or whatever, you can use the same protocol. I am not sure if it is useful in your app, but you should give it a try.


Steve
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38003
    
  22
Moving discussion as too difficult for “beginning”
James Gibbs
Greenhorn

Joined: Feb 21, 2013
Posts: 29

SOAP has become unfashionable due to its overhead. Consider using a RESTful WS that transports JSON (Android has a JSOn API built in).

Storing it in memory is tricky, as Android may decide to kill your app at any given moment. Either use the built in SQLite DB, or store the raw JSON in internal or external storage: http://developer.android.com/guide/topics/data/data-storage.html. The latter is what I would do.


Thanks that's a great response. Would building this RESTful service in the Play! framework be a good way to go?

I'm guessing you think JSON would be better over SQLite in my case for reduced complexity?

Steve, thanks for the heads up on MQTT, I've taken a look at it, I still might go the google route for now as I'm still a beginner and I'm guessing they'll be more support/docs for their implementation. But MQTT might be useful to me in future
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41106
    
  45
James Gibbs wrote:Would building this RESTful service in the Play! framework be a good way to go?

I can't comment on that. Personally, I use Jersey, and I've never taken a long enough look at Play to compare it with other frameworks.

I'm guessing you think JSON would be better over SQLite in my case for reduced complexity?

That would be my gut feeling, but it really depends on what you're doing with the data in the app. There are tradeoffs with either choice.
James Gibbs
Greenhorn

Joined: Feb 21, 2013
Posts: 29

Yeah I've taken a look at Jersey aswell, seems there's a lot of overlap between play and jersey. Think I'll have to try them both at some stage to get a good feel for them. So then it looks like it'll be JSON and Play! but im still undecided on how to store the data on Android and the Play server.

The web service will need to basically occasionally allow me to add/modify/delete items/objects. 99% of the time it'll either be idle or supplying the Android app with new objects.

On the Android side the app will most of the time be displaying selections of the items/objects and downloading new objects when required. There's only a few extra fields the app will create, such as if the item has already been viewed, favorited etc

I'm guessing my choices are either object serialization to text file(s) or a DB of some kind, maybe NoSQL on the web service and SQLite on Android....really don't know what to go for

Update: After hours of research I've come to the conclusion that serializing the JSON to disk on Android is going to be best bet. However I still don't know what to use for web service side?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Few questions on web services + local storage for Android app
 
Similar Threads
Database vs filesystem which one is best for storing images?
Data storage
have all methods in same interface or spread out in static helper classes?
Threading Models in Android: Loopers, Handlers, Message Queues.
performance increase - move to ear - suggestions