Expo: How to create a file in app's internal/private folder - expo

I have explored expo FileSystem APIs but it doesn't give any option to store files on app's internal folders.
All the files saved using createFileAsync API with Document dir are showing up on user's device file manager app.
Is there any way to do it without ejecting expo?

Related

Writing files to AWS Elastic Beanstalk

I have developed a web application with a Node.js backend on a local machine using Webstorm IDE. Among other things, the application creates a new unique folder and writes 7 javascript (.js) files to this folder during runtime each time a user requests a new account. Everything works properly in the local development environment.
When the application is uploaded and deployed to AWS Elastic Beanstalk, and a new user is requested though the application web page, I am receiving the following 404 (Not Found) error in the browser's Developer, JavaScript Console. The same error appears for each of the 7 files. The number 1541877962401 is the unique folder name generated by the application when a user requests a new account and user.js is one of the 7 javascript files copied to this newly created folder. savedUser is an existing folder in the file structure and is not created during runtime.
GET http://sowtest082-env.stsvxa672t.us-east-1.elasticbeanstalk.com/savedUser/1541877962401/user.js net::ERR_ABORTED 404 (Not Found)
I am guessing that the application does not have the correct permissions to create the folder and/or files in AWS?
Within the context of the Elastic Beanstalk environment, what is the best method to create a folder and copy javascript files to this folder during runtime? It is fairly easy to restructure the location of the folder and the files within it in the development environment so as to match the ASW EB environment. Reengineering the application to store the contents of these files in an AWS MySQL database engine would take a lot more work.
Bye the way, these 7 files are not tmp files and they are not config files...
Thanks...

How to open Microsoft Project file on SharePoint 2013 in client application

We have an on-premise SharePoint 2013 farm, and we have a few .mpp files stored in a library.
.xls and .doc files in the library were opening in the respective Web Apps, but the .mpp files were not.
I was getting an alert asking if I wanted to allow the website to open an app on the computer.
On selecting Allow, it was showing a prompt for getting an app for ms-project from the Store.
I changed the library to open all files in client applications, but the behavior for .mpp files persist.
Curious case is that if I open 'View properties' and click on the link, it opens in the client application.
How can I force the .mpp files to always open in the client?
We fixed this with a very simple change in the view.
We unchecked the default Name (linked to document with edit menu) column and replaced it with Name (linked to document).
Now we are able to open the .mpp file in the client application.

Transferring files to VMs via SSH web browser upload button

I was wondering where the location of the files are once they are uploaded to VM instances.
I cannot find it very easily.
I am using the below menu to upload available in ssh web browser window.
UPDATES
I managed to find the upload path of the file uploaded(see my answer below).
But I am now having problems with downloading files. I provide the full path but was unable to download it. Is there any trick to this?
I am using Safari Version 10.0.2 (11602.3.12.0.1)
Finally found the location.
Once the upload is done and you see the success message, the file will be in the users home directory.
The username that you have logged in via ssh web browser to upload the file.

Load file from "Resource Files" folder C++ Windows Application (win32)

I'm trying to load a file from the Resource Files folder inside my Windows Application (Win32) C++.
My folder structure inside Visual Studios is as following:
External Dependencies folder
Header Files folder
Resource Files Folder
Web Folder
css folder
js folder
images folder
login.html
The only way i've been able to access the login.html file is by doing the following:
WebBrowser->Navigate("file://C:\\Users\\Chris\\Desktop\\WindowsProject\\Windows\\MIA_Windows\\MIA_Windows\\MIA_Windows\\web\\login.html");
I don't want to access it by doing the whole path. I want to be able to access it like the following:
WebBrowser->Navigate("file://\\web\\login.html");
Does anyone have any suggestions on how I'd be able to do this?
Native resources can be loaded from embedded resources using the res:// URL scheme.
See the MSDN documentation for the res: protocol and more details from the Knowledge Base
For non-embedded content, you can try setting the BaseURL for the host WebBrowser, which controls decoding of relative URLs.

What do I need to do to submit my desktop app to the Windows Store?

I heard that Windows 10 will allow developers to submit their desktop (non-Metro) apps to the Windows Store. I'm developing using C/C++/MFC and WinAPIs.
What do I need to do to submit my desktop app to the store? And what are the requirements/charge?
You should consider watching this //build talk with John Sheehan. It covers the details of Win32 apps in the store (codename Project Centennial). The first detail is "this project is still under development" (as of May 2015).
In a nutshell, you can take an existing MSI-based installed app, run it through a tool to generate an appx, and then you're done. There are some things that won't work (eg installing services, custom licensing / DRM, or running as administrator) but most normal app code will work. The example shown is Adobe PhotoShop Elements, which worked perfectly except for the licensing check (which can now be handled by the Store anyway).
If you don't want to sit through an hour of this Build 2015 presentation linked by Peter Torr, here's a synopsis of what Project Centennial will entail. Also, as was pointed out already, this is all a preliminary stuff, that is still under development (as of May 2015.)
Applies to Win32/.NET/COM based apps listed in a Windows 10 Store:
MSIs are "evil". Use APPX packages instead.
APPX Gloal: one-click installs thru Windows Store, automatic app updates via Windows Store (using file diff'ing - no need to re-download large unchanged files in the package.)
Microsoft will have an automatic conversion tool: MSI to APPX.
MSI licensing/DRM will not work: i.e. can't look up CPU serial number, hard drive info, network card MAC addr, etc. (My take: The store app will not be able to access hardware directly.)
The app will have a live tile & anything else that can be done with the Universal App (or Metro style app.)
The app's AppxManifest.xml file will define app's file associations.
The app installs into a sandbox folder with randomized path, example: C:\Program Files\WindowsApps\<GUID>\<Package Name>. This path changes every time a new app version is released.
The app's sandbox folder will have Root\VFS subfolder that will contain the following redirected subfolders:
AppData
AppVSystem32Catroot
AppVSystem32Catroot2
Common AppData
ProgramFilesCommonX64
ProgramFilesCommonX86
System
SystemX86
Windows
For instance, if your app tries to access C:\Windows it will be redirected to C:\Program Files\WindowsApps\<GUID>\<Package Name>\Root\VFS\Windows invisibly for the app.
The app's package sandbox folder will have Registry.dat file (that is a registry hive) for that app. All requests to the system registry done by your app will be redirected to that file, including HKLM and HKCU keys. So in other words, your app won't be able to modify any of the shared system registry keys.
Apps installed via APPX packages cannot share dependencies between their files, nor inter-load other app's package contents.
Namespace merging (between shared system files and package's Root\VFS folder files):
Namespace wrire redirection (writing into shared system registry is redirected into your app's Registry.dat file. Also on the file system scale only AppData folder is redirected to your app's Root\VFS\AppData folder):
The redirected AppData folder will be placed into non-roaming location.
The store app can run only as a user (which they refer to as a "Full Trust", which in my book is a misnomer) It cannot run elevated, and if it tries to call an API that shows UAC prompt, such API will silently fail.
The store app cannot install or run NT services.
I believe that there's a way to sign up for any updates on this project.