Disable/restore testing | developer.brewmp.com Disable/restore testing | developer.brewmp.com

Developer

Disable/restore testing

When an application is disabled, the MOD, BAR, and SIG files are deleted from the application directory. Any other file types included in the installation or dynamically generated by the application will persist within the directory for subsequent use when the application is restored. However, files in the installation package will overwrite any existing files in the directory when the application is restored. For this reason, user data intended to be persistent across the disable/restore process should not be stored in files that exist in the original installation package. NSTL will likely fail your application if user data (preferences, scores, etc.) are lost during this test.

Thanks for the information. Is this available anywhere in the documentation?
I think that the test case mentions only that disabling the app partially deletes AUT files, but it doesn't mention that all files are overwritten when the application is being restored.
Is there a way that, as a developer, I could possibly know how this process exactly works without reading your post?

Thanks for the information. Is this available anywhere in the documentation?
I think that the test case mentions only that disabling the app partially deletes AUT files, but it doesn't mention that all files are overwritten when the application is being restored.
Is there a way that, as a developer, I could possibly know how this process exactly works without reading your post?

Apologies for the hijack, but my question doesn't deserve its own thread:
In the game I am writing, I have chosen to complete eschew using BREWs .bar files in favour of having my own resource file. This resource file will be downloaded with the .mod, and will never be altered in any way at any stage. The size of this resource file is about 160k.
Firstly, is this approach completely OK with respect to TBT? I assume it is, and I believe I have heard of other people doing it, but I had a fit of paranoia earlier today and want to make sure it will not cause any problems ;).
Secondly, it looks like my resource file will stay resident even if my app is disabled - since the resource file is quite large, this (I suppose) makes disabling my app in order to save space a little pointless. I have heard vague rumours that simply renaming it to myapp.bar will cause it to be deleted when my app is disabled, which sounds like a Good Thing from the point of view of the user wishing to save space. Since the file does not have the structure of a .bar file, and will never be accessed as one, will this rather messy solution lead to any problems with respect to TBT?
Many thanks,
Simon
Edit:
One more question, while I'm at it :). Upon pressing CLR on my main menu, the game will show a closing splash screen which will have to be cleared via a keypress from the user before the app actually exists. This runs counter to some of the BREW UI requirements, so I wondered if this single infraction would be enough to cause my app to fail TBT?
Edit2:
Thanks, charliex :)

Apologies for the hijack, but my question doesn't deserve its own thread:
In the game I am writing, I have chosen to complete eschew using BREWs .bar files in favour of having my own resource file. This resource file will be downloaded with the .mod, and will never be altered in any way at any stage. The size of this resource file is about 160k.
Firstly, is this approach completely OK with respect to TBT? I assume it is, and I believe I have heard of other people doing it, but I had a fit of paranoia earlier today and want to make sure it will not cause any problems ;).
Secondly, it looks like my resource file will stay resident even if my app is disabled - since the resource file is quite large, this (I suppose) makes disabling my app in order to save space a little pointless. I have heard vague rumours that simply renaming it to myapp.bar will cause it to be deleted when my app is disabled, which sounds like a Good Thing from the point of view of the user wishing to save space. Since the file does not have the structure of a .bar file, and will never be accessed as one, will this rather messy solution lead to any problems with respect to TBT?
Many thanks,
Simon
Edit:
One more question, while I'm at it :). Upon pressing CLR on my main menu, the game will show a closing splash screen which will have to be cleared via a keypress from the user before the app actually exists. This runs counter to some of the BREW UI requirements, so I wondered if this single infraction would be enough to cause my app to fail TBT?
Edit2:
Thanks, charliex :)

i use custom bin files on a lot of apps, and no worries
some of them are .bin files, amonst other things, no problems.
it depends which tester you get, I've had varying problems with CLR key usage and qualcommm, yours might be an issue, generaly clr on main menu quits out. You might be able to argue it, you might not. It might pass the first time, and not the second. i can't recall if i've done a confirmation on clr key quit before, don't believe so. end maybe, but not clr

i use custom bin files on a lot of apps, and no worries
some of them are .bin files, amonst other things, no problems.
it depends which tester you get, I've had varying problems with CLR key usage and qualcommm, yours might be an issue, generaly clr on main menu quits out. You might be able to argue it, you might not. It might pass the first time, and not the second. i can't recall if i've done a confirmation on clr key quit before, don't believe so. end maybe, but not clr

Quote:Originally posted by ziemowit
Thanks for the information. Is this available anywhere in the documentation?
I think that the test case mentions only that disabling the app partially deletes AUT files, but it doesn't mention that all files are overwritten when the application is being restored.
Is there a way that, as a developer, I could possibly know how this process exactly works without reading your post?
I guess the simple answer on that is no...I created an FAQ item on the website to better explain the process.

Quote:Originally posted by ziemowit
Thanks for the information. Is this available anywhere in the documentation?
I think that the test case mentions only that disabling the app partially deletes AUT files, but it doesn't mention that all files are overwritten when the application is being restored.
Is there a way that, as a developer, I could possibly know how this process exactly works without reading your post?
I guess the simple answer on that is no...I created an FAQ item on the website to better explain the process.

I've done confirmation on CLR-key quit before and had it pass TBT. In that case it called for pressing CLR again to exit. We've had apps that go to an end-splash and timed out to quit--I think those have been through TBT as well...

I've done confirmation on CLR-key quit before and had it pass TBT. In that case it called for pressing CLR again to exit. We've had apps that go to an end-splash and timed out to quit--I think those have been through TBT as well...

I appologize for hijacking this back to the original post subject but I have a question.
How does one go about doing this. Lets say that during loading, test.txt was put on the phone. If user edits this file and saves it, I'm guessing it now needs to be persistant.
Do I need to save the file under a different name?
If yes, once the user puts the app back on the phone, how is the app supposed to know that the file exists in that directory?
Is it normal for apps to check for files in the directory they are installed on?
Same thing goes for a game, how are the high scores kept persistant?
This is a very good subject and I appreciate you starting this thread.
David

I appologize for hijacking this back to the original post subject but I have a question.
How does one go about doing this. Lets say that during loading, test.txt was put on the phone. If user edits this file and saves it, I'm guessing it now needs to be persistant.
Do I need to save the file under a different name?
If yes, once the user puts the app back on the phone, how is the app supposed to know that the file exists in that directory?
Is it normal for apps to check for files in the directory they are installed on?
Same thing goes for a game, how are the high scores kept persistant?
This is a very good subject and I appreciate you starting this thread.
David

I have updated the FAQ on this topic to address these issues...let me know if you have any other questions.

I have updated the FAQ on this topic to address these issues...let me know if you have any other questions.

Previously NSTL would pass apps that stored high scores in the prefs. What will happen to applications that have been previously passed using this method, and are now being submitted for new phones?
Tom

Previously NSTL would pass apps that stored high scores in the prefs. What will happen to applications that have been previously passed using this method, and are now being submitted for new phones?
Tom

Thanks Max, that answers my questions quite nicely.

Thanks Max, that answers my questions quite nicely.

Vexxed wrote:Previously NSTL would pass apps that stored high scores in the prefs. What will happen to applications that have been previously passed using this method, and are now being submitted for new phones?
Tom
There's absolutely no problem with storing high scores in the preferences...was the wording in the FAQ unclear?

Vexxed wrote:Previously NSTL would pass apps that stored high scores in the prefs. What will happen to applications that have been previously passed using this method, and are now being submitted for new phones?
Tom
There's absolutely no problem with storing high scores in the preferences...was the wording in the FAQ unclear?

mohlendo wrote:There's absolutely no problem with storing high scores in the preferences...was the wording in the FAQ unclear?
I was under the impression that the preferences (GetPrefs / SetPrefs) data is cleared when the application is disabled. If this isn't the case, then I guss I'm just confused and putting high scores and other information in the Prefs is fine.
Tom

mohlendo wrote:There's absolutely no problem with storing high scores in the preferences...was the wording in the FAQ unclear?
I was under the impression that the preferences (GetPrefs / SetPrefs) data is cleared when the application is disabled. If this isn't the case, then I guss I'm just confused and putting high scores and other information in the Prefs is fine.
Tom