Choix pour le stockage de non-consommables in-App Purchase

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 image/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

Réponses

  • Apple peut héberger des contenus, mais je ne connais pas la limite.



    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".
  • GranDavGranDav Membre
    décembre 2012 modifié #3
    Ce que rapporte Smy est en effet la meilleure solution : les contenus côté serveur. Cependant cela n'enlève pas le fait qu'un nouveau produit ajouté doit forcément passer par l'étape de validation et donc par un nouveau binaire (alors que cela n'a pas forcément lieu d'être si tu télécharges du contenu).



    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 :-)
  • Merci pour passer un peu de temps à  me répondre image/smile.png' class='bbc_emoticon' alt=':)' />



    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.
  • C'est la solution que j'ai adopté.

    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.
  • samirsamir Membre
    'GranDav' a écrit:




    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 :-)




    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
  • 'samir2303' a écrit:
    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/ image/smile.png' class='bbc_emoticon' alt=':)' />
  • StephSteph Membre
    Je viens de mettre en place ce type d'application pour un client.



    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é image/smile.png' class='bbc_emoticon' alt=':)' />
Connectez-vous ou Inscrivez-vous pour répondre.