Hi to all,
Clearly an interesting topic over here !!
I would say, as usual when mister @tsuji_koichi is involved.
First, Personal Opinion
On a overall topic, âpublicâ endpoint should never be used in a production app. [ google services or any other one ]
Like the uc?export=view&id=xxxxxx but i could name many others.
Those are not reliable, not efficient and are prompt to behaviour change, not to mention some can be deleted. ( google has a long story of switching, turning off those kind of end-point )
Using an API request is the way to do it, at least for production environment.
Return to the main topic,
As @tsuji_koichi mentioned the only way to made a efficient and reliable access to any data is to call an native AppSheet âfunctionâ to make the request. ( remember all those request probably goes into some async loop worker )
So setup 2 with file path will always be the best.
some details :
I never know why but Appsheet seems to use two âdifferentâ methods to feed image inside app. (maybe it depends of security option or maybe even view type )
with a https://www.appsheet.com/get/?i=
this will return a 600 width image.
[the full resolution image can be open with the fullscreen icon, and it seems no new request is send to access it ]
with the https://www.appsheet.com/template/gettablefileurl?appName=
this will return a 600 width image from the https://www.appsheet.com/fsimage.jpg?filename=
[the full resolution image can be open with the fullscreen icon, but a new requested has to be sended to access it, this will generate a wait time and a lot of 404 error, but i think it really depends how you secure your urlâs app, security options : secure url, secure image etcâŚ]
Both method require a unix relative file path, [many way exist to massively generate those path]
the https://www.appsheet.com/fsimage.jpg?filename= can be directly generated and put into a table column with a size parameter, or setting it inside the app with a virutal column, context view, action, user settings etcâŚ
( this is the fastest way to have the image inside the app, plus you can minimize mobile data usage and app reactiveness )
Any way,
Honeslty, i have an App with more than 200K image, and AppSheet handle it natively like a charm.
( only a classic file path column set as image type, without any âoptimizationâ ) [ Iâm still amazed by this ]
End,
I could mention the use of the https://www.appsheet.com/remote/ + Url end-point [view, export, download, http web-app services request ]
( can be useful to if you want to add a document conversion action button but better to use a webhook api for this)
Linked Topic
Itâs funny how time coincidence collide sometimes;
I recently finished the development of an API to give my users access to their personnel directories through a GAS Back-end [a mix of pure drive.app and drive API V2] and a Front-End with JavaScript/JQuery/React/Html.
Basically,
First, i created a JSON Query function to dynamically map and index any requested directorie tree + files.
Then i created a Custom React/JavaS component which take the returned JSON Object to build dynamically the Front-End HTML Code.
This is morish like an AppSheet Deck view type, with some embded icon for go-in-to-folder, delete, rename, view, add or download file or folder.
( the onclick() Html event trigger back the specific GAS Back-end fonction )
So, im more than happy to learn that AppSheet develop a drive access component.
This can maybe solve one of my long time usercase : a fully AppSheet integrated Document Management System
Wait and see
