Как включить Firebase База данных в реальном времени Автономное сохранение? - PullRequest
0 голосов
/ 16 февраля 2020

В моей MainActivity Я включаю постоянство firebase, как показано ниже,

// Imports ** 

private  lateinit var mDatabase : FirebaseDatabase

val md = FirebaseDatabase.getInstance().setPersistenceEnabled(true)

class MainActivity: AppCompatActivity() {

override fun onCreate(savedInstanceState: Bundle?) { 
// bla bla 
}
}

После инициализации MainActiviy моя активность2 начинает уничтожать MainActivity . В моей модели представления Activity2 я инициализирую все данные с сервера, как показано ниже:

class AppMainActivityViewModel(application: Application) : AndroidViewModel(application) {

lateinit var user_data_ref : DatabaseReference
lateinit var user_data_ref_lis : ValueEventListener

init {
        user = FirebaseAuth.getInstance().currentUser?.uid!! }

fun updateDashboard(){
 user_data_ref = FirebaseDatabase.getInstance().getReference("Users/$user")
user_data_ref_lis = user_data_ref.addValueEventListener(object : ValueEventListener {

            override fun onCancelled(p0: DatabaseError) {
            }
            override fun onDataChange(p0: DataSnapshot) {
                userdata.value = p0.getValue(UserModel::class.java)
            }
        })
}

override fun onCleared() {
        super.onCleared()
        user_data_ref.removeEventListener(user_data_ref_lis)
    }

    }

Если я сначала запусту свое приложение с inte rnet, я предполагаю, что мои слушатели теперь кэшировали данные в автономном режиме, а затем Я вышел из приложения, затем открылся без inte rnet, я ожидал, что локально кэшированные данные немедленно вызовут изменение onData, но, к моему удивлению, изменение onData никогда не инициировалось. Затем я изменил свой код на keepyn c true для user_data_ref, после чего он работал нормально в автономном режиме.

Каждый раз, когда пользователь открывает приложение, загружается куча старых историй (приблизительно 30 ссылок с 100 КБ для каждой ссылки. Некоторые из старых историй никогда не изменятся вообще). Это значительно увеличивает мое потребление пропускной способности за период, так как каждый раз при загрузке файлов fre sh с текущими логами c. Моя главная цель - обеспечить постоянное использование трафика - снизить потребление пропускной способности.

Вот несколько вопросов, которые у меня есть сейчас:

  1. Согласно документу, прослушивателя ValueEvent должно быть достаточно для кэширования данных, почему он не работает в моем случае?

  2. Будет ли эта синхронизация истинно увеличивать потребление пропускной способности, поскольку она постоянно проверяет наличие обновлений?

  3. Будут ли синхронизированы истинные прогоны, даже если моя активность будет уничтожена?

  4. Если я установлю для keepynced значение true для ссылки на базу данных, размер которой составляет 100 КБ , если внутри моей ссылки происходит дочернее обновление, которое будет изменено на 1 КБ. Будут ли загружены эти 100 КБ в следующий раз или только 1 КБ?

1 Ответ

2 голосов
/ 16 февраля 2020

Моя основная цель обеспечения сохранения - это уменьшить потребление полосы пропускания.

Цель сохранения диска - позволить приложению запускаться и запускаться, даже если у пользователя нет целое rnet соединение. Хотя постоянство диска может также сократить некоторые загрузки данных, это не гарантируется и не является его основным назначением.

Чтобы уменьшить потребление пропускной способности, вам следует читать меньше данных. Вызов keepSynced(true) на узле будет поддерживать этот узел в syn c до тех пор, пока приложение активно. Если узел регулярно меняется, и вам нужны данные только время от времени, это почти гарантированно приведет к потере пропускной способности. Здесь также цель синхронизации узла состоит не в том, чтобы уменьшить использование полосы пропускания, а в том, чтобы сохранить эти данные "fre sh" в случае, если они необходимы, когда пользователь не подключен.

К вашим вопросам:

  1. Согласно [документации], прослушивателя ValueEvent должно быть достаточно для кэширования данных, почему он не работает в моем случае?

Это невозможно точно сказать, почему данные не кэшируются. Но если ваш onDataChange не вызывается, можно с уверенностью предположить, что данные также не будут записаны в кэш диска.

Первый шаг к устранению неполадок состоит в реализации onCancelled, что вам следует никогда оставить пустым. Его минимальная реализация:

override fun onCancelled(p0: DatabaseError) {
    throw p0.toException();
}
Будет ли эта синхронизация истинно увеличивать потребление пропускной способности, поскольку она постоянно проверяет наличие обновлений? Будет ли эта синхронизация выполняться верно, даже если моя активность будет уничтожена?

Когда Вы звоните ref.keepSynced(true), он подключает пустой слушатель к ref. Это означает, что данные в ref будут постоянно обновляться в памяти (и если вы включите постоянство диска в кеше) в течение всего времени, пока приложение работает.

Как уже говорилось ранее, если данные часто обновляются и используются нечасто, это может в конечном итоге использовать большую полосу пропускания, чем простое подключение прослушивателя, когда это необходимо. Как уже говорилось ранее: вы должны вызывать ref.keepSynced(true), когда вам нужно, чтобы данные узла были свободными sh.

Невозможно сказать для каждого сценария, какое влияние оказывает синхронизация узла на использование полосы пропускания. , Вам придется измерить и экстраполировать на основе понимания того, что на самом деле делает каждый API, и для чего он предназначен.

Если я установлю keepynced true для ссылки на мою базу данных, размер которой составляет 100 КБ, если внутри моей ссылки происходит дочернее обновление, которое будет изменено на 1 КБ. Будут ли загружены эти 100 КБ в следующий раз или только 1 КБ?

Ни то, ни другое. В этом случае Firebase выполняет так называемый delta syn c. SDK вычисляет список хэшей для локальных данных и отправляет их на сервер. Сервер сравнивает их со своими собственными хешами, а затем отправляет обратно только те данные, которые изменились. Результат, как правило, должен быть меньше, чем отправка обратно всего снимка, но насколько меньше, зависит от того, сколько данных в местоположении и сколько было изменено.

Также см .:

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...