Алексей

Паттерн репозиторий используется для изоляции логики хранения данных. Например:

interface UserRepository {
    function getUser($id);
    function getUsersWhichSatisfyMyCustomBuisnessRulecs(BuisnessRules $rules);
    function saveUser(User $user);
}

class InMemoryUserRepository implements UserRepository {
    private $users = [];

    function getUser($id) {
         return isset($this->users[$id]) ? 
             $this->users[$id] : null;
    }

    function getUsersWhichSatisfyMyCustomBuisnessRulecs(BuisnessRules $rules) {
         return array_filter($this->users, function (User $user) use ($rules) {
               return $user->isSatisfyRule($rules->getSomeRule());
         }
    }
    function saveUser(User $user) {
        $this->users[$user->getId()] = $user;
    }
}

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

- что нет жесткой привязки к реализации. Вы можете использовать внутри репозитория plain sql, data mapper, active record, ассоциативные массивы, файлы... ну вы поняли. Главное интерфейс заимплементить.

- репозиторий позволяет вам построить архитектуру приложения не связывая все с логикой хранения данных. Таким образом мы организуем слабую связанность системы и придерживаемся принципа единой ответственности.

martinfowler.com/eaaCatalog/repository.html

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

На днях, не позже середины следующей недели, начнем разворачивать комментарии на той же самой странице в мобильной версии. Пришли к тому же выводу, что и вы (=

Обновление от 19 января: сделали комментарии к ответам разворачивающимися на той же странице в мобильных устройствах.

Поддерживаю тех, кто сказал искать золотую середину. не вздумайте в одной папке делать более 1000 файлов или папок. Без разницы как осуществляется к ним доступ (по урл или ftp)!

Лично у меня миллионы картинок разбиты почти как советовали выше:
2274facdbca56499fe397344c633e25a.jpg лежит в 2/2/7/2274facdbca56499fe397344c633e25a.jpg
При такой структуре получаем не более 16ти папок в каждой папке.

хорошая практика, применяющаяся много где, например у Microsoft
вычисляем md5 у файла - 2274facdbca56499fe397344c633e25a
файл кладем в папку avatars/227/4fa/cdb/2274facdbca56499fe397344c633e25a.jpg

Отвечу сам себе.
Здесь есть полезная конкретная информация о технической реализации.

А если вкратце, то...

Для авторизации, регистрации используется все та же таблица 'users'. Вместе с обычной регистрацией и авторизацией, когда при регистрации (в самом простом виде) в таблицу 'users' добавляются email, password и login пользователя, а при авторизации проверяется соответствие введенных login'а и password'а существующим в базе данных, аналогичным образом используется и регистрация/авторизация через социальные сети. Только в данном случае источником данных о пользователе для его регистрации является не непосредственный пользователь, который вводит данные в форму, а соц. сеть. Регистрация в данном случае достаточно прозрачная, т.е. не видна пользователю. Схема примерно следующая (без особенностей работы Oauth-протокола):

1) Пользователь выбирает вход через соц. сеть.
2) Происходит обращение к странице авторизации в этой соц. сети, если человек еще не авторизовывался там. После ввода данных, а если он ранее авторизовывался, происходит запрос на разрешение использования его данных.
3) Если человек отказывается, то на этом конец. Если дает согласие, то выполняется перенаправление на указанную в настройках Oauth страницу сайта.
4) У каждого пользователя в соц. сетях есть свой уникальный идентификатор, который можно запрашивать. Для своей таблицы 'users' нужно добавить пару дополнительных полей (например, вот такие): auth_via (enum('native, 'vk', 'mailru', '...')) - для обозначения типа регистрации пользователя, и social_id - здесь будет храниться уникальный идентификатор в соц. сети. Если нужно хранить какие-то специфические данные этого пользователя из соц. сетей, то можно создать доп. поля для этих данных.
5) После того, как пользователь дал разрешение на использование его данных, необходимо запросить нужные данные от соц. сети, в т.ч. и идентификатор пользователя в соц. сети. Вот здесь и начинается невидимый процесс регистрации. Нужно проверить есть ли в БД пользователь с таким social_id, если нет, то вставляем social_id, данные пользователя из соц. сети, по необходимости, в БД. Все, пользователь зарегистрирован.
Если же данные о пользователе есть, то необходимо запросить актуальные данные из соц. сети, сравнить их с теми, что в базе и если они изменились, то обновить их и в своей базе данных, если нет, то просто переходим к следующему шагу.
6) Создается сессия с данными пользователя.

Таким образом, к существующей таблице "родной" регистрации пользователей сайта присоединяется, условно говоря, таблица, поля, необходимые для регистрации/авторизации через соц. сети., и друг-другу они не мешают.



Для пользователя, зарегистрированного из соц. сети пароля и логина, естественно, нет. Они нужны для авторизации. А т.к. пользователь авторизуется с помощью своих логина и пароля в соц. сети, то и указывать здесь нечего. И еще, можно при авторизации, к запросу проверки логина и пароля, добавить условие

'AND WHERE `auth_via`="native"'

, чтобы исключить пользователей, зарегистрированных из соц. сетей.

Как видно, для каждого пользователя в таблице создается внутренний (внутрисайтовый, если так можно выразиться) первичный, автоинкрементный ключ. Соответственно, нет разницы для логики сайта между пользователем, зарегистрированным через соц. сеть и через сайт. Если говорить об интернет-магазине, то, для привязки заказов к пользователю, можно использовать единый, внутренний идентификатор ID.

поменять ее нельзя, это API со стороннего сервиса

load xml — берет файл с локальной ФС, что мешает (тем или иным образом) обработать хмл (пусть даже в консоли регуляркой вырезав все ненужные item)?
Получили файл от АПИ, обработали, залили в мускул.

возможно-ли сделать в рамках такого запроса удаление из БД тех записей, id которых не найдены в файле XML?

Напрямую никак. Можно импортнуть данные из ХМЛ во временную таблицу и на основе появившихся ИД — снести из основной все лишнее (delete from table main where id not in (select from table tempforxml))

Вопрос обстоит в том, каким образом можно получить данные из item_1 которые находятся в атрибуте img. Когда я создаю в таблице поле с именем «img», туда парсятся данные из атрибута последнего тега item, и дублирования имен полей в MySQL не допустимо, а имена атрибутов поменять нельзя. Если кто знает, как еще можно обратиться к атрибуту через LOAD XML, просьба подсказать.

Напрямую нельзя. Народ извращается с load data infile с последующей работой с xml в базе, по типу такого newtover.tumblr.com/post/14858246616/mysql-load-data-from-xml. Но вряд ли это будет эффективный способ.

Случайно не в расширенном режиме добавляли apk?
В расширенном режиме помимо добавления новой, надо отключить предыдущую версию.

P.S. мобильная версия маркета обновляется быстрее веб-версии.