I have updated the test server (note the link in the original post), the Companion, and the Emulator Companion.
The ReadWithQuery functionality was dropped from the Google Sheets API after the component was originally written. That sent me back to the drawing board.
In place of ReadWithQuery, there are now two blocks: ReadWithExactFilter and ReadWithPartialFilter. These allow you to query against a single column in the spreadsheet to either exactly match or contain a substring parameter.
Both of these blocks return both a list of row numbers and the list of row data. You need row numbers for other blocks, but previously there was no way to query for those numbers.
I tested against @Juan_Antonio 's very useful test application. It has not yet been tested against sheets with restricted access.
I know @TIMAI2 reports that the Emulator I posted previously didn't work. I haven't had a chance to investigate what the problem is. I updated it just in case.
I am leaving on vacation for two weeks and will be able to return to this when I get back.
component works fine, will it be added in future release,
else you can provided this component as extension as we might use it in the latest version of mit ai2.
or @Susan_Lane make sure the test server keeps running until the component gets released in the Stable version of MIT AI2, as I and many developers have the projects saved in the http://sheets-dot-ai2-ewpatton-temp.uc.r.appspot.com/ because the downloaded AIA files also cannot be imported as it says "unable find the component "GoogleSheets" "
Thanks for extension suggestions, only thing that make me to stick with Google Sheets API based component is the speed of read and write, with API it's 1-1.5 seconds, with Apps Script, it takes minimum 3 seconds
Just read an entire sheet data with 10 column and 10 rows, you can check yourself while you perform this with apps script and Google Sheets Component, just use a button and label, use a timer label to check speed
May be, but what if the sheet is already read when the app is started (e.g. in the Screen.Inititialize event) and then displayed later when it is needed?
I just created a demo app for only Read Data From Sheet. You can also check the similar way for other operations like Read and Write Row or Column, etc... where the time difference is what i said in
I concur. Did some testing, all on the Google Sheets Component test server. I don't have a service account set up, so my test with the new component was without credentials. My test google sheet, is "anyone can view", had 100 rows and 8 columns of random data. The screenshot shows start time (from button click), end time (to data display) and accumulated time in milliseconds. I also tested a gviz query and the usual export as csv. I used my replicant extension for Google Sheets.
The timings vary wildly from test to test on the same method,, which I guess is due to the state of the network at the time, but in general:
Gviz is by far the quickest
CSV comes in second (export?format=csv)
Google Sheets Component
Google Apps Script
Not something to really lose any sleep over, most of the problem appears to be network latency, when the network is really switched on, they are all as fast as each other, best times being in the 500 - 1000ms range.
I can live with a 1000ms overhead on my google apps scripts, not exactly mission critical
Doubt, should I be able to delete a row from the google spreadsheet when y select an item from the list, even if the Item are read in format CSV ?
Let me explain you waht I am traying to do.
I need to filter a colomn text from an spreadsheet, then I need to show those items in a list view , select ant specific item and errease the row with a botton
Before you do anything detailed in the test server, you should know that the Spreadsheets component will be released on ai2.appinventor.mit.edu within the next week.
Just the opposite. Right now, the Spreadsheet component is only available on a testing server. Next week, we hope to make it available on our regular site.
So this is one of those fun (?) little details about how the internals of App Inventor works that causes things to break in odd ways. As a workaround, you could assign the result to a label's text field and then use that in the data. The internal fix is straightforward but likely an edge case the original implementor did not consider.
