В App Purchase: динамически добавлять неиспользуемые элементы

Я разрабатываю приложение, в котором пользователь может приобретать цифровые карты, диаграммы и т.д. Я хотел бы обернуть их в приложения-покупки. Дело в том, что я не знаю заранее, сколько карт будет, поскольку я получаю их из другого источника из сети. Может быть сотни.

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

Существует три различных типа диаграмм.

Мое первое решение состояло в том, чтобы создать три расходных элемента и позволить им купить их; это работало нормально, но, к сожалению, Apple отказалась от этого, так как они требуют, чтобы графики были "не потребляемыми".

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

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

Любые идеи, как сделать это масштабируемым?

Ответ 1

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

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

Другой вариант: Компания, с которой я работала, изначально настроила это очень просто. Наше приложение запустится, и мы поговорим о php script, который передал нам идентификаторы магазина приложений, которые у нас были в нем. В этот момент мы проверим их и применим действительные возвращения. Этот параметр позволил нам изменить наши покупки приложений через iTunes Connect, а затем в script, и все было отлично.

Ответ 2

Это более старая статья, но у меня был один и тот же вопрос, и выяснилось, что теперь есть возможность динамически предоставлять не-расходные материалы путем размещения списка идентификаторов продуктов на вашем собственном сервере:

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

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

Отсутствует механизм выполнения для получения списка всех продуктов настроенный в iTunes Connect для определенного приложения. Вы ответственны для управления списком ваших приложений и предоставления информацию в ваше приложение. Если вам нужно управлять большим количеством продуктов, рассмотрите возможность использования массовой загрузки и загрузки XML в iTunes Connect.

Руководство для разработчиков приложений для разработчиков Apple

Ответ 3

Если вы приобрели их напрямую через IAP или через какую-либо "валюту" в приложении, вы могли бы упростить объем работы, который вам нужно будет сделать в будущем, используя систему именования, которая гарантировала бы уникальное имя карты за каждый предмет, который вы хотите продать. Например:

 NSString *myMapName = [NSString stringWithFormat:@"%@%@%@%@", app_identifier, map_type, top_left_corner_location, scale];

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

В случае, когда вы используете валюту (которая звучит легче, чем альтернативный вариант, и это то, что, похоже, делает много больших приложений) вам просто нужно сделать хэш с некоторыми данными на вашей карте, чтобы люди могли "Угадайте код, который вы храните в своей цепочке связок /plist, и волшебным образом получаете все свои карты, не платя:)

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

Надеюсь, это поможет!

Ответ 4

Я думаю, что ваш лимит на предметы - это нечто вроде 10 000 или около того.

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

Приложение загружает названия диаграмм и соответствующий идентификатор продукта с вашего сервера, а затем вы просто покупаете продукт.

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