Android Loopj AndroidAsyncHttp mocking - android

is there are any way to mock Loopj AndroidAsyncHttp responses?
I am developing application which depends on REST API, but API is not ready yet and I want to develop application independently from API. Retrofit has a lot of mock implementations, but I was not able to find any solutions for AndroidAsyncHttp. Is there are any way?
I tried to send success message to handler on request creation handler.sendSuccessMessage(200, new Header[1], new byte[1]); , but onSuccess or something else is not called.

As example, you may create on any hosting php file with responsing json.
Or you can use my template for this cases http://so.five-dots.ru/api-test.php
Make responsing on this address and implements your logic. Then RESTfull API backend service will be ready, you can replace adresses on real and getting responseBody will reqirement data.

Related

Verify http requests made by android app while running espresso

While running UI Espesso tests I would like to also verify if the app is making correct http requests (e.g triggered by a button press). Currently using OkHttpClient client to make the requests.
Did you try something? I like to use Wiremock to mock http requests and check that the app have done the correct request. You must use the standalone version or you will get some issues with HttpClient.
For more information see http://wiremock.org/index.html

App Engine endpoint with Retrofit

Would like to use Retrofit for handling network requests between Android Client and GAE endpoints.
GAE endpoints give Client/Server endpoint libraries to handle all the networking and also Oauth2 authentication which is nice.
Retrofit helps well for asynchronous call, cancellation, parallel calls...so is better than android client asynctask.
So can this Retrofit lib be configured with Appengine GAE endpoints or need to go through normal GAE servlet?
Just to clarify my question and make answers clear for any who read this :
I had for my App :
Client side : cloud endpoint library generated by google plug in for eclipse
Back end side GAE : different API with methods coded in JPA such as :
#ApiMethod(name = "insertMyShareItem")
public ShareItemData insertMyShareItemData(ShareItemData shareitemdata) {
logger.log(Level.SEVERE, "insertMyShareItem");
}
Advantages of google cloud endpoint was endpoint libray , easy use of Auth2 and automatically use of secure connections via HTTPS
Now I want to give up Async task in order to implement Retrofit or Volley. I understood I cannot use google cloud endpoint anymore and need to transform my methods on GAE Back end side in methods which extends HttpServlet so I can access them by URL call with normal setup of Retrofit.
Which means now I need to care :
how I pass my object to Retrofit and how I retrieve them on back end
how I transform Retrofit HTTP call in a HTTPS call for secure connection
how I implement and manage Auth2 and tokens between Client and GAE back end to establish secure authentication.
This is what I understood from search and below answers.Thks
Use the Google Cloud API URL as the base URL and proceed with the normal setup of Retrofit. I don't think it is a big deal. Here is a link to a tutorial that could help you get started with Retrofit.
[source]

Using Sync Adapters+ Volley/RoboSpice for Syncronous processing of Network Requests

My application needs to periodically request the server for new data. I have researched regarding this and many suggested to use sync adapter for syncing with the server, however my requirement changed and I need to do the following process. Is it still advisable to use sync adapters or can I use any other library to efficiently make the following Http request sequence.
public void onPerformSync(Account account, Bundle extras, String authority, ContentProviderClient provider, SyncResult syncResult) {
ZipFile imageZipFile;
/*this is a http post request and the size the zipfile is around 1Mb*/
ZipFile resultFile=makeHttpPostRequest(String URL, String payload);
SomeObject result= processZipFile(resultZipFile);
saveData(result);
for(String url:result.getUrls()){
/* this is a HttpGet request which returns a zip file that
contains 8 images , total size of zip would be around 200kb*/
imageZipFile= makeHttpGetRequest(url);
saveImageZipToDisk(imageZipFile)
}
}
As you can see I am making a Http Post request to get some data that contains the image URL's and use those URL's to make a new HttpGet request. I would need both the result from the POST and also the images for my app to run.
Is this a valid way to use sync adapters or is this totally unacceptable? or Can I use Volley/ Robo spice to spawn the image requests to multiple threads? Sorry I am being novice, but this is a scenario I have been trying to solve.
Update:
So after reviewing the pros and cons of Volley and Robospice, I am using volley as I could customize the code and have more control over the caching mechanism.
All alternatives should be working.
With async adapters, you will get :
async background processing in a native android process
might be more lightweight than the app process depending on your design
but the communication between the app and the async adapter will involve IPC which means bundling/unbundling stuff
With Volley, you will get :
async background processing in the same process as your app, inside Volley threads
communication between your requests and your app will be a fully double way OO channel
With RoboSpice, you will get :
what volley provides, but requests will be executed inside an Android service
possible easier setup of caching
more alternatives for networking (spring android, google http client, retrofit) etc.

Can I use some Python in the backend for an Android app?

Most of the backend stuff is in PHP which handle JSON request and response flow of data from Android app to backend.
I'd like to start writing Python code to handle the extra features I'm going to add in my app. How can I do that? Do I need to install Django or something like it in the backend? Our webhost does show "Python support". I'm guessing just a couple of Python classes and some helper library files would suffice.
But here's where I'm conceptually stuck:
In Android, on the app, in the user's side, suppose I send all my queries to backend with this function:
//Pseudo code on Android app
getServerResponse()
{
url = " ??? ";
jsondata = {somedata[a:b]};
response = sendData_andGetResponse(jsondata); // suppose this function sens json data and expects a server response.
showResults(response);
//Pseudo code on backend - BackendProcessing.py
def processRequest():
# some processing done here
response = "some_processed_data"
return response
My problem is, what and how do I integrate the backend Python code and the client side Android app code to communicate with each other. What should the URL be in my Android code to pass data from user to backend? How do I link them?
Do I need to specially setup some third party Python API to handle calls from the Android app at the backend? Or can I just do it with simple Python functions and classes with HTTP request and responses coming in for a particular URI?
You can include URL of the backend server in the android code. Define a variable for the URL of your backend server and use Httppost method for communication between backend and frontend.
Details here http://developer.android.com/reference/org/apache/http/client/methods/HttpPost.html
You can do it with simple Python functions and classes with HTTP request and responses coming in for a particular URI. A third party Python API is not necessary.
You can also use Python based web frameworks like Django for the backend.

What is an easy way to stub / dummy a restful web service?

I want to create an android application, this application will make RESTful calls to a web service to obtain some data.
I know what the RESTful interface will be, but I don't want the hassle of creating my own implementation. Is there an easy way to create a stub RESTful web service that will return some static data without having to write a full blown WS application to do this?
Mocky.io allows you to create stub endpoints and specify the data they return via public URLs.
Runscope (disclaimer, I'm a founder) allows you to capture a real request once, then replay back the response as needed via Response Playback URLs.
I've found using Sinatra really useful for this sort of thing if you want to test the actual HTTP calling code. You can have a endpoint returning data in seconds. Very little Ruby knowledge required.
require 'sinatra'
require 'json'
get '/Person' do
content_type :json
{ :id => 345, :key2 => 'John Doe' }.to_json
end
Is all you would need to return a simple json object.
One of the approaches (similar to Vinnie's) is to make a local implementation of your webservice. For example, your webservice allows you to log a user in and to get a list of users online.
The webservice interface looks like this:
public interface WebService {
public LoginResponse login(String user, String pass) throws Exception;
public UsersOnlineResponse getOnlineUsers() throws Exception;
}
Then, we implement this interface for remote webservice which will be used in production. Remote implementation makes HTTP calls with help of HTTP client, retrieves response and parses it to an appropriate response object. Here is a fragment of it:
public class RemoteWebService implements WebService {
private AndroidHttpClient client = AndroidHttpClient.newInstance(USER_AGENT);
#Override
public LoginResponse login(String user, String pass) throws Exception {
LoginResponse response = client.execute(
createPostRequest(METHOD_LOGIN, user, pass),
new JsonResponseHandler(LoginResponse.class));
handleResponse(response); // verify response, throw exceptions if needed
return response;
}
}
For testing purposes, when webservice is not available or is being developed, we implement local webservice. Local implementation takes predefined JSON responses from assets folder and parses it to an appropriate response object. It's up to you how to implement webservice behaviour: it can be simple static responses or some random/validation-dependent responses. Here is the part of it:
public class LocalWebService implements WebService {
private Context context;
public LocalWebService(Context context) {
this.context = context;
}
#Override
public LoginResponse login(String user, String pass) throws Exception {
Thread.sleep(DELAY); //emulate network delay
if (validateParams(user, pass)) {
return parseAssetsJson("ws/login.json", LoginResponse.class);
} else {
Response response = parseAssetsJson("ws/status_bad_request.json", Response.class);
throw new WebServiceException(response);
}
}
public <T> T parseAssetsJson(String filename, Class<T> klass) throws IOException {
InputStream is = context.getAssets().open(filename);
return JsonParser.getInstance().fromJson(new InputStreamReader(is), klass);
}
}
Next, we want to switch between implementations painlessly. The usage of both implementations of the webservice is transparent, because we use WebService interface. So, we'll configure the WebService instance on app launch. Application class suits our needs:
public class App extends Application {
public static final boolean USE_LOCAL_WS = false;
private static WebService webService;
public static getWebService() {
return webService;
}
#Override
public void onCreate() {
super.onCreate();
webService = USE_LOCAL_WS ? new LocalWebService(this) : new RemoteWebService();
}
}
I'd suggest checking out WireMock (disclaimer - I wrote it):
http://wiremock.org/
You can run it standalone on your laptop, configure stubbed responses and verify that your app send the requests you expected it.
It's configurable via a fluent Java API or JSON (files or over HTTP).
I ended up writing a mock service tool for a similar purpose: https://github.com/clafonta/Mockey/wiki
A mock service is a great tool for quickly building UIs and validating your client code, but it can become a rabbit hole, so I recommend you use something that is already out there before building your own. Github has plenty of results when you search for 'mock'. Regardless of what you do, here are a few key stumbling blocks that you may encounter.
You end up working with the wrong data/JSON format. For example, your app works great with the mock service, but breaks when hitting the real service because your app consumes a JSON object but the real service returns an Array of JSON objects. To avoid this, you could try using JSON Schema to help highlight invalid JSON models in your mock service.
Your app doesn't make a valid request. Your mock service will typically not care about the incoming request. For example, the real service needs a "customerID" and your app never passes it in. To avoid this, you could build some "required request parameter" validation logic in your mock service.
Testing challenges. Your automated functional testing approach needs to interact with your mock service tool if you want to test things beyond the simple "happy path". For example, you run your test "user A logs-in and sees 0 messages" vs. "user B logs-in and sees 20 messages".
You can try Jadler (http://jadler.net). It's an http stubbing/mocking library I've been working on for some time. It should meet all your requirements I believe.
Just in case someone is still looking at this thread at year >= 2017. There's free tool out there now that let's you create mock soap and rest web services in seconds without the need to install or deploy anything on your box.
amock.io
You can select your http method, response code, response message body, content-type, specify custom endpoint, etc.
It's very useful for returning mock data from remote web services to you app, any kind of app.
Disclaimer, I developed this service, out of necessity and I made it free so others can benefit from the solution.
Beeceptor (disclaimer, I'm the author) shall help you for the exact use-case here. Create an API endpoint, define a mock path and response. Use it in hackathons to build mock APIs in seconds.
Beeceptor is more than a mocking service. It is an HTTP proxy for APIs. For example, if you have a real API, use the real API as ultimate target. Beecetor intercepts traffic and using rules,
when rules are matched, APIs are mocked
when no rule matches, your target endpoint is hit as usual.
With Mocky.io, you shall have different API paths, with Beeceptor your base URL is going to be same all the time.
There's pretty new mock API solution called QuickMocker that allows not only stubbing static data, but also generate fake (faker), random and contextual data using shortcodes. Supports multiple HTTP methods and RegExp URL path which allows to create even one single dummy endpoint that can intercept anything you need. And yeah, it allows to debug any request made to your fake API domain.
Probably the best thing to do is create a mock for the REST web service service while you're developing your application code and then replace it with code to call the actual web service returning "real" data, once your application is written.
I'm currently writing a very similar application to yours which (like you) obtains data from a RESTful web application. In my application, I'm following the MVP pattern recommended by GWT and is also documented by Martin Fowler as the PassiveView pattern.
What you want to do is abstract away the code to make the REST web service call into an interface (the Model). The responsibility of this model class is to provide data to the Presenter/Controller. The Presenter will handle all of your business logic and then pass data up to the view (the view should be pretty dumb as well allowing it to also be mocked out). During testing, you will create a MockModel to implement the model interface and pass test data to the Presenter - without making an actual web service call at all! Then, when you're ready, you will replace this class with the actual web service and start your integration testing.
This approach has the added benefit in that it will be easy to create specific (and repeatable) test cases in your mock model. If you don't have control of the actual web service (and I'm assuming you don't), this can be difficult (or even to impossible) to achieve. The result should be a more robust, better tested application without to need to create any test XML or JSON or creating the web services yourself.
Create some files with dummy responses and put into a folder. Now go to command-line and execute the following:
python -m SimpleHTTPServer
You can now access these files and dummy responses at
http://:8000
I suggest taking a look at FakeRest (https://github.com/marmelab/FakeRest), a client-side only Fake Server using XMLHTTPRequest monkey patching.
Disclaimer: I wrote it.
Atmo could be useful.
Disclaimer: I'm the author of atmo.
You can make use of http://maqueapp.com/ to create the mock web service. Its quick and easy. I heard about it on theflexshow episode 157 (not flexshow!)

Categories

Resources