Google I/O 2010 - Android REST client applications

By: Google Developers

1201   18   229546

Uploaded on 05/27/2010

Google I/O 2010 - Developing Android REST client applications

Android 301

Virgil Dobjanschi

This session will present architectural considerations for developing RESTful applications on the Android platform. It focuses on design patterns, platform integration and performance issues specific to the Android platform.

For all I/O 2010 sessions, please go to http://code.google.com/events/io/2010/sessions.html

Comments (7):

By anonymous    2017-09-20

The best pattern is a combination of various patterns. it's subjected to the type of activity you are supposed to do.

For some recommended design patterns see: Google I/O 2010 - Android REST client applications

For accessing the rest API, there's already several libraries which are designed for this specific purpose (e.g., retrofit, volley, being some of them) they abstract the network access as well as the serialization, doing these by yourself, seems overkill unless there's specific reason to do so.

For example, in retrofit it's easy as this:

the API as an interface

public interface GitHubService { 
  @GET("/users/{user}/repos")
  List<Repo> listRepos(@Path("user") String user); 
}

using with an adapter

RestAdapter restAdapter = new RestAdapter.Builder() 
      .setEndpoint("https://api.github.com")
      .build(); 

GitHubService service = restAdapter.create(GitHubService.class);

List<Repo> repos = service.listRepos("octocat");

This does all the serialization, and deserialization required (with retrofit 2.0 the serialization is detached and should be plugged-in via modules).

There is official example/tutorial on volley here

Original Thread

By anonymous    2017-09-20

TL; DR

Always start long term operations from a service. (or a JobScheduler)

Description

If you are downloading a reasonably big file, use the presenter to trigger an IntentService (or JobScheduler for Android Marshmallow and later), never AsyncTask, Thread or any asynchronous structure that would callback to the main thread.

The presenter survives to onPause, but not to onDestroy, so if the application be killed by the operating system the reference to the activity/fragment will be lost anyway.

If you are running the download in a service, your presenter can check if the file already exists and updates the activity/fragment properly.

Remember that the fragment being destroyed is actually good for the OS, so use early/often persistence of network data :-)

Original Thread

By anonymous    2017-11-06

In my application that I'm developing, I am making calls to an API, one of them is logging in.

While I was learning about using Async Tasks in Android, I came across this question which had a link to a Google IO video which specifically stated that inner Async tasks is a bad idea. I thought that made sense and went on my merry way.

I go to make a new LoginActivity as I figured it would be nice to get a good template to it. However, I noticed that it had an inner asynctask which I thought was a no-no.

public class UserLoginTask extends AsyncTask<Void, Void, Boolean> {

    private final String mEmail;
    private final String mPassword;

    UserLoginTask(String email, String password) {
        mEmail = email;
        mPassword = password;
    }

    @Override
    protected Boolean doInBackground(Void... params) {
        // TODO: attempt authentication against a network service.

        try {
            // Simulate network access.
            Thread.sleep(2000);
        } catch (InterruptedException e) {
            return false;
        }

        for (String credential : DUMMY_CREDENTIALS) {
            String[] pieces = credential.split(":");
            if (pieces[0].equals(mEmail)) {
                // Account exists, return true if the password matches.
                return pieces[1].equals(mPassword);
            }
        }

        // TODO: register the new account here.
        return true;
    }

    @Override
    protected void onPostExecute(final Boolean success) {
        mAuthTask = null;
        showProgress(false);

        if (success) {
            finish();
        } else {
            mPasswordView.setError(getString(R.string.error_incorrect_password));
            mPasswordView.requestFocus();
        }
    }

    @Override
    protected void onCancelled() {
        mAuthTask = null;
        showProgress(false);
    }
}

This is an inner asynctask class nested inside the Activity class. What makes this okay and other asynctasks not?

Original Thread

By anonymous    2017-09-20

There is a cool explanation on how to design apps for such kind of purposes - Developing Android REST client applications.

Original Thread

Recommended Books

    Popular Videos 404

    Submit Your Video

    If you have some great dev videos to share, please fill out this form.