Но можно найти кого-то с аккаунтом чтобы пустили твои устройства к ним

привет. столкнулись со следующей проблемой. Используем sqlite db заполненную изначально на сервере. Используем либу https://github.com/andpor/react-native-sqlite-storage Вшиваем базку в апп и пытаемся с ней работать. В целом все хорошо. Но есть на этапе разработки нюансы под iOS. При последующих сборках выглядит так, что база ложится в какой-то кеш/хранилище и обновление ее руками и создание референсов заново ничего не меняет. Проблема характерна для iOS только, на андроиде такого нет. Собственно вопрос: как это лечить? воркэраунды? Полагаю если переименую файл бд - заведется, но это как-то убого так постоянно ренеймить . Кто сталкивался?

Products[key].name скорее всего должно быть

Ну, зависит от структуры данных, но я предполагаю, что в этом проблема

если такую сагу вызвать несколько раз проблем не будет?

привет. столкнулись со следующей проблемой. Используем sqlite db заполненную изначально на сервере. Используем либу https://github.com/andpor/react-native-sqlite-storage Вшиваем базку в апп и пытаемся с ней работать. В целом все хорошо. Но есть на этапе разработки нюансы под iOS. При последующих сборках выглядит так, что база ложится в какой-то кеш/хранилище и обновление ее руками и создание референсов заново ничего не меняет. Проблема характерна для iOS только, на андроиде такого нет. Собственно вопрос: как это лечить? воркэраунды? Полагаю если переименую файл бд - заведется, но это как-то убого так постоянно ренеймить . Кто сталкивался?

собрать так cd android && ./gradlew assembleRelease gradle.properties добвить android.enableAapt2=false у меня после добавления этой строки решилась проблема

Вы за неделю это не решили? 😄 Я когда-то на C++ писал ядро для мобильного приложения (только версия iOS вышла), там база sqlite деплоилась с приложением, а обновлялась по АПИ отдельному с сервра. Хватило дня чтения документации по iOS и гуглинга чтоб понять и спроектировать как надо.

скажем так, пока это не основная проблема, и она не является блокером. и к ней тупо не возвращались. я уже прочел доки, и выглядит так, что вариант сделать рид-онли или указать локейшен. решил просто еще раз озвучить, мб кто-то с таким сталкивался.

Т.е. когда я это делал, у нас приложение можно было технически зарелизить без этой стартовой базы (и так и было в процессе разработки и тестирования), просто тогда бы приложение на старте ещё долго и много качало бы по сети, а с этой базой пользователь сразу мог видеть данные, пусть и немного устаревшие.

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

У меня есть массив объектов [ {id: 1, text: “aaa”, order: 1}, {id: 2, text: “bbb”, order: 2}, {id: 3, text: “ccc”, order: 3}, ] Если этот массив пересортировали, то мне надо пройтись по всему массиву и переписать все значения order ? [ {id: 2, text: “bbb”, order: 1}, {id: 1, text: “aaa”, order: 2}, {id: 3, text: “ccc”, order: 3}, ] Или есть другой способ более компактный? При таком способе приходится делать 2 дорогие операции 1 - map для всех элементов 2 - пересохранять все элементы (для 3х может не критично, а для миллиона уже критично)

При такой постановке задачи - да, надо пройтись по массиву и переписать значения order. При этом я не понимаю (опять же, при такой постановке задачи), почему надо пересохранять все элементы? (`for (let i=0; i<arr.length; i++) arr[i].order = i+1`) Подозреваю, что на самом деле нужны совсем другие структуры данных )

В данный момент у меня задача решена немного иначе, на массивах, которые хранятся в firestore (без order)

Т.е. сейчас порядок сортировки определяется естественным порядком следования элементов (индексом в массиве). Вы хотите добавить ещё один параметр, который опять же определяет сортировку. Зачем? Чтоб теперь было два "source of truth" и их синхронизировать? )

Нет, я не хочу добавлять параметр В том решении, как сейчас - он совсе не нужен, так как есть естевенный порядок массива, и если я перемещаю элементы в предалх массива и сохраняю его “как есть” в firestore то и извлекаю его в том же порядке Но мне кажется это немного дорогим удовольтсвием (хотя и работает быстро) постоянно сохранять массив (на больших объемах скорее всего будет не так быстро) Я ищу способ решать задачу пересортировки более дешевым способом

<View></View> мой норкотек...

Нет, я не хочу добавлять параметр В том решении, как сейчас - он совсе не нужен, так как есть естевенный порядок массива, и если я перемещаю элементы в предалх массива и сохраняю его “как есть” в firestore то и извлекаю его в том же порядке Но мне кажется это немного дорогим удовольтсвием (хотя и работает быстро) постоянно сохранять массив (на больших объемах скорее всего будет не так быстро) Я ищу способ решать задачу пересортировки более дешевым способом