Im developing an app that have alot of web requests. Such as download or upload files , REST requests and etc.
I want to save all of this functions in a class like a helper and only just import the class and call functions that i need them in my activities.
something like a custom library for web requests i mean.
Is there any Design pattern for this?
(I hope i explain my idea well)
Consider using these libraries:
Robospice - for asynchronous network calls
Retrofit - for REST calls
OkHttp - good HTTP/SPDY client
Picasso - for image loading and caching
Jackson - to work with JSON
You can use custom IntentService class to hanle all networking there, starting this service from UI and passing apropriate ACTION to perform.
And of course i would suggest you watch this video from Google I/O 2010 and use REST Pattern A described there in EVERY network app you make.
You could use the Chain of Responsibility pattern for building up requests and then executing them. See some details here.
Of course, using just this one pattern would not be enough. It should be used in conjunction with an Observer, Factory, Proxy and maybe some others. Just start developing with SOLID in mind.
Related
I am developing an Android application which has 3 main types of network operations :-
1) OAuth type login authentication which is a 2 step process - first one is getting the access token and second is getting user details.
2) Post operations when user clicks a button only working with text data (no images)
3) Background sync operations where multiple databases will be updated on the client and server and most of these tables are not related to one other. So they can be performed in parallel.
So for these network operations should I use Volley or custom async http implementations?
What if I have images to upload and download in these operations.
Volley is much better that custom async operations and handles much more cases. The question would be more which http client library to use. There quite a few out there but Volley does a good job.
for point 1) you need to apply you custom flow and requests here but it is not difficult as Volley is quite modular
for uploading and downloading images you will also have to do some more work because it does not come out-of-the-box.
I would also suggest to try jus. it is based on volley but including many handy features, which will help you in your particular case as well.
I have a server that returns data in JSON format (I author the server code).
I am planning to extend the abstract AbstractWindowedCursor and load remote data into this window. Is this the right way to do?
The best way to do it would be to use a AsyncTask to open a connection to your server.
Take a look at the example code from Google on how to do this.
Better implementation would involve using Volley or some other library like OkHttp. However, the example above from Google will give you a good idea of what goes on under the hood and is a good place to start.
Is there a reason you want to use the AbstractWindowedCursor? I've never seen it used for api calls, it's really more for querying the database.
I'm using AsyncHTTPClient to communicate with my server API.
I've read that I have to use services to communicate with a server.
1) Is AsyncHTTPClient already a service? Or do I still need to put all methods which use AsyncHTTPClient into my own services? Or is it OK to call AsyncHTTPClient methods directly from my Activities?
2) I can't understand how services should be properly used. Let's say I don't use AsyncHTTPClient but I have few different actions which make a call to server API (get realities, get users, post user, etc.). Do I have to put each action into a separate service? If not, how can I call different methods from one same service? All examples I have seen always show that there's just one action which is automatically being called on service start up by Activity.
3) I found another Android REST library Retrofit - does it have any advantages over AsyncHTTPClient? Do I need to put it into services?
At first, I would recommend you to use Retrofit. I've already used AsynHttp, but now I am using Retrofit, and I am very satisfied with it.
About the topics in your question:
I've read that I have to use services to communicate with a server.
Where do you read this? I don't create Service to my requests, and all of then works pretty well. The main point when creating your requests is to make them in a background thread. So if you don't use some lib like AsyncHttp or Retrofit, you have to put your requests in an AsynTask class, for example.
Is AsyncHTTPClient already a service?
No. It is a library to make asynchronous HTTP requests. In the site of the lib, they say:
All requests are made outside of your app’s main UI thread and You can also use it in Service or background thread.
That is, you can use it in a Service, they do not say you have to use it in a Service.
The example in the site teaches how to make a RestClient with this library. It is a good example. You only need to create a static class and put the methods to make your posts, gets etc
I can't understand how services should be properly used.
Services are used for long-running operations in the background. A possible way to use a Service with your lib (AsyncHttp or Retrofit) is when you want to make requests to the server, even when the user is not using your app. So you can create a Service with a timer that will call the server at the intervals defined by you.
Retrofit - does it have any advantages over AsyncHTTPClient?
Backing to Retrofit, again you don't have to put it in a Service. Only if you need this. From threir site, they say: Retrofit turns your REST API into a Java interface. This make your client very simple, and self documented because each call to your server API will be a method in this interface, and I think this is a big advantage. It is simple to use Retrofit. As I said, now I changed to Retrofit, and I can say, the lib has a good documentation and support, it has many users. So it is easy to find solutions to some bug. Other advantage is that it already has the lib GSON, which is very useful to parse the JSONs that you will receive from your server API.
But of course talking about vantages is dangerous because you can find many personal opinions. See this question and its answers. I think some answers from there can also help you with your choice.
To finish, here are some links with tutorials about Retrofit and how to create your requests with this powerful library.
Durable Android REST Clients
Consuming APIs with Retrofit
A smart way to use Retrofit
as the title said,
I'm looking for a method to handle a POST request made from my Android front end to my Drupal back end.
I've already seen a lot of documentation and reference, like this one: http://tylerfrankenstein.com/code/build-mobile-app-sell-products-with-drupal
but I can't figure it out.
Anyone can help me?
Use Services
It sounds like you need to setup an API using something like a REST service. Drupal has a great module for this called Services.
Essentially you can setup your Android app to use the POST method to push to your Drupal configured endpoint.
EG: https://www.mysite.com/api/android/
Services is extremely flexible and you can have it work through basic CRUD operations for nodes or you can use hooks and use custom logic for a particular service you want to use and write custom PHP code to do whatever you want.
How about using this library for native Android applications to communicate with Drupal web servers?
Feature list:
Synchronous and asynchronous requests
Flexible object serialization / deserialization
API can calculate object differences to perform patch requests
Simple entities request
Here is one design/ best practices question..
I'm new to android development, and basically new to web/mobile solutions.
So, my question is - what are best practices when organizing structure of android application that get data from the remote server?
Should request to server go into one class that does communication with server (get and post requests), or should I look at my requests as data source, meaning that every data class manages it for itself?
or should I have more levels of abstraction - one level for acquiring data, other for model that uses some interfaces without knowing from what source data come from?
I'm curious how experienced android developers approach to these design issues...
Virgil Dobjanschi presentation is a good resource as pointed earlier, which basically tells you to run your requests from a background service so the activity does not get destroyed and to store your data in the database as early as possible.
For more technical details, the way I am doing it is to divide the app into three components:
1- Library to encapsulate the handling of the HTTP request and response (with ApacheHTTP), which can handle simple request/response and advanced features that might involve cookies (can be necessary for login) and modifying the HTTP header.
2- Marshal/Unmarsha layer, where I parse the server data (e.g. XML or JSON) and convert it to objects (i.e. models) that the rest of my app will deal with.
3- Persistence layer.
As per Dobjanschi's presentation, I usually make data requests run in a service not in a thread worker inside the activity.
Use one of the 3 models presented at this Google I/O talk. It provides you suggestions that will help you out on the whole process of definition of your app architecture. It'll also prevent you from making common mistakes beginners use to make:
http://www.youtube.com/watch?v=xHXn3Kg2IQE
This post will also help you out:
Need sample Android REST Client project which implements Virgil Dobjanschi REST implementation pattern