Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the working principle of android Robospice". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the working principle of android Robospice"?

Some of the existing solutions

Robospice is much better than AsyncTask, but there are still some problems. For example, the following common code initiates a request in Activity through Robospice. You don't need to read it carefully, just have a general idea:

FollowersRequest request = new FollowersRequest (user); lastRequestCacheKey = request.createCacheKey (); spiceManager.execute (request, lastRequestCacheKey, DurationInMillis.ONE_MINUTE, new RequestListener {@ Override public void onRequestFailure (SpiceException e) {/ / On success} @ Override public void onRequestSuccess (FollowerList listFollowers) {/ / On failure}})

Then there is the specific code of the request:

Public class FollowersRequest extends SpringAndroidSpiceRequest {private String user; public FollowersRequest (String user) {super (FollowerList.class); this.user = user;} @ Override public FollowerList loadDataFromNetwork () throws Exception {String url = format ("https://api.github.com/users/%s/followers", user); return getRestTemplate () .getForObject (url, FollowerList.class);} public String createCacheKey () {return" followers. "+ user }} problems

You need to do the above for each request, and the code will look bloated:

-for each of your requests you need to inherit SpiceRequest to write a specific subclass.

-similarly, you need to implement a RequestListener to listen for each request.

-if your cache expires for a short time, users will have to wait a long time for each of your requests to finish.

-RequestListener holds an implicit reference to Activity, so it is a question of whether a memory leak is needed.

To sum up, this is not a good solution.

Five steps to make the program simple and robust

When I started developing Candyshop, I tried other approaches. I tried to build a simple and robust solution by mixing some libraries with interesting features. This is a list of libraries I used:

* AndroidAnnotations is used to handle background tasks, EBean, etc.

* Spring RestTemplate is used to handle network requests from REST (including stateful transfer). This library works very well with AndroidAnnotations.

* the library SnappyDB is mainly used to cache some Java objects to local files.

* EventBus uses EventBus to decouple the communication between components within App.

The following figure is the overall architecture that I will explain in detail:

The first step is an easy-to-use caching system.

You will definitely need a persistent caching system to keep it as simple as possible.

@ EBean public class Cache {public static enum CacheKey {USER, CONTACTS,...} public T get (CacheKey key, Class returnType) {.} public void put (CacheKey key, Object value) {.} second step: a REST-compliant Client

Here I will illustrate it through the following example. Remember to make sure you use REST API and put it in the same place.

@ Rest (rootUrl = "http://anything.com") public interface CandyshopApi {@ Get (" / api/contacts/ ") ContactsWrapper fetchContacts (); @ Get (" / api/user/ ") User fetchUser ();} the third application-level event bus (Event Bus)

The Event bus object is initialized at the beginning of the program, and then can be accessed globally by the application. In Android, Application initialization is a good time.

Public class CandyshopApplication extends Application {public final static EventBus BUS = new EventBus ();...} the fourth step is to process those Activity that need data.

For this type of Activity, my approach is very similar to Robospice, which is also based on Service. The difference is that my Service is not the one provided by Android, but a regular singleton object. This object can be accessed from all over the App, and we will explain the specific code in step 5, where we will first take a look at the structure of the Activity code. Because, what we can see in this step is the strong part of our simplification effect!

@ EActivity (R.layout.activity_main) public class MainActivity extends Activity {/ / Inject the service @ Bean protected AppService appService; / / Once everything is loaded... @ AfterViews public void afterViews () {/ … Request the user and his contacts (returns immediately) appService.getUser (); appService.getContacts ();} / * The result of the previous calls will come as events through the EventBus. We'll probably update the UI, so we need to use @ UiThread. * / @ UiThread public void onEvent (UserFetchedEvent e) {...} @ UiThread public void onEvent (ContactsFetchedEvent e) {...} / / Register the activity in the event bus when it starts @ Override protected void onStart () {super.onStart (); BUS.register (this) } / / Unregister it when it stops @ Override protected void onStop () {super.onStop (); BUS.unregister (this);}}

One line of code completes the request for user data, and it also requires only one line of code to parse the data returned by the request. Other data such as address books can also be processed in the same way, which sounds good.

Step 5 background service of singleton version

As I said in the previous step, the Service used here is not the Service class provided by Android. In fact, at the beginning, I considered using Services provided by Android, but * * gave up for the sake of simplification. Because the Services provided by Android usually provides services for operations that need to be handled without an Activity presentation. In another case, you need to provide some functionality to other applications. This is not exactly in line with my needs, and using singletons to handle my background requests allows me to avoid using complex excuses, such as ServiceConnection,Binder and so on.

There are many places that can be discussed in this part. To make it easier to understand, let's start with the architecture and show what happens when Activity calls getUser () and getContacts ().

You can think of each serial in the following figure as a thread:

As you can see, this is the mode I like very much. In most cases, the user does not have to wait, and the view of the program is immediately populated with cached data. Then, when the server data is fetched, the view data will be replaced by the new data. In turn, you need to make sure that your Activity can accept the same type of data multiple times. There is no problem keeping this in mind when building Activity.

Here are some sample code:

/ / As I said, a simple class, with a singleton scope @ EBean (scope = EBean.Scope.Singleton) public class AppService {/ / (Explained later) public static final String NETWORK = "NETWORK"; public static final String CACHE = "CACHE"; / / Inject the cache (step 1) @ Bean protected Cache cache; / / Inject the rest client (step 2) @ RestService protected CandyshopApi candyshopApi / / This is what the activity calls, it's public @ Background (serial = CACHE) public void getContacts () {/ / Try to load the existing cache ContactsFetchedEvent cachedResult = cache.get (KEY_CONTACTS, ContactsFetchedEvent.class); / / If there's something in cache, send the event if (cachedResult! = null) BUS.post (cachedResult) / / Then load from server, asynchronously getContactsAsync ();} @ Background (serial = NETWORK) private void getContactsAsync () {/ / Fetch the contacts (network access) ContactsWrapper contacts = candyshopApi.fetchContacts (); / / Create the resulting event ContactsFetchedEvent event = new ContactsFetchedEvent (contacts) / Store the event in cache (replace existing if any) cache.put (KEY_CONTACTS, event); / / Post the event BUS.post (event);}}

It seems that there is still a lot of code in each request! In fact, I unfolded it for a better explanation. It is not difficult to find that these requests follow a similar pattern, so you can easily construct a Helper to simplify them. For example, getUser () can look like this:

@ Background (serial = CACHE) public void getUser () {postIfPresent (KEY_USER, UserFetchedEvent.class); getUserAsync ();} @ Background (serial = NETWORK) private void getUserAsync () {cacheThenPost (KEY_USER, new UserFetchedEvent (candyshopApi.fetchUser ());}

So what is serial used for? Let's see what the document says:

By default, all anonymous methods of @ Background are executed in parallel. But if two methods use a serial of the same name, they will run sequentially in the same thread, one after another.

Although sequential execution of network requests in a single thread can lead to performance degradation, it makes it easy to handle transactions like "POST first and then GET to get data", which is a feature worth sacrificing some performance. To say the least, if you really find the performance unacceptable, you can easily use multiple serial to solve it. In the current version of Candyshop, I use four different serial at the same time.

Thank you for your reading, the above is the content of "what is the working principle of android Robospice". After the study of this article, I believe you have a deeper understanding of what the working principle of android Robospice is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.