Im trying to find out how to save highscore data to the isolated storage on windows phone. I have searched numerous things and have found nothing working. Anyone know how I can do this?
The following answer was taken from this MSDN entry:
http://msdn.microsoft.com/en-us/library/ff604992.aspx
XNA Game Studio 4.0 Refresh does not provide access to writeable
storage on Windows Phone. To access such storage, you'll need to use
classes from the System.IO.IsolatedStorage namespace.
For Windows Phone projects, Visual Studio automatically adds the
assembly containing System.IO.IsolatedStorage to your project. There
is no need to add any additional references to your project.
Examples for writing data to the Isolated storage:
protected override void OnExiting(object sender, System.EventArgs args)
{
// Save the game state (in this case, the high score).
IsolatedStorageFile savegameStorage = IsolatedStorageFile.GetUserStoreForApplication();
// open isolated storage, and write the savefile.
IsolatedStorageFileStream fs = null;
using (fs = savegameStorage.CreateFile(SAVEFILENAME))
{
if (fs != null)
{
// just overwrite the existing info for this example.
byte[] bytes = System.BitConverter.GetBytes(highScore);
fs.Write(bytes, 0, bytes.Length);
}
}
base.OnExiting(sender, args);
}
Related
When I use the Download method of the FileReference class, everything works fine on Desktop and Android, but I get an error on iOS.
This is the code:
var req = new URLRequest(url);
var localRef:FileReference = new FileReference();
localRef.download(req);
On iOS I'm getting an Alert:
Download Error
File downloads not supported.
I already tried to NavigateToUrl() and it asks save the file in Dropbox or another App.
How can I fix this error?
You shouldn't use FileReference on mobile (or AIR, in general, though it does open the Load/Save dialog on desktop so there can be some use there). You should instead use File and FileStream, which give you far more control over the file system.
In this case, you could try to use File.download() and save it to File.applicationStorageDirectory, but I don't know if it will have any difference since it extends FileReference.
What I generally do is use URLStream instead of URLLoader. It gives you access to the raw bytes of the file you are downloading and then use File and FileStream
So something like (and this is untested off the top of my head, though I have used similar in the past):
var urlStream:URLStream = new URLStream();
urlStream.addEventListener(Event.COMPLETE, completeHandler);
urlStream.load(new URLLoader('url');
function completeHandler(e:Event):void {
var bytes:ByteArray = new ByteArray();
urlStream.readBytes(bytes);
var f:File = File.applicationStorageDirectory.resolvePath('filename');
var fs:FileStream = new FileStream();
fs.open(f, FileMode.WRITE);
fs.writeBytes(bytes);
fs.close();
}
Now, obviously, there is a lot more you want to account for (errors, progress, etc). That should be enough to point you in the right direction, however.
It's possible to create a full download manager using this method (something I did for an iOS project two years ago), since you can save as-you-go to the file system rather than waiting until Event.COMPLETE fires (using the ProgressEvent.PROGRESS event). That allows you to avoid having a 500MB file in memory, something most devices can't handle.
I am trying to upload so many files via Azure Blob Storage .NET api and using with the current latest version 4.0.1. In ASP.NET MVC application i use async action method to upload via await blobFile.UploadFromStreamAsync but it really doesn't work and even i don't see an exception. It silently stops in that method without success.
But if i change action method to none-async and upload via blobFile.UploadFromStream method then everything to works well. I may uploaded via async way with 1% success rate that means very very low stability.
Do you experience same thing ? Is it bug in Storage Api implementation ?
Here is short example. One is async and the other one is none async action methods. There is no any problem if i upload small files but problem appears on large downloads. In this example UploadBlobSec method upload in short time but UploadBlob takes endless time.
public async Task UploadBlob()
{
var storageAccount = CloudStorageAccount.Parse(ConfigurationManager.ConnectionStrings["AzureStorage"].ConnectionString);
var blobContainer = storageAccount.CreateCloudBlobClient().GetContainerReference("files");
var blobFile = blobContainer.GetBlockBlobReference("song.mp3");
using (var stream = new WebClient().OpenRead("http://apolyonstorage.blob.core.windows.net/files/e8b1a1fa-8791-44dc-92ce-1a67a62f7b0f.mp3"))
{
await blobFile.UploadFromStreamAsync(stream);
}
}
public void UploadBlobSec()
{
var storageAccount = CloudStorageAccount.Parse(ConfigurationManager.ConnectionStrings["AzureStorage"].ConnectionString);
var blobContainer = storageAccount.CreateCloudBlobClient().GetContainerReference("files");
var blobFile = blobContainer.GetBlockBlobReference("song.mp3");
using (var stream = new WebClient().OpenRead("http://apolyonstorage.blob.core.windows.net/files/e8b1a1fa-8791-44dc-92ce-1a67a62f7b0f.mp3"))
{
blobFile.UploadFromStream(stream);
}
}
Code snippet looks fine - although I am not sure what the application around it is doing. Have you turned on server logs to see what is happening server side? For large files you should see the async upload translated into a couple of PutBlocks and then a PutBlockList. If you don't see the PutBlockList them maybe something strange is happening in your application.
Then assuming you do see the operations in the server logs that obviously means the operations are occurring. At that point look at the E2ELatency numbers vs ServerLatency I think you will see a large difference with E2Latency being much higher as it incorporates the time spent client side - and it would be interesting to see if your client network could be contributing to the problem. For example on my connection the e2elatency on the first PutBlock was 1346 ms vs 137 for ServerLatency.
For more information on logging take a look here.
Jason
I am aiming to create an application where the user can take a picture of their face, which includes an overlay of a face cutout. I need the user to be able to click the screen and for the application to save the picture, mask it with the same face cutout, and then save it to the applications storage.
This is the first time using AIR on IOS with Actionscript3. I know there is a proper directory that you are supposed to save to on IOS however I am not aware of it. I have been saving other variables using SharedObjects...
E.g:
var so:SharedObject = SharedObject.getLocal("applicationID");
and then writing to it
so.data['variableID'] = aVariable;
This is how I access the front camera and display it. For some reason to display the whole video and not a narrow section of it, I add the video from the camera to a movieclip on the stage, 50% of the size of the stage.
import flash.media.Camera;
import flash.media.Video;
import flash.display.BitmapData;
import flash.utils.ByteArray;
import com.adobe.images.JPGEncoder
var camera:Camera = Camera.getCamera("1");
camera.setQuality(0,100);
camera.setMode(1024,768, 30, false);
var video:Video = new Video();
video.attachCamera(camera);
videoArea.addChild(video);
Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;
Capture_Picture_BTN.addEventListener(TouchEvent.TOUCH_TAP, savePicture);
function savePicture(event:TouchEvent):void
{
trace("Saving Picture");
//Capture Picture BTN
var bitmapData:BitmapData = new BitmapData(1024,768);
bitmapData.draw(video);
}
I apologize if this is the wrong way of going about this I am still fairly new to Actionscript as it is. If you need any more information I will be happy to provide.
You can only save ~100kb of data via SharedObject, so you can't use that. It is meant solely to save application settings and, from my experience, is ignored by AIR devs because we have better control over the file system.
We have the File and FileStream classes. These classes allow you to read and write directly to and from the device's disk, something not quite possible on the web (the user is the one who has to save/open; can't be done automatically).
Before my example, I must stress that you should read the documentation. Adobe's LiveDocs are among the best language/SDK docs available and it will point out many things that my quick example on usage will not (such as in-depth discussion of each directory, how to write various types, etc)
So, here's an example:
// create the File and resolve it to the applicationStorageDirectory, which is where you should save files
var f:File = File.applicationStorageDirectory.resolvePath("name.png");
// this prevents iCloud backup. false by default. Apple will reject anything using this directory for large file saving that doesn't prevent iCloud backup. Can also use cacheDirectory, though certain aspects of AIR cannot access that directory
f.preventBackup = true;
// set up the filestream
var fs:FileStream = new FileStream();
fs.open(f, FileMode.WRITE); //open file to write
fs.writeBytes( BYTE ARRAY HERE ); // writes a byte array to file
fs.close(); // close connection
So that will save to disk. To read, you open the FileStream in READ mode.
var fs:FileStream = new FileStream();
var output:ByteArray = new ByteArray();
fs.open(f, FileMode.READ); //open file to write
fs.readBytes( output ); // reads the file into a byte array
fs.close(); // close connection
Again, please read the documentation. FileStream supports dozens of read and write methods of various types. You need to select the correct one for your situation (readBytes() and writeBytes() should work in all cases, though there are instances where you are should use a more specific method)
Hope that helps.
the code below was developed for shared memory. when it is used on two services or two user app, it work pretty well. but when the memory is created in service, the application can not find the memory. what is wrong with this code?
in service:
mmf=MemoryMappedFile.CreateNew("ALFMap",10000);
bool mutexCreated;
Mutex mutex=new Mutex(true,"ALFMutex",out mutexCreated);
stream=mmf.CreateViewStream(0,1000);
BinaryWriter writer=new BinaryWriter(stream);
writer.Write("I am reza dadkhah");
mutex.ReleaseMutex();
in user app:
using (MemoryMappedFile mmf = MemoryMappedFile.OpenExisting("ALFMap",MemoryMappedFileRights.FullControl))
{
Mutex mutex=Mutex.OpenExisting("ALFMutex");
mutex.WaitOne();
using (MemoryMappedViewStream stream=mmf.CreateViewStream(0,1000))
{
BinaryReader reader = new BinaryReader(stream);
textBox1.Text=reader.ReadString();
}
mutex.ReleaseMutex();
}
Have you tried writing the content of the memory in a file using your application ? Try that first and confirm the value is in the memory or not.
I'm working on a little hack sending MIDI messages from an app using RtMidi as a wrapper for CoreMIDI on OS X. I use RtMidiOut::openVirtualPort("MyAwesomePort") so I can select my app as an input source in a DAW.
However, if my program closes and I open it again, my DAW does not recognize the input device as the same port, despite being given the same name.
I was originally using pyrtmidi, so went and verified the behavior writing in C++ directly with RtMidi. "My DAW" in this case is Reaper 4, but I've duplicated the behavior in Pro Tools, Logic, and MuLab.
I know it's possible to retain some uniqueness of a virtual midi port, since MidiKeys behaves just as I'd like my application to behave: my DAWs remember it even if MidiKeys closes and re-opens while my DAW is still running.
So I dug into the RtMidi source, and the CoreMIDI wrapper seemed straightforward enough. All that the MIDISourceCreate asks for is a string. The client parameter is (what I presume after browsing the docs) an identifier for my application, it being a client of the CoreMIDI services.
void RtMidiOut :: openVirtualPort( std::string portName )
{
CoreMidiData *data = static_cast<CoreMidiData *> (apiData_);
if ( data->endpoint ) {
errorString_ = "RtMidiOut::openVirtualPort: a virtual output port already exists!";
error( RtError::WARNING );
return;
}
// Create a virtual MIDI output source.
MIDIEndpointRef endpoint;
OSStatus result = MIDISourceCreate( data->client,
CFStringCreateWithCString( NULL, portName.c_str(), kCFStringEncodingASCII ),
&endpoint );
if ( result != noErr ) {
errorString_ = "RtMidiOut::initialize: error creating OS-X virtual MIDI source.";
error( RtError::DRIVER_ERROR );
}
// Save our api-specific connection information.
data->endpoint = endpoint;
}
So I looked at the MIDISourceCreate documentation, and read this:
After creating a virtual source, it's a good idea to assign it the same unique ID it had the last time your application created it. (Although you should be prepared for this to fail in the unlikely event of a collision.) This will permit other clients to retain persistent references to your virtual source more easily.
This seems like exactly what I'm looking for. Except I have no idea how to assign the source a unique ID. The out parameter for MIDISourceCreate is a MIDIEndpointRef, which according to the docs is just typedef'd to a UInt32 down the line. So I hypothesized that maybe I should keep track of this UInt32, but that seems like a bad idea.
After digging through all of this I feel like I'm hitting a bit of a brick wall. How do I retain the uniqueness of my MIDI port in between runs of my application?
According to the docs,
kMIDIPropertyUniqueID
The system assigns unique ID's to all objects. Creators of virtual endpoints may set this property on their endpoints, though doing so may fail if the chosen ID is not unique.
So maybe something like this:
// Try to set the ID if it's saved.
if (savedUniqueId) {
OSStatus result = MIDIObjectSetIntegerProperty(endpoint, kMIDIPropertyUniqueID, myUniqueId);
if (result == kMIDIIDNotUnique) {
savedUniqueId = 0;
}
}
// If not saved, record the system-assigned ID
if (!savedUniqueId) {
OSStatus result = MIDIObjectGetIntegerProperty(endpoint, kMIDIPropertyUniqueID, &savedUniqueId);
// Handle the error?
}
The unique ID is typedefed to a SInt32. I've made the assumption that 0 is an invalid unique ID, which is at least true for connections (the docs for kMIDIPropertyConnectionUniqueID say it's "non-existant or 0 if there is no connection").
I'm not sure how you maintain long-term uniqueness with only 32 bits, but it'll hopefully be sufficient for relaunches of your app.