I'm new to Android, but I'm ultimately hoping to create a social networking app. I'm trying to figure out the best way to store user data (profile field responses, etc). I'm planning to use Google App Engine for data storage. Very generally, how do I take data gathered from, for example, an "Edit Profile" page and (a) store it in the GAE datastore and (b) make it show on the user's profile? For example, what methods would I use, and how would I set up user data? Also, I know there are more user-friendly interfaces for GAE datastore like Objectify and Slim3; can these be used with Android? I apologize if these are general questions, but it would be great if you could point me in the right direction!
GAE is a Server side platform while Android is a client side platform. Both of them while using Java as their base language have different SDKs. So you cannot mix them.
The approach that you will need to take is the following:
Build a simple REST Web Services layer for your Server side application that is hosted on GAE.
The Android client will make a REST call to send and get data from the Server.
On the Server side Java application that you host in App Engine, you can use the Datastore API. If you want to be a bit more productive you can look at libraries like Objectify.
On Android, I suggest that if you are going to store preferences/profile details for the user, you should use the following:
a) Use Android Preferences. This will save the preferences data on the device itself and will not need network calls to happen between the device and server just for the sake of getting preferences.
b) Any data that you really need to save on the Server, you should as mentioned earlier make a REST Web Server in GAE and invoke it via HTTP Networking on Android.
Hope this helps.
Related
I need to create a Rails app which in the future will need to share the same database with a native app.
As I am still quite inexperienced I would like to understand which way is the best to have the 2 app share the same database, in this case I will use postgresql.
I'm thinking of using postgrest for it but I'm unsure if there are any better/ faster ways.
which way is the best to have the 2 app share the same database
The best way is to not share database at all. Mobile app does NOT talk to database directly. Instead, it should talk to an api server, which will provide needed data and perform appropriate checks (user credentials, etc.)
The API server may be implemented as part of the same rails app or a separate app.
Another way might be to expose a read replica for your database to the mobile which can access the data directly through it via the API calls.
There are lots of options, depending on what you are trying to achieve with the web app. You can look into BAAS's such as Firebase or similar products. However, if you are already using rails, you try the new Rails 5 API mode, where all your controllers and models are preformatted to serve JSON making it slightly easier to get your API up and running for your native app.
An API (to clarify your understanding based on your comments), is a layer that will deal with creating, updating, editing, and deleting things in your database. You will have to define it using your own code (or rails generators if your app is very simple). This layer is so you can insert business logic before the database operation is performed based on the request sent from your app.
I am trying to create an android application in which an user will pretty save some data in database-like user data, photos and also be able to retrieve.
But I am clueless how to set up a server, connect to some database etc.
Can somebody help me point to right resources for end-to-end installation of server, database, and its interaction with the android application
Just set up a basic server that works over HTTP, and use HTTP libraries for android to make requests and handle results in the device. There are plenty of technologies with which you could make the server, just google building REST API with PHP/.net/java (whichever language you are comfortable with).
If you are mobile app developer and want to create server-client app then better use any back-end service rather than implementing new by own. Some most advanced and simple to use services are Parse and Firebase , BaasBox also there are many more.
And the plus point is this services free of cost until you have very large users.
I am trying to create an Android app similar to google latitude and I am not sure what to use in terms of databases. I thought of using SQLite (which is serverless), but I still need a server in order to make two clients communicate to each other. I am really new with connecting an app with a server or a database, so any help would be appreciated.
I dont believe there is a way to remote connect to any database from Android (could be wrong, but when I check it wasnt possible). Your going to have to use SQLite for your local, and i recommend using MySQL for the server side, and use JSON to retrieve information via a service page.
OK, what you want to do is a client-server architecture. You need to think about what kind of data you want to store, and where to do that.
Obviously, on the server side, you need to store data. It will depends what your server is, and what technology you use for it. This question has nothing to do with Android, as you'll probably communicate to your server using HTTP or another protocol that would allow it to communicate to your android app (the client) and maybe later on, to different kind of clients (web app, iOS, etc.). So you can use any database technology, Oracle, MySQL, Postgres, whatever. You can even build your server application using Microsoft .NET technology, or anything else. You're not tied to Java / Android (although my personal technology stack of choice would probably be a Jetty HTTP server, Oracle database or MySQL if you want lighter, and Java of course).
On the client side, you may also want some data storage, and in this case it depends on the size and complexity of what you want to store. For simple key-value pairs, use SharedPreferences. For more complex data structures, SQLite is your technology of choice.
I need to build Android application using Java which is able to send request to read or write some data to "database" or similar data store on google web server (using GWT technology).
Android app should be able to authenticate user with Google Account, send request to server to add data to database on server, receive data form server.
I would like to know what is the best approach and architecture I should use? What mechanism should I use to get data response over network (RPC, GET request)? What should I put on server side (servlet, ...) ?
There is example how to build gwt app: which run 1. javascript in browser 2. servlet, service, serviceImpl, serviceAcynch, etc... I think this is no use for my app because I need to directly get and send data to/from server.
I need to have data exchange with GWT server to get/update coordinates for my Google MapView. Therefore I need to use data exchange mechanism between android client app and GWT.
Why do I need this on android? I have to be able to get GPS position of android device and update data with web server, then display my android device position on map. I need GWT to store, put, return position data (for example to show visited locations). Should it be build as Android native app? How can I update, get data from GWT server?
You've asked a general question. The best I can do is give you a general answer. For stuff like this, I like to build up a REST framework. REST is a robust and resilient paradigm which is something you need when developing mobile applications, the network connection could go out at any time. Using REST, you can just use standard HttpRequests to query the server. Responding to the requests server side is as simple as processing the HttpRequests. On Android, the HttpURLConnection class is perfect for this kind of stuff. If you want a rather complex but comprehensive example of all this, you can take a look at the SampleSyncAdapter example in the android SDK. Also, you might find this Google IO video interesting. It's one of my favorites.
I'm planning on constructing a large application. It will have a browser based interface along with a mobile application interface (iOS, Android, blackberry).
I would like to be able to push data from the server onto these interfaces, and there will be a lot of data being sent from the mobile apps back to the server. So my question is what kind of server am I looking to build.
I'm a PHP developer mainly, though I can write in Java and have dabbled in others. I'm fine with learning a new language. My thoughts as a PHP developer is that I could just build a PHP application and use it's API to power the other interfaces.
However there will be a lot of data moving around and I don't feel like PHP would be the best base for this really. So I'm exploring alternatives. Any thoughts on where to start with this?
you can use a framework like Rhomobile's Rhodes that generates your browser based clients and they also offer a server component: http://rhomobile.com/products/rhosync/
Common practice would be to separate out the backend functionality between different servers.
Server 1: serve up your static content
Server 2: serve up your dynamically generated content (things based on queries that require IO such as DB interaction
Server 3: dedicated realtime infrastructure for the realtime push functionality
Server 1 & 2 could probably be the same server for now but I'd recommend having a dedicated realtime server. Communication between servers is normally done with some sort of message queue although web service calls are also an option.
My area of interest is realtime push so here's a bit more information on that. If you want to stick with PHP there's the phpwebsocket project. If you want to look at Java then there's [WaterSpout}(http://www.spoutserver.com/), jwebsocket and Jetty which has been around for a while and is (or was the last time I checked) used by the Twitter Streaming API.
There are more options for the realtime component of your solution on this Realtime technologies guide which I'm maintaining.