未找到Adobe AIR SharedObject-Android/iOS-更新时

正如标题所述，我在iOS和Android上的用户报告说，当我将更新推送到受尊敬的店面时，他们的保存数据已被删除。游戏在应用程序加载和退出时正确保存和恢复数据。我没有更改任何保存信息位置或包名称。。。只是简单的bug修复、构建、推送

任何澄清都会很有帮助，或者我应该采用建议的冗余数据备份方案，以确保最终用户体验从此不会受到负面影响。我还想更好地了解如何测试它，因为不允许发布包更新市场上安装的应用程序

var so:SharedObject = SharedObject.getLocal("storage"); 
var u:User;
if(so.data != null){
    u = so.data.user;
}

trace("Loading application...");

if(u != null){
    trace("LOADING SAVE DATA");
    user = u;
}else{
    trace("NO SAVE DATA EXISTS");
    user = new User();
}

---

我已经发现了这个问题的原因，Adobe似乎也发现并修复了这个问题（从AIR 3.5开始）

SharedObject存储在根据应用程序使用的SWF命名的目录中，因此如果应用程序运行的是“myApp.SWF”，SharedObject将存储在“myApp”目录中。如果更改此SWF的名称（即AIR项目对应的XML构建表配置文件），任何后续构建都将在新位置存储其SharedObjects

此bug中描述的问题专门针对iOS，其中应用程序没有将SharedObject存储在上面描述的相应SWF位置，而是存储在项目XML构建表中由“filename”属性表示的单独位置

我还发现Adobe确实允许在移动平台上使用SharedObject进行持久存储

我已经为将来的版本开发了一个简单的备份，以避免将来的更新无法持久保存SharedObject时出现冗余

/** the last timestamp a deep save was completed */
private var mLastSave:Number = -1;


/**
 * save the state of the globals object and all of its
 * sub objects.
 * @warning
 * all objects must implement variables in a "public" state.
 * Private variables are not saved within the persistance manager
 */
public function save():void{
    var so:SharedObject = SharedObject.getLocal("storage");
    so.data.user = user;
    so.flush();
    saveDeep();
}


/**
 * Save the SharedObject to denoted mobile applicationStorageDirectory.
 */ 
public function saveDeep():void{
    // save on first application save or after
    // every 5 minutes
    if(mLastSave == -1 || mLastSave < getTime() + 300000){
        mLastSave = getTime();

        var file:File = File.applicationStorageDirectory.resolvePath("userSave");
        var fileStream:FileStream = new FileStream(); 
        fileStream.open(file, FileMode.WRITE);
        var ba:ByteArray = new ByteArray();
        ba.writeObject(user);
        fileStream.writeBytes(ba);
        fileStream.close();
    }   
}


/**
 * Load the application from the SharedObject be default
 * if the SharedObject DNE attempt to load from the 
 * applicationStorageDirectory, if neither exist
 * create new User object
 */ 
public function load():void{

    registerClassAlias("user", User);

    // Create/read a shared-object named "userData"
    var so:SharedObject = SharedObject.getLocal("storage"); 
    var u:User;
    if(so.data != null){
        u = so.data.user;
    }

    trace("Loading application...");

    if(u != null){
        trace("LOADING SAVE DATA");
        user = u;
    }else{
        trace("NO SAVE DATA EXISTS");
        var file:File = File.applicationStorageDirectory.resolvePath("userSave");
        if(file.exists){
            trace("Found userSave backup -attempting to load");
            var fileStream:FileStream = new FileStream(); 
            fileStream.open(file, FileMode.READ);
            var ba:ByteArray = new ByteArray();
            fileStream.readBytes(ba);
            fileStream.close();
            try{
                user = (ba.readObject() as User);
            }catch( e : EOFError ){
                trace("SharedObject did not exist, attempted userSave load, failed");
            }
        }else{          
            user = new User();
            trace("created New user...");
        }
    }
}

/**完成深度保存的最后一个时间戳*/
私有变量mLastSave:Number=-1；
/**
*保存全局对象的状态及其所有属性
*子对象。
*@警告
*所有对象都必须以“公共”状态实现变量。
*私有变量不保存在持久性管理器中
*/
公共函数save（）：void{
var so:SharedObject=SharedObject.getLocal（“存储”）；
so.data.user=用户；
所以，flush（）；
saveDeep（）；
}
/**
*将SharedObject保存到指定的移动应用程序存储目录。
*/ 
公共函数saveDeep（）：void{
//第一次应用程序保存时或之后保存
//每5分钟
如果（mLastSave==-1 | | mLastSave

ShareObjects并不意味着是长期持久存储。它们就像浏览器cookies。虽然我没有足够的经验在手机上使用它们来确定，但我的猜测是，当你更新你的应用程序时，这就像清除那些cookie所在的缓存。据我所知，它们不是用来填充cookie的，因为它们在对象序列化中非常有用，例如，包含最高分的用户对象。以下是Adobe员工对这个问题的两个回应：注意，他们没有提到反对使用SharedObject来完成这样的任务。我认为使用AIR与使用flash player不同，在flash player中，用户可以选择擦除所有数据，或者不允许共享对象开始。这不是一个我在广播中探索过的领域。SharedObjects对于序列化存储来说非常简单/方便。您从哪里获得“userSave”目录名？我面临着一个类似的问题，在应用程序更新后我找不到一个持久目录。我已经抛弃了SharedObjects。它们对于持久化大类数据来说真是太棒了，但我发现自己在一开始就不需要数据持久化的时候，却虐待了系统，过于依赖数据持久化。同样从可读性的角度来看，在一个类中有一堆公共变量会产生一些困难的调试情况。我已经转移到XML来持久化数据，现在避免了这种情况。在安卓和iOS上进行了几次应用程序更新之后，我们的许多用户对他们的数据丢失感到愤怒。