How to upload an image from an Android Client to the datastore and get it back (or send it to another client)?

333 views
Skip to first unread message

Aaron Villalpando

unread,
Jan 5, 2014, 5:49:42 PM1/5/14
to google-a...@googlegroups.com

I've been doing GAE tutorials the entire week and haven't been able to send an image to the datastore using google cloud endpoints and retrieve it (maybe with modifications done serverside).


Basically I would like to create an asynchronous multiplayer game using GAE and Android where Person A creates an image, then sends it to the server, server sends it to Person B, who edits the image, and then Person B sends it back to A (and so on).


Do you guys have any recommendations on how to go about implementing this?

I tried looking at the tictactoe sample to learn more about the relationship between the backend and the android client but I haven't been able to figure out how to do something like I described. Not only that, but the tutorial
seems to be all over the place for beginners like me. If they explained that tictactoe sample like they did with the Mobile Assistant Tutorial it would be amazing.


If any of you have any helpful, very simple functional samples using GAE for android in java relating to this type of problem (image sharing through GAE using Android) it would be extremely helpful.

Thank you.

Kristopher Giesing

unread,
Jan 7, 2014, 2:55:45 PM1/7/14
to google-a...@googlegroups.com
Yes, it's possible to do this with Google App Engine.  There are a lot of options; you'll need to make some design decisions to start, and then the documentation can help you with the implementation.

First, you need to decide whether the game state should be stored on the server or transient.  That determines whether you need to use the data store.  Most likely you'll want the game state to be stored, but I don't know your specific requirements so I could be mistaken.  Assuming you want to use the data store I *highly* recommend you use Objectify rather than the built-in JPA or JDO support in App Engine.  Objectify has a lower start up cost so is better for overall performance, and its APIs are tailored to GAE so you avoid some of the weirdness in JDO/JPA.

In addition to the game state it sounds like you want to store images.  Storing image data in the data store might not work for you depending on the image size; if that's the case you may want to look into the Blobstore APIs.  I have not personally used them so I don't have much to say there.

Next, you need to decide how players submit moves, and how they will be informed of moves by other players.  Google's documentation suggests using the Channel APIs, which are essentially a wrapper around WebSocket.  There are some significant limitations to Channel, though, not least of which is that the client has to be JavaScript (for Android, this means using an embedded WebView).  Channel is also designed to be one-way (server to client); for client to server messages Google suggests using HTTP POST requests.

An alternative to Channel is to use HTTP requests in both directions: POST for submitting moves, and GET (in a polling sense) to retrieve moves.  GET polling can be less friendly to network bandwidth and battery though.

In my own (iOS) game I decided to use raw WebSockets instead and create my own wrapper, foregoing the Channel APIs.  There are WebSocket libraries for both iOS and Android (though I don't have any experience with the Android ones) - this means your client doesn't have to be a WebView.  In addition, WebSocket can be used for bidirectional messaging, meaning you can use one transport for both move submission and notification.  However, if you're using the Blobstore to store data, you may want to use HTTP requests to post moves anyway, since (as I understand it) the Blobstore already has an HTTP request interface.  Again though, I haven't used Blobstore myself, so YMMV.

Finally, a comment on Google cloud endpoints.  The cloud endpoints system is not something I've used, but from what I can tell, it is a code generation system designed to make it easier to develop both the client and server together using a single API definition (somewhat like IDL).  If that's the case, then there's nothing you can do with cloud endpoints that you couldn't do by hand.  I would recommend designing the system by looking at the underlying capabilities of App Engine and seeing which ones meet your needs, and then consider cloud endpoints as a kind of "syntactic sugar" that can help with the implementation.

Good luck,

- Kris

Jeff Schnitzer

unread,
Jan 7, 2014, 3:06:05 PM1/7/14
to Google App Engine
Keep in mind that GAE datastore entities are limited to 1MB in size,
which might be a significant problem for your images. If so, you'll
want to use the blobstore/google cloud storage instead and track the
metadata in the datastore.

Jeff
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengi...@googlegroups.com.
> To post to this group, send email to google-a...@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-appengine.
> For more options, visit https://groups.google.com/groups/opt_out.

Atakan Sergio

unread,
Feb 1, 2014, 4:07:36 PM2/1/14
to google-a...@googlegroups.com
Hi Aaron,
Did you find any samples and were you able to make it work?
I appreciate if you can share a sample code.
Reply all
Reply to author
Forward
0 new messages