i'm trying to do a recording application with flash ( IE9, requirement ) - i'm wondering whether there is a possibility to get uninterrupted access to user's file system to save parts of a long recording ( more than 2 hours ) ( large parts 200 mb). So that when by mistake, he closes browser tab, his recording progress is not totally lost ?
Yes, this is possible. Sort of.
Because you're publishing for web, you're limited to the FileReference class, which can only save to the local filesystem by opening a save dialog box for the user.
However, you can cache the recording data with SharedObject without needing user intervention every time.
Note that the user will need to authorize storage once you try to cache data beyond the storage limit (default 100k). This is an improvement over FileReference as the user won't need to click something for every caching operation, but it still requires user intervention at least once to allow the process.
Related
I understand the textbook definition/concept of localstorage and sessionstorage. I really should write, "I believe I do". My 2 questions are as follows:
Can you provide a clear example of when one (localstorage/session storage) should be used over the other? Basically, what data should
be stored in the localstorage and what data would be stored in the
sessionstorage? I have read a list of country codes could go into the local storage, I ponder if this is really right. What would happen if the country list changes, wouldn't the old list always display and how would one refresh the list upon a change?
What happens when the localstorage and/or sessionstorage hits
the max mb for the browser?
1) The data you store either with LocalStorage or SessionStorage depends on how you want your user to experience your application.
For example, if you have a login page, the username should be something kept with LocalStorage, because probably this same user will log into your app multiple times and not necesseraly wants to save the password in the browser. Having the username in LocalStorage will make it easier for the user to login in the future, even after closing the browser or changing tabs.
But, if you have a system that provides services like booking, searching or maybe comparison between products, storing data with SessionStorage would be better, because although the values set by the user while using your application won't change during this session, they might - and probably will - change in a future use of your application.
In your case specifically, and repeating what was said in the beginning, even with changes in your list of countries, you need to have in mind how your user will interact with your system and what are your needs with the data that is being provided by them.
Don't forget you can always clean the localStorage if you need, and set new values as they appear.
2) There's a really good explanation of how the browser responds to a full memory here
I am building a web app, where there is a lot of user specific data. Prior to HTML5, I would have just saved all this data in a database on the server.
Eg: Username, List of books read.
With HTML5 Local storage, I imagine I could just store it on the client. The problem is, what if there are multiple users using the same client (computer & web browser).
Is there a way to separate the user data for each user in local storage ? Is this not what HTML5 Local Storage was intended for ?
In most cases you should clear the localStorage for each user for privacy reasons.
However, if the data is generic, non-identifiable data, something simple like a high score from a game, then yes a object based storage might be ok.
If the data is anything specific, or identifiable, deleting the localStorage after a timeout, logout, or login is preferred.
Clear the localStorage:
localStorage.clear();
and start fresh after one of the above events.
Otherwise a web-savvy person could view the browser's localStorage content and each user's data.
Store an array of 'users' object. Html 5 Local Storage is quite flexible. You can then search for the object using an id for example.
Using ActionScript, When several clients are connected to a remote SharedObject it functions as a 'live' data exchange, where all clients are updated whenever any client makes a change. It obviously works because only the server has actual access to the file, and simply broadcasts the change.
Is there a way to enable the same type of functionality between several local swf files loaded into stand-alone projectors?
Specifically: A user can run several (some have 60 or more....) instances of an online game client, which includes a map of the identical virtual world. Rather than have every instance load the same map into memory, it would save MUCH (The map is larger than Georgia..) memory if they could all access the same data.
A sharedObject would obviously create file access headaches since each client needs read/write access. Is there some other technology available or a way to load an auxiliary swf perhaps to function as the 'server'?
Yes you can do similar things with Flash SharedObject. You've pretty much found the name, you just had to search for it :)
Check out the getLocal method - it allows you to access a locally persisted information from multiple files.
Few things:
Keep in mind to set a proper localPath in order to be able to read the data from multiple files.
Keep in mind that this storage is first limited, and this limitation is commonly defined by the user.
Another crucial thing is that the local storage can be denied by the user. Which means that it's not sure that you can always write there.
While it can be used with a Flash Media Server, the standard local storage won't dispatch events when the property is changed. You need to create your own script if you need real time updates.
Hope that helps :)
Is it possible to make localStorage and/or IndexedDB offline data permanent?
I am planning to make a completely offline HTML5 app and want the data to never get deleted, unless and otherwise the user knowingly does so.
I do not want the data to be deleted even after the app is closed, system is shutdown or something like CCleaner is run.
What you are looking is persistent storage as defined in Quota Management API. Currently none of the browser implemented it.
However IndexedDB data, even thought temporary storage, are persist over application life cycle.
I'm creating a game for a viral marketing campaign where roughly one in 100 players will get access to a QR code for some exclusive thingamajig. The game will require information to be pulled and pushed from the database since the game environment will 'grow' over time.
I haven't decided yet on how to do this, but I had 2 ideas, each with their concerns:
solution 1: connect the SWF to a database
concern: I have decompiled SWF's before and it is remarkably easy. How do I protect my database credentials against this?
solution 2: have the SWF connect to .php scripts that query a database. This way my database connection credentials are safe inside the php file.
concern: However, how do I then make sure the PHP script isn't being accessed by a custom script? Somebody could get the php URL from the SWF source and just access it directly, bypassing the flash app.
You need to understand one thing.
Anything client side can be and if money is involved probably will be hacked.
With that being said, security is about layers, the more layers involved, the harder it is to be hacked.
There are many methods you can use and combine together that will take out of the picture the average swf hacker.
The first place I would start with is never ever store sensitive info in the client.(IE: server compiled SWFs)
If you have data there, it can be grabbed/modified.
Next, I would encrypt all data sent to and from the swf with a public key. This key would expire frequently. To obtain the key the swf would have to pass user credentials(login).
On the server side you can track the user via a session.
You can add socket connection support with a persistent connection
httsp, SSL, TSL
And many many more options to pick from.
The choice is yours.
The real question however, is how far do you want to go.
I would rule Solution 1 out right away for just the reason you identified.
So let's just talk about how to circumvent the solution 2 issues.
What I see is a common way to handle this is having the server side script handle the generation of these special items. If you look at a lot of online flash games, I'm sure you'll agree that Flash is responsible for the UI almost entirely, the rest is handled by the backend. This of course limits the type of games you can do this way.
There is also another way. If you could have your swf generated by your backend, you could store session data that would only be good for a limited time. This of course wouldn't have to be the same swf that stores all of your game assets but just the classes that are required to communicate with the backend. Generating the server interaction swf dynamically would then allow to store session important data and encrypting it with a different key every time, so that if someone does hack it, it would limit what they can do with it, as a new session would require new credentials.