Вземете тригер от ContentObserver

Има ли начин да разберете защо е задействан ContentObserver? Например, ако наблюдавам SMS чрез URI „content://sms“ и SMS е изпратен или получен, има ли начин да разбера, в рамките на класа ContentObserver, какъв е типът на SMS (знам, че мога да задам N ContentObservers, указвайки различни URI, но се надявам, че има начин да се разбере от класа ContentObserver)?

БОНУС: Има и забавна тънкост:

Вторият метод е достъпен само от API ниво 16 нататък, така че кодът не трябва да разчита на URI, за да работи правилно.

ContentObserver:

ContentResolver contentResolver = getBaseContext().getContentResolver();
contentResolver.registerContentObserver(Uri.parse("content://sms"), true, 
                   new MessageObserver(new Handler(), getBaseContext()));

Клас ContentObserver:

class SMSObserver extends ContentObserver {     
   public MyObserver(Handler handler) {
      super(handler);           
   }

   @Override
   public void onChange(boolean selfChange) {
      this.onChange(selfChange, null);
      // What SMS type caused this to trigger????????

   }        

   @Override
   public void onChange(boolean selfChange, Uri uri) {
      // What SMS type caused this to trigger????????
   }        
}

android sms contentobserver
person Utopia025    schedule 30.09.2013    source източник

Отговори (1)


arrow_upward
0
arrow_downward

Вижте, че ще получите Onchange в посочените по-долу случаи

  1. Ако някой синкадаптер е активен в тази база данни, тогава той ще задейства onchange всеки път, когато е от синхронизиране, в този случай може да получите onchange, дори ако нищо всъщност не е променено.
  2. Ако има действителна промяна в набора от данни.

Сега идваме към разкриването на данни, които са били променени, задаването на наблюдател за всеки възможен URI не е никак добра идея, с това можете въпреки че можете да откриете сценарии за актуализиране или изтриване, но усещането за ново вмъкване ще бъде проблем. Ще ви предложа да следвате

Запазете един наблюдател, при инициализация можете да обработвате цели данни, които са налични първоначално, продължете да помните column_id,update_timestamp и общия брой редове, след като напреднете напред, когато промяната дойде следващия път с Coulmn_Id,update_timestamp и count, можете да разберете вид промяна, която се случи

--> Потърсете всички редове, които имат column_id по-голям от това, което си спомняте, ако върне някакви редове, тогава със сигурност са вмъкнати някои нови редове, можете да ги заявите конкретно --> ако горният критерий е неуспешен, тогава трябва да потърсите update_timespamp нещо по-голямо от това последното, което си спомняте, ще каже дали за редове, които са били актуализирани --> Ако и двата по-горе критерия са фиал, тогава потърсете разлика в броя, което може да ви каже за операция за изтриване.

ако не се случи нищо от горното, очевидно не е било нищо, тогава просто игнорирайте сигнала onchange. Дано помогне.

person Techfist    schedule 01.10.2013