I have a set of computations that I am currently running on the Android. I want to move these computations from Android to a cloud (possibly google c2dm architecture or any other free service) but I dont have enough knowledge on how to use the c2dm. I will be sending a list of strings to the cloud, do lots of computations on the cloud and then return the rearranged list of strings to android.
Can anybody help me with this (as to how to connect the cloud with an android app)?
Thanks
Anks
You could use HTTP POST-GET requests to communicate with server, send and receive JSON/xml data.
EDIT that's almost enough to leverage client-server communication in your app.
http://developer.android.com/reference/java/net/HttpURLConnection.html
http://www.ibm.com/developerworks/opensource/library/x-android/
http://www.ibm.com/developerworks/xml/library/x-andbene1/
I am unsure what you mean by "google cloud".
One way to achieve this would be to use Google App Engine. It allows you to run server applications developed in Java/Python on Google's infrastructure.
What this means is that you can develop the server side yourself, and therefore implement any protocol you like to communicate with clients, that is, create your own web service.
As Mighter mentioned you could perform raw HTTP requests. However, there are a number of existing protocols for remote procedure call: SOAP, XML-RPC, etc..
I personally tend to like JSON-based protocols. It's easy to make your own implementation for that type of protocol, but you may be interested by this JSON-RPC library for Android, as an example.
Also check this other question: How to call a SOAP web service on Android
Once you'll have your web service ready, whether using SOAP, JSON-RPC or else, then you should be able to create a client, and expose the remote service calls through Java classes. If well designed, it could 1. feel as if you were calling methods on a local object, and 2. allow you to swap with a local implementation in case the network is unavailable.
I think it depends of how heavy your computations are, or how much computation power do you need. you can try to write a simple app engine server which handles post requests and return a JSON format answer. in case your computations are complex i would use google compute engine and install my custom stack.
in both cases you would need to write a server side to handle your data. if you use google app engine you can write it in java, python, php or go. if you use compute engine you can basically write it in any language that you can run on linux.
hope it helped!
Related
Is it possible / does it make sense to use an Android app as a "Producing client" for Apache Kafka?
Let's say my Android App need to capture and analyse reaction time data. Goal is to collect all data and show the average reaction time in real-time in the App.
The alternative is having an app server of some kind as an
intermediary that accepts messages from the android app and posts them to
Kafka, rather than having the app be a Kafka Producer on its own.
Even if it's possible, in my opinion it has some disadvantages.
In general I like clients to be as simple as possible to avoid maintenance issues. Instead I'd route all client requests through a REST API on my app server. The disadvantages are not related to Kafka, but are common problems of native clients.
Coupling
You're coupling the Android app closely to your messaging infrastructure. If you later decide that a Kafka solution is too much and Plain Old Java would be good enough, you'll first have to update the Android app and wait until enough users do an update.
Network issues + delivery guarantees
Kafka clients also require a direct connection to each of the brokers. Mobile clients can have very inconsistent/spotty network connectivity, making direct client access susceptible to dropped events and overall network connectivity issues.
Authentication
Probably you already have some kind of authentication in your app. You can also create authenticated connections to Kafka. So you'll have two authentication paths, whereas with an app server Kafka only needs to check if the requests are coming from the trusted app server, which means less implementation effort.
...
I think it would make lots of sense:
Kafka-clients.jar provide auto-reconnecting capability which is very useful when the phone is on a flaky internet connection
The Kafka-clients.jar is quite thin and does not include any of Kafka Server code (it doesn't even depend on Scala).
Unfortunately, it isn't compatible with Android just now: KAFKA-7025 . If you'd like to see this happen, please upvote the JIRA issue.
I believe that an Android Application can use a secured connection to a Kafka Broker cluster using SASL, for example. However, it must be done in coupling with any other communication, which can support synchronized keys rotation, which is initialized by any remote server with synchronization with the broker's cluster.
Any concrete instance of mobile application can listen to a concrete topic, and produce messages to a related topic, which is created when registering the instance using a REST server. Any deserializer verifies headers or Keys for a token, which are appointed using REST while registering on the same service. Custom encryption can be provided similarly.
Technically it is solvable. But what are the benefits, in front of using Firebase, for instance? Expenses I see from the start. Benefits???
Is it possible / does it make sense to use an Android app as a "Producing client" for Apache Kafka?
Let's say my Android App need to capture and analyse reaction time data. Goal is to collect all data and show the average reaction time in real-time in the App.
The alternative is having an app server of some kind as an
intermediary that accepts messages from the android app and posts them to
Kafka, rather than having the app be a Kafka Producer on its own.
Even if it's possible, in my opinion it has some disadvantages.
In general I like clients to be as simple as possible to avoid maintenance issues. Instead I'd route all client requests through a REST API on my app server. The disadvantages are not related to Kafka, but are common problems of native clients.
Coupling
You're coupling the Android app closely to your messaging infrastructure. If you later decide that a Kafka solution is too much and Plain Old Java would be good enough, you'll first have to update the Android app and wait until enough users do an update.
Network issues + delivery guarantees
Kafka clients also require a direct connection to each of the brokers. Mobile clients can have very inconsistent/spotty network connectivity, making direct client access susceptible to dropped events and overall network connectivity issues.
Authentication
Probably you already have some kind of authentication in your app. You can also create authenticated connections to Kafka. So you'll have two authentication paths, whereas with an app server Kafka only needs to check if the requests are coming from the trusted app server, which means less implementation effort.
...
I think it would make lots of sense:
Kafka-clients.jar provide auto-reconnecting capability which is very useful when the phone is on a flaky internet connection
The Kafka-clients.jar is quite thin and does not include any of Kafka Server code (it doesn't even depend on Scala).
Unfortunately, it isn't compatible with Android just now: KAFKA-7025 . If you'd like to see this happen, please upvote the JIRA issue.
I believe that an Android Application can use a secured connection to a Kafka Broker cluster using SASL, for example. However, it must be done in coupling with any other communication, which can support synchronized keys rotation, which is initialized by any remote server with synchronization with the broker's cluster.
Any concrete instance of mobile application can listen to a concrete topic, and produce messages to a related topic, which is created when registering the instance using a REST server. Any deserializer verifies headers or Keys for a token, which are appointed using REST while registering on the same service. Custom encryption can be provided similarly.
Technically it is solvable. But what are the benefits, in front of using Firebase, for instance? Expenses I see from the start. Benefits???
I have a website and i need to make an app on android and iphone and the app has to communicate with the server,similar to facebook app.Do i need web services like SOAP for this.I read their documentation but how necessary are they and what is their main purpose? Can I do the same without using web services? my website is in codeigniter
If you need to implement web services for your app, I recommend taking a look at CodeIgniter Rest Server. This provides an easy way to implement REST web services, which are lighter weight, easier to work with, and more flexibile than SOAP.
Benefits of using a Web Service:
1 - Usability: You can develop Android and iOS apps, and both of them can use the same Web Service. Other smart phone platforms can also be developed later and use the same Web Service.
2 - Flexibility: For instance, you need to have a mechanism to talk with the database. You can implement the database transaction in your Web Service. (I have experience in using hibernate) You do not have to create a database configuration in every smart phone app. If you decide to change your database, then you just need to modify your database configuration in the Web Service - nothing changes on the client sides.
3 - Security: It is not a good mechanism to connect directly from a Mobile app to your database server. You need to have some kind of Authentication mechanism that can be provided by a Web Service.
Which kind of Web Service is better? I agree with #Justin that REST is a good approach since it is lighter, simpler to implement and more flexible.
SOAP can be a better approach when Security is the most important thing, for instance in certain enterprise scenarios. REST vs. SOAP
Are webservices necessary? Well the correct answer to your question is it depends on the app. Most apps that connect to a server to get some information use web services. However, no you don't need to write your own web services. Increasingly people are using platforms like agigee
http://apigee.com/about/products/usergrid/
So no you would not need to write your own api if you used usergrid, but you might want to if you wanted to keep the data all within your own infrastructure.
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.