Próbuję próbki z Room Persistence Library . Utworzyłem jednostkę:

@Entity
public class Agent {
    @PrimaryKey
    public String guid;
    public String name;
    public String email;
    public String password;
    public String phone;
    public String licence;
}

Utworzono klasę DAO:

@Dao
public interface AgentDao {
    @Query("SELECT COUNT(*) FROM Agent where email = :email OR phone = :phone OR licence = :licence")
    int agentsCount(String email, String phone, String licence);

    @Insert
    void insertAgent(Agent agent);
}

Utworzono klasę Database:

@Database(entities = {Agent.class}, version = 1)
public abstract class AppDatabase extends RoomDatabase {
    public abstract AgentDao agentDao();
}

Odsłonięta baza danych przy użyciu poniższej podklasy w Kotlinie:

class MyApp : Application() {

    companion object DatabaseSetup {
        var database: AppDatabase? = null
    }

    override fun onCreate() {
        super.onCreate()
        MyApp.database =  Room.databaseBuilder(this, AppDatabase::class.java, "MyDatabase").build()
    }
}

Zaimplementowana poniżej funkcja w mojej działalności:

void signUpAction(View view) {
        String email = editTextEmail.getText().toString();
        String phone = editTextPhone.getText().toString();
        String license = editTextLicence.getText().toString();

        AgentDao agentDao = MyApp.DatabaseSetup.getDatabase().agentDao();
        //1: Check if agent already exists
        int agentsCount = agentDao.agentsCount(email, phone, license);
        if (agentsCount > 0) {
            //2: If it already exists then prompt user
            Toast.makeText(this, "Agent already exists!", Toast.LENGTH_LONG).show();
        }
        else {
            Toast.makeText(this, "Agent does not exist! Hurray :)", Toast.LENGTH_LONG).show();
            onBackPressed();
        }
    }

Niestety przy wykonaniu powyższej metody następuje awaria z poniższym śladem stosu:

    FATAL EXCEPTION: main
 Process: com.example.me.MyApp, PID: 31592
java.lang.IllegalStateException: Could not execute method for android:onClick
    at android.support.v7.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:293)
    at android.view.View.performClick(View.java:5612)
    at android.view.View$PerformClick.run(View.java:22288)
    at android.os.Handler.handleCallback(Handler.java:751)
    at android.os.Handler.dispatchMessage(Handler.java:95)
    at android.os.Looper.loop(Looper.java:154)
    at android.app.ActivityThread.main(ActivityThread.java:6123)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:757)
 Caused by: java.lang.reflect.InvocationTargetException
    at java.lang.reflect.Method.invoke(Native Method)
    at android.support.v7.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:288)
    at android.view.View.performClick(View.java:5612) 
    at android.view.View$PerformClick.run(View.java:22288) 
    at android.os.Handler.handleCallback(Handler.java:751) 
    at android.os.Handler.dispatchMessage(Handler.java:95) 
    at android.os.Looper.loop(Looper.java:154) 
    at android.app.ActivityThread.main(ActivityThread.java:6123) 
    at java.lang.reflect.Method.invoke(Native Method) 
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867) 
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:757) 
 Caused by: java.lang.IllegalStateException: Cannot access database on the main thread since it may potentially lock the UI for a long periods of time.
    at android.arch.persistence.room.RoomDatabase.assertNotMainThread(RoomDatabase.java:137)
    at android.arch.persistence.room.RoomDatabase.query(RoomDatabase.java:165)
    at com.example.me.MyApp.RoomDb.Dao.AgentDao_Impl.agentsCount(AgentDao_Impl.java:94)
    at com.example.me.MyApp.View.SignUpActivity.signUpAction(SignUpActivity.java:58)
    at java.lang.reflect.Method.invoke(Native Method) 
    at android.support.v7.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:288) 
    at android.view.View.performClick(View.java:5612) 
    at android.view.View$PerformClick.run(View.java:22288) 
    at android.os.Handler.handleCallback(Handler.java:751) 
    at android.os.Handler.dispatchMessage(Handler.java:95) 
    at android.os.Looper.loop(Looper.java:154) 
    at android.app.ActivityThread.main(ActivityThread.java:6123) 
    at java.lang.reflect.Method.invoke(Native Method) 
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867) 
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:757) 

Wygląda na to, że problem jest związany z wykonywaniem operacji db na głównym wątku. Jednak przykładowy kod testu podany w powyższym linku nie działa w osobnym wątku:

@Test
    public void writeUserAndReadInList() throws Exception {
        User user = TestUtil.createUser(3);
        user.setName("george");
        mUserDao.insert(user);
        List<User> byName = mUserDao.findUsersByName("george");
        assertThat(byName.get(0), equalTo(user));
    }

Czy coś mi tu brakuje? Jak mogę to zrobić bez awarii? Proszę zasugeruj.

Dostęp do bazy danych w głównym wątku blokującym interfejs użytkownika jest błędem, jak powiedział Dale.

Utwórz statyczną klasę zagnieżdżoną (aby zapobiec wyciekowi pamięci) w swoim działaniu rozszerzającym AsyncTask.

private static class AgentAsyncTask extends AsyncTask<Void, Void, Integer> {

    //Prevent leak
    private WeakReference<Activity> weakActivity;
    private String email;
    private String phone;
    private String license;

    public AgentAsyncTask(Activity activity, String email, String phone, String license) {
        weakActivity = new WeakReference<>(activity);
        this.email = email;
        this.phone = phone;
        this.license = license;
    }

    @Override
    protected Integer doInBackground(Void... params) {
        AgentDao agentDao = MyApp.DatabaseSetup.getDatabase().agentDao();
        return agentDao.agentsCount(email, phone, license);
    }

    @Override
    protected void onPostExecute(Integer agentsCount) {
        Activity activity = weakActivity.get();
        if(activity == null) {
            return;
        }

        if (agentsCount > 0) {
            //2: If it already exists then prompt user
            Toast.makeText(activity, "Agent already exists!", Toast.LENGTH_LONG).show();
        } else {
            Toast.makeText(activity, "Agent does not exist! Hurray :)", Toast.LENGTH_LONG).show();
            activity.onBackPressed();
        }
    }
}

Lub możesz utworzyć ostateczną klasę w swoim własnym pliku.

Następnie wykonaj go w metodzie signUpAction (Widok widoku):

new AgentAsyncTask(this, email, phone, license).execute();

W niektórych przypadkach możesz również chcieć przechowywać odwołanie do AgentAsyncTask w swoim działaniu, aby można było je anulować, gdy działanie zostanie zniszczone. Ale musiałbyś sam przerywać wszelkie transakcje.

Również twoje pytanie dotyczące przykładu testowego Google ... Stwierdzają na tej stronie internetowej:

Zalecanym podejściem do testowania implementacji bazy danych jest napisanie testu JUnit, który działa na urządzeniu z systemem Android. Ponieważ testy te nie wymagają tworzenia aktywności, powinny być wykonywane szybciej niż testy interfejsu użytkownika.

Brak aktywności, brak interfejsu użytkownika.

--EDYTOWAĆ--

Dla ludzi, którzy się zastanawiają ... Masz inne możliwości. Polecam przyjrzeć się nowym komponentom ViewModel i LiveData. LiveData działa świetnie z Room. https://developer.android.com/topic/libraries/architecture/livedata.html

Inną opcją jest RxJava / RxAndroid. Mocniejszy, ale bardziej złożony niż LiveData. https://github.com/ReactiveX/RxJava

--EDYCJA 2--

Ponieważ wiele osób może spotkać się z tą odpowiedzią… Ogólnie rzecz biorąc, obecnie najlepszą opcją jest Kotlin Coroutines. Room obsługuje go teraz bezpośrednio (obecnie w wersji beta). https://kotlinlang.org/docs/reference/coroutines-overview.html https://developer.android.com/jetpack/androidx/releases/room#2.1.0-beta01

Nie jest to zalecane, ale możesz uzyskać dostęp do bazy danych w głównym wątku za pomocą allowMainThreadQueries()

MyApp.database =  Room.databaseBuilder(this, AppDatabase::class.java, "MyDatabase").allowMainThreadQueries().build()

Kotlin Coroutines (jasne i zwięzłe)

AsyncTask jest naprawdę niezgrabny. Korekty są czystszą alternatywą (wystarczy posypać kilkoma słowami kluczowymi, a kod synchronizacji stanie się asynchroniczny).

// Step 1: add `suspend` to your fun
suspend fun roomFun(...): Int
suspend fun notRoomFun(...) = withContext(Dispatchers.IO) { ... }

// Step 2: launch from coroutine scope
private fun myFun() {
    lifecycleScope.launch { // coroutine on Main
        val queryResult = roomFun(...) // coroutine on IO
        doStuff() // ...back on Main
    }
}

Zależności (dodaje coroutine zakresy dla komponentów arch):

// lifecycleScope:
implementation 'androidx.lifecycle:lifecycle-runtime-ktx:2.2.0-alpha04'

// viewModelScope:
implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.2.0-alpha04'

- Aktualizacje:
8 maja 2019 r .: Pokój 2.1 obsługuje teraz suspend
13 września 2019 r .: Zaktualizowano w celu korzystania z zakresu komponentów architektury

Dla wszystkich RxJava lub RxAndroid lub RxKotlin miłośników tam

Observable.just(db)
          .subscribeOn(Schedulers.io())
          .subscribe { db -> // database operation }

Nie możesz go uruchomić w wątku głównym zamiast tego użyj programów obsługi, wątków asynchronicznych lub wątków roboczych. Przykładowy kod jest dostępny tutaj i przeczytaj artykuł nad biblioteką pokojów tutaj: Biblioteka pokojów Androida

/**
 *  Insert and get data using Database Async way
 */
AsyncTask.execute(new Runnable() {
    @Override
    public void run() {
        // Insert Data
        AppDatabase.getInstance(context).userDao().insert(new User(1,"James","Mathew"));

        // Get Data
        AppDatabase.getInstance(context).userDao().getAllUsers();
    }
});

Jeśli chcesz uruchomić go na głównym wątku, co nie jest preferowanym sposobem.

Możesz użyć tej metody do osiągnięcia w głównym wątku Room.inMemoryDatabaseBuilder()

Dzięki lambdzie jest łatwy do uruchomienia z AsyncTask

 AsyncTask.execute(() -> //run your query here );

Dzięki bibliotece Jetbrains Anko możesz użyć metody doAsync {..} do automatycznego wykonywania wywołań bazy danych. To rozwiązuje problem z gadatliwością, który wydawał się mieć z odpowiedzią mcastro.

Przykładowe użycie:

    doAsync { 
        Application.database.myDAO().insertUser(user) 
    }

Używam tego często do wstawiania i aktualizacji, jednak w przypadku wybranych zapytań zalecam korzystanie z przepływu pracy RX.

Po prostu wykonaj operacje na bazie danych w osobnym wątku. W ten sposób (Kotlin):

Thread {
   //Do your database´s operations here
}.start()

Musisz wykonać żądanie w tle. Prostym sposobem może być użycie Executorów :

Executors.newSingleThreadExecutor().execute { 
   yourDb.yourDao.yourRequest() //Replace this by your request
}

Można użyć eleganckiego rozwiązania RxJava / Kotlin Completable.fromCallable, które da ci Observable, który nie zwraca wartości, ale może być obserwowany i subskrybowany w innym wątku.

public Completable insert(Event event) {
    return Completable.fromCallable(new Callable<Void>() {
        @Override
        public Void call() throws Exception {
            return database.eventDao().insert(event)
        }
    }
}

Lub w Kotlinie:

fun insert(event: Event) : Completable = Completable.fromCallable {
    database.eventDao().insert(event)
}

Możesz obserwować i subskrybować tak, jak zwykle:

dataManager.insert(event)
    .subscribeOn(scheduler)
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(...)

Możesz zezwolić na dostęp do bazy danych w głównym wątku, ale tylko w celu debugowania, nie powinieneś tego robić na produkcji.

Oto powód.

Uwaga: Room nie obsługuje dostępu do bazy danych w głównym wątku, chyba że wywołałeś allowMainThreadQueries () w kreatorze, ponieważ może to zablokować interfejs użytkownika na długi czas. Zapytania asynchroniczne - zapytania, które zwracają wystąpienia LiveData lub Flowable - są wyłączone z tej reguły, ponieważ w razie potrzeby asynchronicznie uruchamiają zapytanie w wątku w tle.

Po prostu możesz użyć tego kodu, aby go rozwiązać:

Executors.newSingleThreadExecutor().execute(new Runnable() {
                    @Override
                    public void run() {
                        appDb.daoAccess().someJobes();//replace with your code
                    }
                });

Lub w lambdzie możesz użyć tego kodu:

Executors.newSingleThreadExecutor().execute(() -> appDb.daoAccess().someJobes());

Możesz zastąpić appDb.daoAccess().someJobes()własnym kodem;

Ponieważ asyncTask są przestarzałe, możemy korzystać z usługi wykonawczej. LUB możesz również użyć ViewModel z LiveData, jak wyjaśniono w innych odpowiedziach.

Aby skorzystać z usługi executora, możesz użyć czegoś takiego jak poniżej.

public class DbHelper {

    private final Executor executor = Executors.newSingleThreadExecutor();

    public void fetchData(DataFetchListener dataListener){
        executor.execute(() -> {
                Object object = retrieveAgent(agentId);
                new Handler(Looper.getMainLooper()).post(() -> {
                        dataListener.onFetchDataSuccess(object);
                });
        });
    }
}

Używany jest Main Looper, dzięki czemu można uzyskać dostęp do elementu UI z onFetchDataSuccesswywołania zwrotnego.

Komunikat o błędzie,

Nie można uzyskać dostępu do bazy danych w głównym wątku, ponieważ może to potencjalnie blokować interfejs użytkownika na długi czas.

Jest dość opisowa i dokładna. Pytanie brzmi, jak należy unikać dostępu do bazy danych w głównym wątku. To obszerny temat, ale aby zacząć, przeczytaj o AsyncTask (kliknij tutaj)

-----EDYTOWAĆ----------

Widzę, że masz problemy podczas uruchamiania testu jednostkowego. Masz kilka możliwości rozwiązania tego problemu:

1. Uruchom test bezpośrednio na komputerze deweloperskim, a nie na urządzeniu z systemem Android (lub emulatorze). Działa to w przypadku testów, które są skoncentrowane na bazie danych i nie ma znaczenia, czy są uruchomione na urządzeniu.

2. Użyj adnotacji, @RunWith(AndroidJUnit4.class) aby uruchomić test na urządzeniu z systemem Android, ale nie w działaniu z interfejsem użytkownika. Więcej szczegółów na ten temat można znaleźć w tym samouczku

Jeśli wolisz zadanie Async :

  new AsyncTask<Void, Void, Integer>() {
                @Override
                protected Integer doInBackground(Void... voids) {
                    return Room.databaseBuilder(getApplicationContext(),
                            AppDatabase.class, DATABASE_NAME)
                            .fallbackToDestructiveMigration()
                            .build()
                            .getRecordingDAO()
                            .getAll()
                            .size();
                }

                @Override
                protected void onPostExecute(Integer integer) {
                    super.onPostExecute(integer);
                    Toast.makeText(HomeActivity.this, "Found " + integer, Toast.LENGTH_LONG).show();
                }
            }.execute();

Aktualizacja: otrzymałem również tę wiadomość, gdy próbowałem zbudować zapytanie przy użyciu @RawQuery i SupportSQLiteQuery wewnątrz DAO.

@Transaction
public LiveData<List<MyEntity>> getList(MySettings mySettings) {
    //return getMyList(); -->this is ok

    return getMyList(new SimpleSQLiteQuery("select * from mytable")); --> this is an error

Rozwiązanie: utwórz zapytanie wewnątrz ViewModel i przekaż je do DAO.

public MyViewModel(Application application) {
...
        list = Transformations.switchMap(searchParams, params -> {

            StringBuilder sql;
            sql = new StringBuilder("select  ... ");

            return appDatabase.rawDao().getList(new SimpleSQLiteQuery(sql.toString()));

        });
    }

Lub...

Nie powinieneś uzyskiwać dostępu do bazy danych bezpośrednio w głównym wątku, na przykład:

 public void add(MyEntity item) {
     appDatabase.myDao().add(item); 
 }

Należy używać AsyncTask do operacji aktualizacji, dodawania i usuwania.

Przykład:

public class MyViewModel extends AndroidViewModel {

    private LiveData<List<MyEntity>> list;

    private AppDatabase appDatabase;

    public MyViewModel(Application application) {
        super(application);

        appDatabase = AppDatabase.getDatabase(this.getApplication());
        list = appDatabase.myDao().getItems();
    }

    public LiveData<List<MyEntity>> getItems() {
        return list;
    }

    public void delete(Obj item) {
        new deleteAsyncTask(appDatabase).execute(item);
    }

    private static class deleteAsyncTask extends AsyncTask<MyEntity, Void, Void> {

        private AppDatabase db;

        deleteAsyncTask(AppDatabase appDatabase) {
            db = appDatabase;
        }

        @Override
        protected Void doInBackground(final MyEntity... params) {
            db.myDao().delete((params[0]));
            return null;
        }
    }

    public void add(final MyEntity item) {
        new addAsyncTask(appDatabase).execute(item);
    }

    private static class addAsyncTask extends AsyncTask<MyEntity, Void, Void> {

        private AppDatabase db;

        addAsyncTask(AppDatabase appDatabase) {
            db = appDatabase;
        }

        @Override
        protected Void doInBackground(final MyEntity... params) {
            db.myDao().add((params[0]));
            return null;
        }

    }
}

Jeśli używasz LiveData do wybranych operacji, nie potrzebujesz AsyncTask.

W przypadku szybkich zapytań możesz zezwolić na wykonanie go w wątku interfejsu użytkownika.

AppDatabase db = Room.databaseBuilder(context.getApplicationContext(),
        AppDatabase.class, DATABASE_NAME).allowMainThreadQueries().build();

W moim przypadku musiałem dowiedzieć się, że kliknięty użytkownik na liście istnieje w bazie danych, czy nie. Jeśli nie, utwórz użytkownika i rozpocznij inną czynność

       @Override
        public void onClick(View view) {



            int position = getAdapterPosition();

            User user = new User();
            String name = getName(position);
            user.setName(name);

            AppDatabase appDatabase = DatabaseCreator.getInstance(mContext).getDatabase();
            UserDao userDao = appDatabase.getUserDao();
            ArrayList<User> users = new ArrayList<User>();
            users.add(user);
            List<Long> ids = userDao.insertAll(users);

            Long id = ids.get(0);
            if(id == -1)
            {
                user = userDao.getUser(name);
                user.setId(user.getId());
            }
            else
            {
                user.setId(id);
            }

            Intent intent = new Intent(mContext, ChatActivity.class);
            intent.putExtra(ChatActivity.EXTRAS_USER, Parcels.wrap(user));
            mContext.startActivity(intent);
        }
    }

Możesz użyć Future i Callable. Nie musisz więc pisać długiego asynctask i możesz wykonywać zapytania bez dodawania funkcji allowMainThreadQueries ().

Moje zapytanie dao: -

@Query("SELECT * from user_data_table where SNO = 1")
UserData getDefaultData();

Moja metoda repozytorium: -

public UserData getDefaultData() throws ExecutionException, InterruptedException {

    Callable<UserData> callable = new Callable<UserData>() {
        @Override
        public UserData call() throws Exception {
            return userDao.getDefaultData();
        }
    };

    Future<UserData> future = Executors.newSingleThreadExecutor().submit(callable);

    return future.get();
}

Moim zdaniem właściwą rzeczą jest delegowanie zapytania do wątku IO za pomocą RxJava.

Mam przykład rozwiązania podobnego problemu, z którym właśnie się spotkałem.

((ProgressBar) view.findViewById(R.id.progressBar_home)).setVisibility(View.VISIBLE);//Always good to set some good feedback
        Completable.fromAction(() -> {
            //Creating view model requires DB access
            homeViewModel = new ViewModelProvider(this, factory).get(HomeViewModel.class);
        }).subscribeOn(Schedulers.io())//The DB access executes on a non-main-thread thread
        .observeOn(AndroidSchedulers.mainThread())//Upon completion of the DB-involved execution, the continuation runs on the main thread
        .subscribe(
                () ->
                {
                    mAdapter = new MyAdapter(homeViewModel.getExams());
                    recyclerView.setAdapter(mAdapter);
                    ((ProgressBar) view.findViewById(R.id.progressBar_home)).setVisibility(View.INVISIBLE);
                },
                error -> error.printStackTrace()
        );

A jeśli chcemy uogólnić rozwiązanie:

((ProgressBar) view.findViewById(R.id.progressBar_home)).setVisibility(View.VISIBLE);//Always good to set some good feedback
        Completable.fromAction(() -> {
            someTaskThatTakesTooMuchTime();
        }).subscribeOn(Schedulers.io())//The long task executes on a non-main-thread thread
        .observeOn(AndroidSchedulers.mainThread())//Upon completion of the DB-involved execution, the continuation runs on the main thread
        .subscribe(
                () ->
                {
                    taskIWantToDoOnTheMainThreadWhenTheLongTaskIsDone();
                },
                error -> error.printStackTrace()
        );