Choix pour le stockage de non-consommables in-App Purchase
John Barbier
Membre
Bonjour,
Pour ma prochaine application j'aimerai pouvoir distribuer des contenus ayant la forme de .PDF ou de .MOV
J'aurai plus d'une centaine de PDF et environ plusieurs dizaines de .MOV, ca fera en tout environ 2Go de stockage, si on achète tout /smile.png' class='bbc_emoticon' alt=':)' />
Il m'a semblé comprendre que que si j'encapsule des contenus, de type non-consomables, avec une version de l'application lectrice, le in-App Purchase va me permettre de :
`- débloquer leur lecture dès l'achat.
- distribuer par lot mes contenus au rythme des Review de l'application lectrice
Mais ceci ne me semble adapté que pour de faibles volumes de contenus
Dans le cas de volumes de stockage importants, avec cette solution, l'application pourrait être énormément plus volumineuse que si on télécharge les contenus à la demande.
Il me semble que je suis dans ce cas avec mes 2Go : Ca me semble bien beaucoup pour une application si l'utilisateur n'achète que 10 ou 15 contenus à terme.
C'est pour valider une alternative au stockage encapsulé que je viens vers vous.
Existe-til une alternative à l'encapsulation dans l'application ?
Pour quel choix stockage de données opteriez-vous pour mes non-consommables ?
Est-il possible de télécharger depuis mon hébergeur (PHP, mySQL) des contenus si Apple me dit que les contenus ont été acquis ?
Si oui, dans ce cas, en plus de déclarer les produits, faut-il faire valider les contenus par une Review ? comment ? Où puis-je lire de la documentation sur ce type de solution, si elle existe ?
Merci, d'avance pour vos réponses
Pour ma prochaine application j'aimerai pouvoir distribuer des contenus ayant la forme de .PDF ou de .MOV
J'aurai plus d'une centaine de PDF et environ plusieurs dizaines de .MOV, ca fera en tout environ 2Go de stockage, si on achète tout /smile.png' class='bbc_emoticon' alt=':)' />
Il m'a semblé comprendre que que si j'encapsule des contenus, de type non-consomables, avec une version de l'application lectrice, le in-App Purchase va me permettre de :
`- débloquer leur lecture dès l'achat.
- distribuer par lot mes contenus au rythme des Review de l'application lectrice
Mais ceci ne me semble adapté que pour de faibles volumes de contenus
Dans le cas de volumes de stockage importants, avec cette solution, l'application pourrait être énormément plus volumineuse que si on télécharge les contenus à la demande.
Il me semble que je suis dans ce cas avec mes 2Go : Ca me semble bien beaucoup pour une application si l'utilisateur n'achète que 10 ou 15 contenus à terme.
C'est pour valider une alternative au stockage encapsulé que je viens vers vous.
Existe-til une alternative à l'encapsulation dans l'application ?
Pour quel choix stockage de données opteriez-vous pour mes non-consommables ?
Est-il possible de télécharger depuis mon hébergeur (PHP, mySQL) des contenus si Apple me dit que les contenus ont été acquis ?
Si oui, dans ce cas, en plus de déclarer les produits, faut-il faire valider les contenus par une Review ? comment ? Où puis-je lire de la documentation sur ce type de solution, si elle existe ?
Merci, d'avance pour vos réponses
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Sinon, le plus "simple" est d'héberger les contenus sur ton site, et de vérifier la transaction d'achat coté serveur avec Apple lors de la livraison. La partie vérification est dans les specs "Verifying Store Receipts".
La solution que je préfères et que je met en général en oeuvre est d'utiliser les produits Apple Consommables en tant que jetons d'achat pour valider le téléchargement de tes produits côté serveur. Cela permet de t'affranchir de la validation si tu souhaites ajouter de nouveaux produits. Néanmoins tu dois gérer des comptes utilisateurs (même invisibles) afin d'éviter à tes utilisateurs de payer deux fois du contenu déjà acheté (en cas de désinstalation / restauration / changement d'appareil).
J'ai fait une présentation à ce sujet lors des CocoaHeads Rennais à la dernière session de Novembre (http://cocoaheads.fr/rennes) ISofTom devrais prochainement les mettre en ligne :-)
Ce que je comprends c'est que, si on regarde les détails techniques de mise en place, c'est pas simple ;
surtout si j'ai à gérer des comptes utilisateurs (pour moi c'est le rôle d'Apple).
L'algorithme suivant est-il possible :
- Créer une appli qui connait les références des contenus
- Déclarer à Apple les contenus qui sont stockés dans mon site en tant que non-consommable.
Ceci pour n'avoir qu'une opération administrative à faire par contenus,
et pas avoir à gérer techniquement de limites (dates, durées, ...)
- Review à chaque ajout de lot de référence de contenus
- Disposer d'une alerte par Apple quand un téléchargement doit être effectué.
(nouveau téléchargement ou re-téléchargement)
- Trouver une solution minimum pour sécuriser le flux de téléchargement.
Il n'y a pas d'alerte par Apple, tu geres l'achat et le telechargement dans ton appli.
Tu declenches un processus d'achat ou de re-achat (tu n'es pas obligé de distinguer les deux).
Au cours du processus, tu recois la confirmation d'achat et la tu lances le telechargement.
Youpi j'ai trouvé le présentateur de CocoaHeads sur les achats InnApp Purchase.
@GranDav : Est-ce que je peux avoir plus de précisions sur cette partie SVP ? ( mise en ouevre de la méthode des jetons pour éviter la mise a jours de l'application a chaque soumission d'un nouveaux produit.)
Merci
Je viens de te répondre dans le thread que tu as crée : http://forum.cocoacafe.fr/topic/10435-achat-inapp-purchase-at-ajout-nouveau-produit/ /smile.png' class='bbc_emoticon' alt=':)' />
Je lui ai fait une interface de publication en Ruby On Rails + une REST API côté serveur. L'application discute avec l'API et renvoi les infos. Les fichiers sont sur un amazon s3 (environ 6go de données).
C'est la solution la plus propre, car l'application fait actuellement environ 5 Mo et non 6 Go comme ce serait le cas si j'avais tout intégré /smile.png' class='bbc_emoticon' alt=':)' />