SnegSneg
Снежана Соседова

(30) речь не о программной выгрузке, а о том, что пользователь теперь может самостоятельно делать бекап, до 8.3.9 этого не было. Правда спрятали эту функцию так далеко, что пользователи ее и не находят, что в нашем случае и хорошо:) А пройти пользователю нужно вот такой путь - список приложений - меню этой базы - Изменить - Администрирование - Резервное копирование. На выходе если заглянуть в папку с бекапом - там 1CD файл с кучей служебных, вот только просто открыть такой файл на настольной платформе не получится.
Программно создать такой бекап нельзя, как и узнать, что пользователь его развернул. Поэтому чтобы перестраховаться в случае, если используете синхронизацию, нужно добавить свою какую-то проверку: например, записывать дату последней синхронизации на мобильном и на сервере для каждого устройства, и сверять эти даты.

(15) просто в вашей первой формулировке прослеживалась связь, значит не так прочитала)

(2) насчет бекапов: платформенный механизм хоть и есть, но очень уж "далеко" спрятан для рядового пользователя, и особенно далеким он становится, когда после поломки базы платформа просто сообщает об ошибке и закрывается, т.е. "список приложений" в мобильном приложении 1С уже никак не достать; + он сохраняет копии на том же устройстве, и пользователю тогда нужно самостоятельно те копии доставать и переносить в облако, если он сильно обеспокоен сохранностью данных:)
Ну и когда используется синхронизация с сервером, та платформенная копия (аналог dt в настольной 1С) тоже не особо поможет, т.к. тут разве что разрывать связь с сервером и заново регистрировать восстановленную базу и подключать другие устройства.

А насчет примеров кода: в докладе ставилась цель хотя бы "на пальцах" успеть рассказать идеи и предоставить пищу для размышлений, изначально это не статья и точно не мануал:)

Но интересно, какая именно часть не до конца понятна/недостаточно подробно изложена и требует примеров кода?

(9) не очень понимаю, в чем связь плана обмена, xml и http-сервиса - это же 3 отдельных никак не связанных вещи, и уж точно не взаимозаменяемые :)
А в каком формате вы передаете данные вместо xml? json?

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

(3) в узле плана обмена "сидит" даже не устройство, а конкретная база на конкретном устройстве - на сервере соответственно храним ИдентификаторПодписчикаДоставляемыхУведомлений этой базы (см. метод ПолучитьИдентификаторПодписчикаУведомлений() ) и какой пользователь там работает, чтобы знать какие куда отправлять данные.

Создать популярное мобильное массовое приложение – достаточно сложно. В этой статье мы хотим поделиться своим опытом и знаниями в этой сфере.

В целом всё очень понравилось. Спасибо организаторам!
Очень радует, что уже есть видео и можно посмотреть доклады, которые не получилось посетить непосредственно на конференции.
И да, ожидала какое-то более яркое закрытие конференции после танцев с бубном на открытии