John and Bensie -- thanks for the excellent pointers!
On Mon, Mar 10, 2014 at 9:26 PM, James Miller <[email protected]> wrote: > Hey Chris, > > What John said :) > > You definitely want to put an API layer between your client apps and > Mongo. There is really nothing positive that comes from a direct connection > to Mongo -- client libraries are limited, authentication is way too close > to the data, and your client apps will depend on an unchangeable database > schema. On the efficiency argument, you're uploading images so we're > already in the hundreds of milliseconds or seconds, if it's another 50ms > running through your application stack is going to be negligible. > > It's very straight forward to POST images using multipart/form-data on > iOS, Android, and pretty much any other client you can think of -- you can > even fire upload requests at an API with a simple curl command. > > For specific libraries on Android, Square has some pretty awesome stuff: > http://square.github.io/retrofit/ > http://square.github.io/okhttp/ > http://square.github.io/picasso/ > > For iOS, look no further than AFNetworking: > http://afnetworking.com/ > > Here's a gist of how I handle multipart photo uploads in a Sinatra API > (uses Paperclip in the model). With Rails you may be able to assign the > multipart parameter directly without the struct -- not sure but in any case > it's pretty straight-forward to grab the relevant data from the request. > https://gist.github.com/bensie/9479467 > > James > > > On Mon, Mar 10, 2014 at 8:31 PM, John Lynch <[email protected]>wrote: > >> Chris, >> >> I think you will be fine using multipart/form-data with >> application/octet-stream to upload the binary data from the phone to the >> web service. There is no need to base64 encode anything, that would just >> increase the size and gain you nothing. You will probably need to manually >> construct your multipart payload (which could include the image plus any >> JSON data you need) on the phone, and then manually deconstruct it on the >> Rails end. >> >> Also, you are 100% correct, the only sane way to do this is via HTTP to >> an app server. You obviously can't have phones making direct connections >> to the mongo database. :) >> >> >> -- >> Regards, >> >> John Lynch >> [email protected] >> >> >> >> On Mon, Mar 10, 2014 at 7:48 PM, Chris McCann <[email protected]>wrote: >> >>> I'm beginning to research how to put together a Rails RESTful API and >>> app to handle requests from an Android app. >>> >>> We currently have a prototype Android app in which the author connects >>> directly to a MongoDB hosted at mongolab.com via the Mongo Android >>> driver using BSON. This has worked fine for the initial proof-of-concept >>> effort to push data to the DB but isn't what we need going forward. >>> >>> For our next phase of development I'd like to build a RESTful Rails API >>> that the Android app can use to push data and get a response back. The >>> Rails app will also allow display and querying the data. >>> >>> In addition to simple JSON text we'd like to be able to push an image >>> taken by the camera on the Android device. The image is currently sent as >>> a MongoDB binary data type. >>> >>> I've done a fair amount of Googling on the topic but am curious what the >>> community has to say on this subject. The original demo author is >>> completely wrapped around the axle about the "efficiency" of sending the >>> image data back over HTTP, insisting that it must be done the way we >>> currently do it, as BSON over whatever type of connection the Mongo driver >>> creates (he is neither a web developer nor a Java programmer and had not >>> seen Rails before I built the demo backend last week). Is gzipped >>> Base64-encoded text just as efficient for hauling the images? >>> >>> The API will initially just support Android with iOS coming shortly >>> thereafter. The choice of MongoDB was purely for expediency (and before I >>> arrived on the scene) and will most likely change. The mobile apps will be >>> ignorant of the backend persistence mechanism so I can design it however I >>> like. >>> >>> Does anyone have opinions on the most appropriate way to bring the >>> images back via the API? From the perspective of the Android app in terms >>> of bandwidth, speed, and power consumption, is one way better than another? >>> >>> Are there any Rails API and Android gotchas I should be aware of? I'm >>> not an Android dev (yet) but I plan to learn enough to mock this up on my >>> own. Are there any Android references or tutorials that folks find >>> particularly good? >>> >>> Many thanks in advance. >>> >>> Chris >>> >>> >>> -- >>> -- >>> SD Ruby mailing list >>> [email protected] >>> http://groups.google.com/group/sdruby >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "SD Ruby" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> -- >> SD Ruby mailing list >> [email protected] >> http://groups.google.com/group/sdruby >> --- >> You received this message because you are subscribed to the Google Groups >> "SD Ruby" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby > --- > You received this message because you are subscribed to a topic in the > Google Groups "SD Ruby" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sdruby/MPeVOqhCNz8/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
