The community will undergo maintenance on October 16th at 10:00 PM PDT and will be unavailable for up to one hour.
Hi PTC Support team
Sometimes , we use view app in environment as a plant where can't use network.
How can I save a text file and picture file to local folder on device?
We want to save an inspection result (OK,NG) temporarily , then upload result file to server when the network is restored.
I try create element ('a') in home.js , It worked fine in preview, but not worked in view app on the device.
Hi @T.Nakamura ,
currently the Vuforia view does not provide functionality to save data locally . So therefore you need a server e.g. Thingworx repository to save the data of the current project session. When you load a project (via Thingmark, ModelTarget etc. ) the data related to the session is saved so far in the app parameters, widget values and js variables of the current View session. This data will be lost when you exit the Vuforia View app or load another project. Currently Vuforia View could not save data to locally to the mobile device. So means to be able to "remember" the status of some session from the past you need to load data from Web Server - e.g. form the Thingworx server or to save the data specific Studio project session you need respectively to save the data to the web server location. So far I know there are no plans for implementation (local data save in offline session)
As mentioned in my previous post this is know restriction but I forwarded your request for to PTC AR R&D / Product Management as Jira Ticket VTS-1187 (you can use also this as reference in discussions with PTC Technical Support). I will provide an update when there is a feedback to the Jira ticket. Possibly somebody from Product Management team or R&D will directly answer on this topic, Thanks
Hi, @RolandRaytchev
Thank you for your support.
I understood can't save data locally.
Currently we use view is limited in our environment.
I hope so implementation for this function.
If you're willing to write some code, you can use the standard JS api for localStorage to write some data (between 5-10 mb total typically) to the device. The localStorage areas are specific to the origin (meaning the path for experiences loaded from the ES is different than downloaded experiences so they have different origins) and data cannot be accessed across different localStorage areas. All experiences loaded from the ES would share the same localStorage space on the device; all downloaded experiences would share the same localStorage space on a device (which is a different localStorage space from the experiences loaded from the ES).
Also any images would have to be converted to base64 to be stored in localStorage since you can just store text data (not binary files). You will have to manage writing the data to localStorage, retrieving it, writing the data to Thingworx, and erasing the localStorage data yourself; none of this is supported or automated. It's really not difficult to do, there is a lot of information online about using the JS localStorage api.
@rabernathy , this seem to be interesting option which I never used therefore was curious to test
simple reference https://www.w3schools.com/html/html5_webstorage.asp but also many others
HTML web storage provides two objects for storing data on the client:
window.localStorage
- stores data with no expiration datewindow.sessionStorage
- stores data for one session (data is lost when the browser tab is closed)Before using web storage, check browser support for localStorage and sessionStorage:
Unlike cookies, the storage limit is far larger (at least 5MB) and information is never transferred to the server.
Web storage is per origin (per domain and protocol). All pages, from one origin, can store and access the same data.
So I tested the window.localStorage with the curret Studio and Vuforia View version on android with simple code like:
$scope.test=function(){
if (localStorage.clickcount) {
window.localStorage.clickcount = Number(window.localStorage.clickcount) + 1;
} else {
window.localStorage.clickcount = 1;
}
let bla = "You have clicked the button " +
window.localStorage.clickcount + " time(s).";
$scope.setWidgetProp("3DLabel-1","text",bla)
}
Frist impression was good-all experiences loaded form the same experience service ( https://my-esperienceservice1.io ) could access the saved data also after closing of view app and restart. So having localStorageExperiencetest1 and localExperiencetest2 calling the same code after reloading form server closing vuforia view they still will "remember" the value of clickcount and will continue to increment. At least this is a good option to share data between session and experiences Project and session if necessarily
But unfortunately in this usage case this have one problem . It is data specific for domain and it seems that there is a different domain for the offline mode.
So starting e.g. experience localStorageExperiencetest1 from library (the experience was downloaded to the mobile) and loaded then it has different count. So means all offline /libraries experience will share the same localStorage but when the experience is again online it has a different local storage and could not access the data saved in offline mode. At least this was my observation.
As I said in my initial post, experiences that are launched from the ES have a different origin than downloaded experiences. I disagree that it's a huge issue though. In a downloaded experience you aren't going to connect to Thingworx to store data anyway so that's a very different use case than starting an experience and then going offline.
The scenario you describe of running a downloaded experience while offline then wanting to run the ES experience later honestly doesn't make any sense to me.....they aren't the same experience and you can't guarantee they will be the same so your scenario could introduce issues when the downloaded experience isn't updated. You're better off starting the experience from the ES and then going offline and coming back online. In fact JS even has listeners for online and offline.
window.addEventListener("offline, () => {
});
window.addEventListener("online, () => {
});
You can start writing to the localStorage when the offline listener is triggered and then write to Thingworx when the online listener is triggered.
Even if you don't want to do that, there a lot of use cases where localStorage makes sense to use even when you are always connected. I use it to store a UUID for the device, I also use it to store information about where you are in the execution of an experience so that if it crashes or you exit, you can re-start at the same place when you restart the experience.
thanks for the clarification. just for understanding , if I understand correctly the application case is that you go online and you will lost the connection right then stay in offline mode (but experience was loaded from ES)= then continue to do some actions and then back in online mode where you can store the data form the "offline" local storage to the twx with the mentioned listeners
But possibly this will not work when the user is on a offshore location where is no connection to server then start the device and for example does an audit. Then finish the audit . Close all applications (also view) and later in the company. In company location user start the view app and want to update the data.
The point is that on the location offshore - means location without ES connection then the only possibly option is to start the offline experience form lib.( if the view app e.g. is not running with the required experience project )
There is a major issue with expecting to start with a downloaded experience and then use the data online later. The downloaded experience is not the same experience as is on the ES; it's a one off copy. In addition, there is no guarantee that the downloaded experience will be in sync with the ES experience which could introduce various unknown issues. I've seen customers that have downloaded an experience to a device and then not updated it for over a year even tough the ES experience has been updated during that time.
As architected, downloaded experiences will never connect to anything online; there would be a cors issue that would have to be dealt with, not to mention the different version issue mentioned above. It would also be a huge security issue for the browser to allow different localStorage origins to directly access data from other localStorage origins. There may be a method to send data from one domain to another but, from the limited research I've done on it, it may not be secure so I won't discuss it here unless I can verify that it is a secure method.