Как удобнее всего спроектировать хранение данных в приложении, с возможность их обновления/добавления?
Здравствуйте!
Опыт у меня небольшой, делал только несколько простых приложений, без публикаций в гуглплей.
Сейчас хочу сделать удобное приложение, которое может быть будет популярным и на котором, теоретически, можно будет заработать немного золотых в будущем. Рассчитываю на максимум 500000 пользователей, но заработать какие-либо деньги на нем будет довольно сложной задачей, особенно с первого приложения для гуглплей, поэтому бюджет у меня минимальный.
Простое приложение со (статическим?) текстовым контентом под Android, без каких-либо аутентификаций и других усложнений.
Запускается приложение, появляется список контента, детальные страницы и другие подобные экраны с чисто фронтэндным функционалом, т.е. без возможности отправления/изменения пользователем каких-либо данных в "главную" БД(т.к. у каждая БД своя) и без возможности взаимодействия друг с другом.
Встал вопрос о хранении данных и их последующим обновлении/удалении/добавлении.
Я читал несколько статей на эту тему, понял, что есть несколько вариантов:
1. "зашить" данные прямо в apk
2. подгружать все данные по сети
3. комбинированный - "зашить какую-то базовую часть", а подгружать только при обновлении/добавлении данных
На мой взгляд, удобнее всего - 3 вариант, но я этот (и 2-й) подход отверг, т.к. не хочу тратится на хостинг, сервер, на бэкэнд или на backendless сервисы, потому что, в конечном итоге, на это все равно придется тратится.
Может быть я что-то упускаю, может быть не знаю, какого-то подхода к решению подобных задач, не хочу полностью сделать приложение, а потом окажется, что есть какие-то ограничении в гуглплей или что приложение будет очень неудобно поддерживать и обновлять?
Реально ли и разумно ли использовать метод 1 и какие у него будут недостатки?
Так же буду очень рад ссылкам на ресурсы/книги/курсам именно по проектированию коммерческих приложений, с хорошей архитектурой и различными подходами для решения задач под Android.
Денис Загаевский, Наверное, неудачное слово.. хотел написать, что апп содержит только списки текстовой информации, показывает пользователю детальное описание каждого элемента и так же дополнительные фичи без взаимодействия пользователя с сервером, с друг другом. Но информация со временем добавляется или обновляется, а скорость обновления старой и добавления новой информации на клиенте не критична.
Оно нужно, потому что целевой пользователь заинтересован в данной информации.
Только один недостаток - это большой начальный размер приложения, если данных будет очень много.
В целом для любого "контентника" лучше всего хранить данные локально, а обновлять базу с обновлением самого приложения в gplay.
Спасибо за ответ! Я посмотрел ограничения в Google Play, 100 Мб (50Мб для Android версии < 2.3).
+ можно загружать 2 файла по 2 Гб максимум рядом с APK, а это, прямо скажем, за глаза.
Можно положить рядом с APK файл с БД из которого при установке считать все данные или просто текстовый файл с инфой в json формате, при установке просто распарсить данные с него и удалить.
Сейчас такой файл весит около 2Мб, по окончании скорее всего будет максимум 10Мб, так что даже в лимит 100Мб можно легко уложиться.
Еще момент, это то, что можно запросы к бэкенду залогировать и потом стянуть всю информацию из БД в один клик. Хотя из БД, организованной локально, в папке приложения наверное стянуть информацию даже легче...
