I'm building a data management system. In the end it will be sending SQLite data via http post method to an instance. I will not be building this web datadase and it wont be ready for some time. However I would like to continue my production of the app and get the http post methods set up correctly.
Is there a way to test http methods without already having a receiving client already set up?
Maybe a public client exists for this purpose?
I want to continue production (and testing) to the point so that when the web database is finally built all I need to do is essentially plug in the new url in my code. Is there anyway I can do that?
Thanks
You can ask it google
Example Henry's HTTP Post Dumping Server.
Stub the posting class, implementing an interface. Use it directly, or use something like Guice to inject it.
You can always set up a dev DB service, and should, but a stub may be sufficient for most of your dev.
Related
I'm very new to this subject.
I try to build an application server that will interact with clients using Android.
Just before I dive into this field and learn everything, I want to know if there is a proof the design will work.
I build on the fact that the server I want to build can function as well as a client.
For example If a user ask the application server for some data, that my server can POST as a client to another server to get the data to be processed and then handed to the user. Can this work?
again, sorry this is very basic, but I didn't find the specific answer to this and I wanted to make sure I'm not building something "in the air".
All the things you want to do are achievable. It is no problem to let the server make requests to another API to provide the answers back to the client if you want to do sth like this:
Client:
myServer.getWeatherData();
MyServer
public List<WeatherData> getWeatherData() {
//call to local weather station api
}
I have to implement a client-server architecture where there are many android client located at different places querying the application server (running all the time (24x7)) and which will do task accordingly and reply to clients. But I don't know what exactly application server is and how to implement it and what is easiest and quickest way to implement this. I am running out of time that is why posting this question otherwise I would have gone through lot of tutorials instead.
The server code is to be written in php/c#/java.
Any quick help is highly appreciated.
You may have look at Google App Engine its easy to setup, hosted on google environment. Which might fulfill your need. In this case you don't need to buy hosting plans etc. etc. You will get yourappname.appspot.com URL to use app server.
Hope it helps!
Note:
Appengine supports Python and Java
You can implement it by knowing how the application servers work.
First of all, you should create a class that implements the HttpHandler, in handle method you can get header and body of the message.
Secondly, you should choose how to handle the request in HttpHandler. One possible approach can be using of ThreadPoolTaskExecutor or SimpleAsyncTaskExecutor or any task executors.
Finally, you should prepare the response messsage with exchange.getResponseHeaders() and exchange.getResponseBody()
I am just beginning to look at using json and a rest client setup to connect with a rest server. Is there a server that can be accessed just so I can try my code and see what is returned.
Blizzard just opened up their API for JSON using HTTP. So it's probably really close to what you're looking for, and it's got potentially LOT of interesting data to play with, even if you don't play the game.
http://blizzard.github.com/api-wow-docs/
Note, you may be limited how much you can use it. But for a simple app and testing, this should not be a problem.
I'm writing an Android app which sometimes needs to request data through HTTP from a REST API. I'm using the Apache DefaultHttpClient for performing requests. Is there a way to write tests for this app and "replace" DefaultHttpClient's response when running the tests so that test results are always consistent?
As an example of the things I'd like to test, one of the web services I'm accessing takes a string and performs a text search, returning a paged list of objects. I need to test the cases where the list is empty, the list fits in the first page, or the list is larger than a page and the app needs to make several requests to get the complete list.
I'm not the developer of this web API nor can modify its responses, so I can't change what it returns. For the above example, if I want to test the case where the list returned is empty, I could just search for a string which I'm sure won't return any results, but the other two cases are harder because what the service can return is always changing.
I think ideally I would have a way to get a modified DefaultHttpClient when running tests, that returns a hardcoded result for requests to a given URL instead of actually doing the network request. This way I would always get consistent results independently of the real web service's response.
I'm currently using Robotium for testing but I'm open to using other tools too.
Yes, you can definitely "fake" responses when using the HttpClient framework. It's quite convoluted, and I will have to leave most of the details up to you, but I will give you a quick overview:
Implement ClientHttpRequestFactory, mainly so you can override the createRequest() method so you can...
Return your custom implementation of ClientHttpRequest, in which you can override the execute() method so you can ...
Return your custom implementation of ClientHttpResponse in which you will finally be able to return your fake response data, e.g. getBody() can return the content of a file, you can hardcode the headers in getHeaders(), etc.
The rest is figuring out how to best tie all these shenanigans to your service layer.
You might give Charles a try for something like this. Sorta a non-code solution.
http://www.charlesproxy.com/
I use the Charles' reverse proxies and the map local tool for things like this.
What you do is point your request at your local box on the reverse proxy port. Charles in turn can be configured to provide a static hard-coded flat file but to your app it looks like a 100% genuine web service response.
There are lots of other cool things you can do with Charles - watch traffic from your android app to and from your server and breakpoints (which allows you to tweak requests and responses before they are sent and received). Definitely worth checking out.
Another option is to use Dependency Injection so that you can change the HttpClient when running the tests. Check out Guice if you are interested.
I'm guessing you are interested in writing functional tests using the standard Android Junit testing framework. So you could just implement the parts of the API you are using on your own webserver and point at that server when running your tests.
If you'd prefer your tests to be self-contained, you could implement an Http server that runs on the device. Examples of using the Http server available in the Android class library are here and here.
I'd like to add the ability for my android app to save changes to data (stored in its SQLite database) to a web server. The upload will be via HTTP POST, using JSON in the body of the request to describe the changes.
I'm wondering if I should use an android Service for this. I'd like the user to be able to continue interacting with the app while it's generating the JSON, making the call to the server, and waiting for the server to complete its work and return a response.
Thanks much!
Even better would be an IntentService
Edit: Now that the compatibility package is out I think the new Loader class may be the best option, possibly using the ASyncTask version or a variation of it.
Yes it is a very good idea to move all the webservice code into a service. The Google IO talk Developing Android REST client applications talks about many reasons why this is a good idea. It also covers other important considerations which relate to your problem which is effectively syncing your database to the cloud.