pour Android: Je dois enregistrer des données de manière permanente, mais aussi être capable de modifier (et évidemment lire). Ces données ne doivent pas être accessibles par l'utilisateur - il peut contenir des éléments comme un highscore, qui ne doit pas être édité par l'utilisateur.
J'aurais (et j'ai déjà déjà) utilisé Vous pouvez enregistrer des fichiers directement sur le stockage interne du périphérique. Par
Par défaut, les fichiers enregistrés sur le stockage interne sont privés à votre
l'application et d'autres applications ne peuvent pas y accéder (ni la
utilisateur). Lorsque l'utilisateur désinstalle votre application, ces fichiers sont
enlevé.
C'est fondamentalement ce dont j'ai besoin - Qu'en est-il des bases de données SQLite ou de la mémoire partagée? Sont-ils mieux adaptés pour économiser (petites quantités de) données?
Aussi: est-il généralement recommandé de gérer les données "secrètes" de manière différente en interne? (comme ne pas l'économiser (en interne) comme entier / chaîne, mais une sorte de cryptage) stockage interne , mais je ne sais pas à quel point il est en sécurité. ici dit:
3 Réponses :
Utiliser SharedPreferences est ce que vous voudrez peut-être. Il enregistre des données dans un fichier XML profondément dans les cavernes du répertoire / Data / Directory. L'utilisateur ou d'autres applications ne peut pas y arriver à moins que le téléphone a des autorisations racines.
http://developer.android.com/reference/andrroid/content/ SharedPreferences.html
Les préférences partagées ne sont-elles pas utilisées comme option de stockage accessible de différentes applications? Ou est-ce que je viens de me manquer?
C'est ce que je pensais d'abord aussi. C'est seulement utilisable à l'intérieur du paquet que je pense. développeur.android.com/guide/topics/data/data- Stockage.html # PR EF
Donc, c'est accessible comme le stockage interne, juste avec XML au lieu de jouer du texte?
À droite mais Android s'occupe de cela via une API incroyablement simple à utiliser. Vous obtenez l'instance de l'application des préférences partagées et commencez à lire. Ou, obtenez un éditeur de l'instance de SharedPreferences, d'écrire des modifications et de commettez les modifications. Assez simple - je l'aime! Il suffit de regarder les liens que je vous ai donné.
Ouais, je les ai lu, n'était pas sûr de l'accès - mais semble assez simple / cool à utiliser pour des données simples.
SharedPreferences utilise un simple fichier XML stocké dans votre application de stockage interne: Pastebin.com/t1hinmss
Oui, mais root @ Android . Vous êtes root. Par conséquent, votre argument n'est pas valide. Alors que je suis d'accord avec @sirlate, un score élevé n'est pas quelque chose que vous voulez protéger comme une carte de crédit (à moins que cela ne se traduit par une valeur réelle / des prix. Cela signifierait beaucoup plus de travail avec SSL et des trucs comme celui-ci.) Si l'un des Les 15% des utilisateurs d'Android qui ont une racine veulent sortir le plaisir du jeu et changer un nombre qui n'a aucune incidence sur la vie réelle (à moins qu'il ne se traduit par des prix réels), alors c'est leur perte, pas la vôtre.
Non Ce n'est pas sûr, l'utilisateur peut modifier des fichiers sur les périphériques et l'émulateur enracinés. Il vaut mieux utiliser le cryptage, mais le cryptage n'est pas sûr à 100%, en fait des geeks expérimentés peuvent craquer votre cryptage. Je suggère de sauvegarder des données critiques qui ne doivent pas être accessibles ni manipuler par l'utilisateur sur votre serveur Web non sur les périphériques de l'utilisateur.
Pourquoi un émulateur? Tant que je ne distribuais pas le .apk, ne devrait-il pas être «impossible» de le faire courir sur un émulateur? (Ou pouvez-vous simplement obtenir l'apk lors du téléchargement de GooglePlay?)
Les utilisateurs enracinés peuvent extraire l'APK de / Data / App.
@benjaminschwalb check Ce out.
peut-il être consulté (peut-être seulement lire?) à travers un périphérique enraciné?
Il peut être lu et écrit à.
Il peut contenir des choses comme un highscore, qui ne doit pas être éditée par l'utilisateur.
Ce sont les données de l'utilisateur, pas la vôtre. C'est le périphérique de l'utilisateur, pas le vôtre. Par conséquent, l'utilisateur peut modifier ces données si l'utilisateur souhaite, tant que leurs données sont stockées sur leur appareil.
Maintenant, si vous vouliez empêcher quelqu'un d'autre de modifier ces données, le cryptage, avec un mot de passe fourni par l'utilisateur, est une mesure raisonnable. Cela semblerait inutile pour un score élevé de jeu.
Sinon, si vous ne souhaitez pas qu'ils modifient ces données, ne le stockez pas sur leur appareil.
Si c'est un score élevé global sur certaines échelles, je ne laisserais même pas l'utilisateur le modifier. (serait tricher et non juste pour tous les autres)
@BENJAMINSCHWALB: Soit ceci est une copie locale d'un "highscore global" (auquel cas l'utilisateur édité de l'utilisateur ne compterait pas, et il serait réécrit par vous de toute façon après une opération de réseau ultérieure), ou Vous avez une architecture très étrange où certains utilisateurs aléatoires contiennent la copie principale de vos meilleurs scores.
Le highscore n'était qu'un exemple - Prenons l'ID utilisateur: Je dois l'enregistrer quelque part localement, et transmettez-le à la DB pour savoir quel utilisateur à mettre à jour - cela ne doit pas non plus être changé (il est attribué automatiquement une fois, et devrait rester inchangé) - ou peut-être un fichier de configuration, où je stocke des choses comme "combien de score / or / ... dois-je obtenir pour xy", ils ne doivent jamais être modifiés non plus. (juste des exemples, probablement il y a de meilleurs moyens de faire tout cela, mais ce n'est pas vraiment la question ici)
@Benjaminschwalb: l'utilisateur de l'utilisateur est quelque chose que l'utilisateur sait déjà (et est donc lié à un mot de passe et n'est pas quelque chose que l'utilisateur peut modifier SANS le mot de passe de l'autre compte), ou l'ID utilisateur est une chaîne générée de plus de 50 caractères. (Et donc, l'utilisateur est peu susceptible de pouvoir modifier pour proposer une valeur valide). En ce qui concerne le "fichier de configuration", ne stockez pas les règles du jeu localement ou vivez avec le fait que les erreurs peuvent manipuler ces règles.
Donc la réponse reste simplifiée: rien n'est sûr sur l'appareil, pas même le code
@Benjaminschwalb: Oui. Bienvenue dans la programmation côté client. :-) Avoir des barricades légères (par exemple, mettre des données sur le stockage interne, vous devez donc avoir une racine à désordre avec les données) est une bonne chose, en particulier lorsque ces barricades sont «fruits à suspension faibles» d'un niveau de développement-effort de développement point de vue. Et j'investissais dans une architecture qui optimise la flexibilité pour que vous modifiez les implémentations côté client ou côté serveur de votre logique initiale. Au-delà de cela, attendez de voir si votre jeu est un succès avant d'investir des tonnes d'essayer d'ériger d'autres barricades; Ils ne comptent que si vous avez réellement des utilisateurs.
En cas de doute, utilisez le cryptage!
Cela a été posé beaucoup, plusieurs fois. Si un utilisateur est enraciné, ils peuvent voir / changer quoi que ce soit. Si vous voulez le rendre plus difficile, chiffrez-le. Même dans ce cas, vous devez stocker votre clé quelque part, une personne dédiée peut donc le craquer.
Rien n'est sûr sur un appareil enraciné. L'utilisateur racine peut accéder à tout fichier, base de données, ... Même la mémoire (mais l'utilisateur typique ne saurait pas comment). Le cryptage aide mais les utilisateurs avancés pourraient décompiler votre APK et extraire la partie Crypt.
Donc, la seule option de stockage sûre «vraiment» serait n'importe où, mais sur l'appareil lui-même? (comme sur un serveur Web - toujours pas complètement sûr, mais c'est un autre sujet)
Oui, c'est fondamentalement juste. Cela dépend de combien de sécurité vous voulez. S'il s'agit simplement d'une liste personnelle de score élevée, allez pour internes / SharedPrafs. Qui s'en soucie si l'utilisateur édite son propre score? Si cela allait sur un classement quelque part, rangez-le partout où le classeur est (serveur).