search

eshcherbin / save-the-moment

SPbAU educational Android project
0 stars 0 forks source link

Created MomentManager and LoadMomentsTask #4

Closed eshcherbin closed 7 years ago

eshcherbin commented 7 years ago

Создан менеджер моментов, который пока что не умеет подгружать моменты извне. Создан LoadMomentsTask, closes #2.

egor-bogomolov commented 7 years ago

Мы почитали про Content Provider и не поняли, действительно ли он нам нужен. Судя по тому, что пишут, он используется для обмена данными между приложениями, это не наш случай. Можно ли ограничиться стандартными способами работы с БД, например с SQLite, и хранить в Drive ее копию? При возможности (наличии интернета) пытаться синхронизировать.

krinkinmu commented 7 years ago

18 нояб. 2016 г. 17:33 пользователь "egor-bogomolov" < notifications@github.com> написал:

Мы почитали про Content Provider и не поняли, действительно ли он нам нужен. Судя по тому, что пишут, он используется для обмена данными между приложениями, это не наш случай.

Не только, более того, Activity тоже можно брать из других приложений, но это же не значит, что они вам не нужны.

Но можно обойтись и обычной БД, хотя большого выигрыша вы не получите.

Можно ли ограничиться стандартными способами работы с БД, например с SQLite, и хранить в Drive ее копию?

зачем хранить БД в Drive? Суть как раз в том что бы хранить её локально.

При возможности (наличии интернета) пытаться синхронизировать.

Ну да что-то такое и подразумевалось, в идеале надо иметь возможность подписываться на изменения в Drive, но я не знаю есть ли там такая возможность.

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub, or mute the thread.

egor-bogomolov commented 7 years ago

зачем хранить БД в Drive? Суть как раз в том что бы хранить её локально.

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

Мое видение сейчас такое:

  1. Нужно как-то хранить список всех моментов и базовую (текстовую) информацию о них. Это можно делать в виде текстового файла, тогда для работы с ним его будет нужно парсить. По сути мы будем работать с ним как с БД, почему бы сразу не хранить БД?
  2. Нужно хранить различную медиа-информацию (аудио, фото, видео). Для этого предлагается под каждый момент создать отдельную папку в Drive, в которой это все будет лежать.
  3. Нужно реализовать возможность отправки момента другим пользователям. Для этого предлагается создавать папку, в которую копируется момент, через сервер отправлять запрос другому пользователю, тот в ответ на запрос копирует информацию из папки в свой Drive и список моментов.
krinkinmu commented 7 years ago

18 нояб. 2016 г. 18:02 пользователь "egor-bogomolov" < notifications@github.com> написал:

зачем хранить БД в Drive? Суть как раз в том что бы хранить её локально.

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

Мое видение сейчас такое:

Нужно как-то хранить список всех моментов и базовую (текстовую) информацию о них. Это можно делать в виде текстового файла, тогда для работы с ним его будет нужно парсить. По сути мы будем работать с ним как с БД, почему бы сразу не хранить БД?

Мой поинт в том, чтобы иметь доступ к БД без интернет, если хранить её только в Drive гарантий, что к ней есть доступ не будет.

По поводу текстового файла - это плохая идея, потому что при обновлении файла вам придётся его фактически переписывать полностью - а со временем он может стать большим. Я бы предложил хранить момент в виде отдельного каталога, и все что к нему относится делать в виде файла в этом каталоге. Но в конечном итоге нужно смотреть, что вам позволяет Drive API - посмотрите какие оповещения об изменениях он может предоставить, если вообще может, как перечислять файлы и папки и т. д. и т. п.

Нужно хранить различную медиа-информацию (аудио, фото, видео). Для этого предлагается под каждый момент создать отдельную папку в Drive, в которой это все будет лежать. Нужно реализовать возможность отправки момента другим пользователям. Для этого предлагается создавать папку, в которую копируется момент, через сервер отправлять запрос другому пользователю, тот в ответ на запрос копирует информацию из папки в свой Drive и список моментов.

У другого пользователя должна быть именно копия момента? Может ли он его изменять? Будут ли эти изменения в копии независимы от исходных данных?

Отправлять это расширить ссылку? А что если момент после отправки и перед тем как его скопируют изменится/удалиться?

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub, or mute the thread.

egor-bogomolov commented 7 years ago

Про Drive еще почитаем и чуть позже ответим.

У другого пользователя должна быть именно копия момента? Может ли он его изменять? Будут ли эти изменения в копии независимы от исходных данных?

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

Отправлять это расширить ссылку? А что если момент после отправки и перед тем как его скопируют изменится/удалиться?

Отправляется момент в том виде, в котором он сейчас находится. Если он будет изменен, то на отправленной копии это никак не отразится. Да, отправка - расшаривание ссылки.

krinkinmu commented 7 years ago

18 нояб. 2016 г. 18:33 пользователь "egor-bogomolov" < notifications@github.com> написал:

Про Drive еще почитаем и чуть позже ответим.

У другого пользователя должна быть именно копия момента? Может ли он его изменять? Будут ли эти изменения в копии независимы от исходных данных?

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

Отправлять это расширить ссылку? А что если момент после отправки и перед тем как его скопируют изменится/удалиться?

Отправляется момент в том виде, в котором он сейчас находится. Если он будет изменен, то на отправленной копии это никак не отразится. Да, отправка - расшаривание ссылки.

Всмысле перед отправкой вы фиксируете состояние момента и после этого его нельзя менять? Или создание копию в Drive, и шарите копию? Первый вариант выглядит странным с точки зрения пользователя - мой момент, что хочу то и делаю, а при втором варианте нужно подумать, когда удалять копию и стоит ли её вообще удалять.

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub, or mute the thread.

egor-bogomolov commented 7 years ago

Создаем копию в Drive и ее шарим. У себя, конечно, момент все еще менять можно.

krinkinmu commented 7 years ago

On Fri, Nov 18, 2016 at 7:09 PM, egor-bogomolov notifications@github.com wrote:

Создаем копию в Drive и ее шарим. У себя, конечно, момент все еще менять можно.

ок, такой вариант мне нравится, пока удалением можно не запариваться.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/eshcherbin/save-the-moment/pull/4#issuecomment-261569950, or mute the thread https://github.com/notifications/unsubscribe-auth/ABH4c9BQZWXsfmUTGRcE9_jGci9amdzwks5q_c2kgaJpZM4Kwqem .

eshcherbin commented 7 years ago

Не только, более того, Activity тоже можно брать из других приложений, но это же не значит, что они вам не нужны.

Но можно обойтись и обычной БД, хотя большого выигрыша вы не получите.

Просто если наследовать MomentManager от Content Provider, то его интерфейс будет несколько однобоким. По нашей задумке в функциональность MomentManager также будет включена загрузка медиа-контента, но тогда получится какой-то некрасивый интерфейс (например, методы insert и delete для работы с моментами и getMediaContent для работы с медиа-контентом).

Впрочем, можно, в принципе, сделать отдельный MediaContentManager. Тут я уже не знаю, какое решение лучше.

По поводу текстового файла - это плохая идея, потому что при обновлении файла вам придётся его фактически переписывать полностью - а со временем он может стать большим. Я бы предложил хранить момент в виде отдельного каталога, и все что к нему относится делать в виде файла в этом каталоге. Но в конечном итоге нужно смотреть, что вам позволяет Drive API - посмотрите какие оповещения об изменениях он может предоставить, если вообще может, как перечислять файлы и папки и т. д. и т. п.

Drive API действительно позволяет создать службу, которая следит за изменениями файлов в Drive. Видимо, тогда и правда остановимся на варианте "локальная база данных, следящая за изменениями в драйве".

krinkinmu commented 7 years ago

2016-11-19 21:28 GMT+03:00 Egor Shcherbin notifications@github.com:

Не только, более того, Activity тоже можно брать из других приложений, но это же не значит, что они вам не нужны.

Но можно обойтись и обычной БД, хотя большого выигрыша вы не получите.

Просто если наследовать MomentManager от Content Provider, то его интерфейс будет несколько однобоким. По нашей задумке в функциональность MomentManager также будет включена загрузка медиа-контента, но тогда получится какой-то некрасивый интерфейс (например, методы insert и delete для работы с моментами и getMediaContent для работы с медиа-контентом).

вот этого я не понял, что значит "включена загрузка медиа-контента", всмысле он будет заниматься передачей меди файла в Drive?

Впрочем, можно, в принципе, сделать отдельный MediaContentManager. Тут я уже не знаю, какое решение лучше.\

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

По поводу текстового файла - это плохая идея, потому что при обновлении файла вам придётся его фактически переписывать полностью - а со временем он может стать большим. Я бы предложил хранить момент в виде отдельного каталога, и все что к нему относится делать в виде файла в этом каталоге. Но в конечном итоге нужно смотреть, что вам позволяет Drive API - посмотрите какие оповещения об изменениях он может предоставить, если вообще может, как перечислять файлы и папки и т. д. и т. п.

Drive API действительно позволяет создать службу, которая следит за изменениями файлов в Drive. Видимо, тогда и правда остановимся на варианте "локальная база данных, следящая за изменениями в драйве".

это должно очень упростить жизнь, в таком случае предлагаю закрыть это PR, а вместо него сделать следующее:

  1. сделать PR с базой данных и зафиксировать в каком-то виде схему базы данных и запросы к ней, ну и все это с какими-нибудь тестами, чтобы быть уверенным, что все работает, пусть пока и без Drive-а + стоит начать разбираться как правильно в Android загружать что-то из базы данных, чтобы отобразить это в активити (искать по ключевым словам CursorLoader и LoaderManager).
  2. сделать пополнение/обновление базы из Drive-а в отдельном PR, где определить в каком формате все будет храниться в Drive
  3. с медиа контентом разбираться в отдельном PR

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/eshcherbin/save-the-moment/pull/4#issuecomment-261730836, or mute the thread https://github.com/notifications/unsubscribe-auth/ABH4cwzolywcq4Pai6FFu8erRUvVUdppks5q_z_MgaJpZM4Kwqem .