I'm creating a univeral app to capture a photo or video and upload it to SharePoint via its REST API. The flow of the current prototype is simple:
On the main page, the user clicks a button to capture a photo or video
A photo or video can be captured using the CameraCaptureUI API
The user is redirected to a page where he/she can enter some metadata
If the user clicks the upload button, the file is sent to SharePoint and the user is sent back to the main page
If the user clicks the cancel button, he/she is sent back to the main page
All of this is working, but I'm not sure what to do with the StorageFile after it's not needed anymore. On the phone, the file is saved to some default location. I'm not copying it to the picture library or whatever, after the file is uploaded (or the user cancelled out) I no longer need it on the device.
Should I take care of deleting this StorageFile myself or does the OS handle this when the app is suspended or closed? I want to avoid that the app is slowly eating more and more storage space over time, for example because the user is closing it before the file is uploaded.
On a side note: I'm not using a background task to upload the file. The user needs to monitor the upload (progress bar) and retry if it fails. If the file cannot be uploaded because there's no internet connection or because SharePoint is down, I no longer care about it.
Everything depends on a place where you have stored the file. If you have used local folder for this, then deleting the file may be a good choice as it won't take memory no more.
Nevertheless from what I read, your scenario just fits to temporary location. If you use ApplicationData.TemporaryFolder then you don't need to take care of the file as the OS will handle it when needed:
The temporary app data store works like a cache. Its files do not roam and could be removed at any time. The System Maintenance task can automatically delete data stored at this location at any time. The user can also clear files from the temporary data store using Disk Cleanup. Temporary app data can be used for storing temporary information during an app session. There is no guarantee that this data will persist beyond the end of the app session as the system might reclaim the used space if needed.
Related
I am curious to know about the real-world solution for dealing with forms that have large amount of data/fields or a wizard like interface (may be using AngularJS kind of GUI framework), especially if we want to take care of a scenario where the data persistence on back-end fails.
My questions are:
Is the form data saved in session, in the interim, (or may be on Browser itself using the JS libraries) till the user saves the final "Save" button?
Or is the data saved each time (i.e. on the user traversing from one screen to another using "Previous" or "next" buttons) on to a back-end database?
What happens if the form data has to be sent to an external web-service (instead of a database) and the call fails (due to timeout or any error)?
There is a strong chance that we will lose all the user entered data (unless we save it in a local database and re-try the web-service call later).
Do any of the caching f/w have any role to play here (including any AngularJS caching f/w)?
Thanks for sharing your knowledge.
I have a hotel page with information about a hotel and when you click book you go to a booking page.
When you get to the booking page you will then be asked for name details etc.
However I need to pass other data from the hotel page to it such as a summary of the hotel and the room configration as a confirmation before they book(so I need this data again).
My question is if the user refreshes the page?
Will using $state or UIrouter or having the data as a service cause the data to be lost? Like flash or non persistent data?
If so would I be better when the user clicks the button it saves it as a session cookie in which I can pick it up on the next page?
It will. You need to persist the information somewhere durable. Either send it to the server, or store it client side using localStorage or something similar.
Refreshing the browser is like restarting the app, only it (if you designed your application correctly) pick up in the same location you were at. However, all information is wiped, except for durable stores like local data, cookies, local database, and obviously it won't affect the server.
So choose the most appropriate durable store based on your application's needs.
I am allowing users to upload a profile picture of themselves. It involves these steps:
User chooses an image file to upload
Server receives the file through AJAX and stores with a name of temp_userid.jpg
Server returns the image location to the page so the user can see it and make adjustments
The user clicks Save Changes which posts back to the server as final confirmation of the image update
Server loads the temp_userid.jpg, makes the adjustments e.g scale and crop, overwrites any existing profile image, and then finally deletes the temp_userid.jpg image
This works fine as long as the user saves his changes. If the user decides to leave the page, then the temp_userid.jpg file is still on the server and is never deleted. Some of the images can be over 5MB in size which I don't want on the server.
How could I go about cleansing the folders of temp files in a safe manner? I was thinking I could:
Attempt to delete the temp image file whenever the user logs in to his account. The only slight issue here is that the user may never log-in again. But that could be dealt with using some kind of account expiration check.
Attempt to delete all images with a prefix of 'temp_' from the server periodically. The risk here is that it deletes it while a user is still making adjustments to his image which would be terrible!
Are there any better ways of doing this? I'm tagging this as ColdFusion because thats the application server I'm using.
How can i persist user details in angularjs unless user logs out of the system?
My header is using a variable called user, so when the user logs in successfully, i set the user attributes from REST response.Once , user is set then using ng:show and $scope.watch i change parts of the header and show welcome 'username'.
The issue comes when user again refreshes the page, in that case User is reset and user sees the landing page header.How can i correct it?How can i persist the User value unless user logs out of the system?Should i set user in rootScope or is there any other better way to handle this?
This is an open-ended question and to really answer it, I'd need to know what your back end looks like and what your security requirements are.
I can see a two ways forward:
(1) If can rely on and trust cookies for security, you could just log the user in with data from cookies just like you log them in via the REST response. The cool thing about this is that, to the user, it would be instantaneous (the next option won't be).
(2) Have a separate controller that handles the header that will always make a request to the server for user data (logged in or not). SEN does something like this (and it drives me crazy btw). I don't know if you have a SEN account, but if you do, you could log in/out and try it out. You'll see that when you hit the page initially, you get a loading screen, but even after that loads, the header even has a little "Signing in..." loading widget itself.
You can use the local storage (a key-value pair HTML5 storage) to store the information and retrieve it on page load. There is a very simple library for this, if you don't want to write javascript yourself, called Lawnchair. Otherwise google for html5 local storage tutorials.
I need to store user sessions when they login to my website. Plan it this:
Store user session in memcache when user signs in.
All user activities are tracked so log all that in memcache only so i dont have to hit the DB every second writing "A shared a photo" "A clicked on a link.."
When user logs off OR the connect is cut then write an edt time and copy all data to the DB.
Now problem is if memcache crashes then all this data gets lost. So what is the work around?
Do note: I am tracking all user activity including mouse clicks, so i cannot be writing to the DB every second for each user hence i was suggested to use memcache but i am open too other ideas also.
What you're describing is pretty much why we wrote membase in the first place.
I've used memcachedb but have moved to redis and it rocks!