GAS - Chart API Deprecated - google-apps-script

I looked at my 'Execution Hints' and saw this.
"Chart API is deprecated."
I copied the chart codes directly from here
https://developers.google.com/apps-script/reference/charts/column-chart-builder
What am I to change it to if it is deprecated?
I use the charts as images and send it to emails.

You are correct Google has Deprecated Image Charts. It was officially deprecated as of April 20, 2012 as far as I know there is nothing by Google to replace it.
you will need to find some other third party tool to suit your needs or create your own.
It appears it will stop working on April 20,2015
Deprecation Policy
Google will announce if it intends to discontinue or make backwards
incompatible changes to this API or Service. Google will use
commercially reasonable efforts to continue to operate those Google
Chart Tools versions and features identified at
http://developers.google.com/chart/chart-api-list without these
changes until April 20, 2015, unless (as Google determines in its
reasonable good faith judgment):
required by law or third party relationship (including if there is a
change in applicable law or relationship), or doing so could create a
security risk or substantial economic or material technical burden.
The above policy is the "Deprecation Policy."

I think the original poster is referring to a different Charting service. This one being the one used with UiService in GAS.
UiService is the only place that Charts can be used. And since UiService was deprecated as of Dec 11, 2014, it makes sense that UiService only features, such as Charts, would also be deprecated.
It it likely to be possible to use Google Charts with the new enhancements to the HtmlService. The last time I tried to use Google Charts with HtmlService, it mostly worked. I have not tried since they introduced the IFrame based Sandbox mode.
The UiService set of Charts was a subset of the Google Charts stuff (which itself I think it just a free serving of the charting stuff built into GWT).
So while how you set things up will be different, you should have feature parity once you migrate your application from UiService to HtmlService.
The Google Image Charts are older, static charts, and that does appear to be going away. But again, that is just one small portion of what Google Charts as an offering is.

Related

It is in regards to an email from google about migrating discontinued documents list API

I received this email and due to my lack of experience in google drive, I am unsure of how to go about troubleshooting this.
Google
IMPORTANT: Steps to migrate from discontinued Documents List API
Hello administrators,
We recently posted a reminder that Documents List API will be discontinued on April 20, 2015. This change means that service calls for this API will no longer be supported, and any Google Apps features that are implemented using this API will no longer function.
Our records indicate that you may have an application that uses Documents List API, and we recommend that you migrate to Drive API, which has comparable functionality, as soon as possible.
Here's what you need to do:
Determine if you have an application that makes requests to these types of URLs:
(took out urls since this format did not allow me to send more than two)
Migrate the applications to Drive API.
If you have questions about migration, please contact Google Apps for Work Support.
Sincerely,
The Google Apps for Work Team
How do I determine, which, if any, docs are going to cease to function post 4/20? Is there a way to organize my current list of docs (I have many) to see how many I need to pay attention to? In terms of migrating, is there a migrating tool available online?
From what I have read, I feel like this doesn't even pertain to my current drive. My understanding is that this is for developers not casual users such as myself. Am I wrong in that assumption?
Thank you for all your help in this matter. If I am not explaining everything to the level you need, please let me know. I am just confused by the email and want to make sure I stay ahead of this.
Best,
Nathan
The key part of the email is Our records indicate that you may have an application that uses Documents List API
If you have such an app (you should know since by implication, you wrote it), then you have a lot of work to do over the next two weeks. If you don't, then relax. Your documents are not affected by this announcement, only the app that Google thinks you once wrote.
It's possible it's referring to an app you have installed, in which case there is nothing you can do other than hope the developer has a new version.
In my case Google Apps Sync for Microsoft Outlook and Google Drive Windows seem to be the 2 applications that are requesting access to these depecrated scopes ... Come on Google, spread the word internally !

The future of Google Apps Script User Interface - UiInstance or HTML Service?

The situation:
I'm currently creating an advanced Google Apps application which I would like to release later on in the Google Add-On store (It's an Add-On for Google Spreadsheets).
My application has since the beginning been developed using the UiInstance service for creating the User Interface. It works swell and I'm really happy with the results.
However, if I consult the Add-On style guide this is mentioned:
Use the add-ons CSS package in your HTML service pages. (And don't use UI service to create a public add-on — it won't look as professional.)
Also, the UI service is marked as Experimental in the Google Apps Reference Guide, this might also be a problem for publicly releasing it (can anybody point me in the right direction to ask more information on this?)
The question; Does anybody know about the plans for the UI Service? Might this get deprecated in the (near) future? I've been looking for more information on this but I did not find it. Please keep in mind that your guess is as good as mine.
Should I start recreating my UI with the HTML Service or is there any future for the UI Service?
My personal opinion; I think the UI Service makes it a lot easier to create a User Interface, still having the possibility to adjust it as you wish.
You are perfectly right when you say "your guess is as good as mine" but I see at least 2 arguments that makes me think HTML Service is the way to go :
the "recommendation" about not using UiApp in add-on is not really a recommendation, it's definitely a requirement. They won't approve an add-on build with UiApp (and approval is also a mandatory step)
They provide a link to a Google static CSS sheet that will determine the "look and feel" of the add-ons for buttons, fonts and about all graphic elements used in the Ui so that, if ever they feel like changing something in the Ui, they have full control on it and don't rely on each app developer good will to update it. This would not be the case in UiApp of course.
And lastly, they stopped maintaining UiApp and deprecated all methods that were having issues, leaving it "as it is" so I guess the future is - at the least - uncertain...
I fully agree with you that when you know how to use UiApp it is fairly easy but I know also that this is more a personal point of view that not so much people share. If you are a "normal" web developer then HTML and JQuery are certainly more familiar and far more easy to use.
I guess (I know it's just a personal guess ;-) it's time to start your "mutation" to HTML Service, at least if your goal is to publish your apps.

How to migrate code from Google Maps API V2 to V3?

As the Google Maps JavaScript API Version 2 has been officially deprecated as of May 19, 2010. The V2 API will stop to work after May 19, 2013.
Does all the applications which we have develop using V2 going to stop after May19, 2013 and we have to migrate these to V3 before this?
I don't know if google has expressly said that they will remove the API and assets from being able to be used, but I do know that after May 19, all bets are off, they are free to take down the API and any/all assets that are required to support v2 at any time without notice, so it's kind of an "at own risk" deal.
It's time for you to migrate over....v2 has been deprecated for years and v3 is very well supported.
It's not ridiculously hard to migrate over, you can probably keep the majority of your existing codebase and just call a few different functions.
For instance, all of the original functions that you used to call like this:
new GMap2()...
new GMarker()...
new GLatLng()...
Have all been namespaced, so their equivalents in v3 would be:
new google.maps.Map()...
new google.maps.Marker()...
new google.maps.LatLng()...
Any time you'd be using services, however, like StreetView or DirectionsRenderer, you'd need to check the docs on that because those have changed slightly.
You'll have to chase some bugs down as you go through, but the docs are very very well organized and you shouldn't have that much trouble.
Best of luck!
Here's an easy guide on how to do the upgrade: http://gabrielduque.wordpress.com/2011/01/13/upgrading-from-google-maps-api-v2-to-v3/

Google Map version2 vs Version3. shall we continue with gmap version 2

My map project needed an update this month and when i referred gmap i saw the notification requesting to migrate to version3. This is from may 19th 2010.
There are three projects live which used gmap extensively.
Those projects are for Transportation department in which we have plotted a route for a bus service with many options.
What will be the problem if i let the existing projects be as they were. that is in version 2.
I would like to have suggestions for the above.
From the Google Deprecation Policy:
"For a period of 3 years after an announcement (the “Deprecation Period”), Google will use commercially reasonable efforts to continue to operate the Deprecated Version of the Service and to respond to problems with the Deprecated Version of the Service deemed by Google in its discretion to be critical. During the Deprecation Period, no new features will be added to the Deprecated Version of the Service."
http://code.google.com/apis/maps/terms.html#section_4_4
So you are probably good to keep using it for awhile - but eventually you will need to update.
Note that V3 is not guaranteed to be compliant with IE6, which is the reason why I am temporarily holding off on updating my own applications.
If v3 has all the features you need, then go with v3.

developing location/map based web site

I wanna start developing a map-based web site.
At first I ordered a regulat Gps device just to test the site, later on I would like to use Iphone's gps and other cell devices.
So I need something pretty generic.
I searched the web for map-based development framework and come up with too many of them :
Geo server, Map server, Open layers, Geoext , Google maps's api , and more.
I'm not a seasoned web developr (more of a c++ kind of guy) so I need something pretty straightforward , though robust at the same time.
Moreover, I need one which is free, and won't have licensing problem down the road.
At first I just need basic capabilities as displaying the gps data on my web site in real-time.
Can someone experienced recommend one ?
Thanks
Client
I'd go with OpenLayers - this is an opensource JavaScript client library, similar to the Google Maps API, or Bing API. However OpenLayers will free you of any licensing worries, or changing APIs as the source is available and can be modified - this is not the case with the Google/Bing/Yahoo APIs. You can however use the data from these services as layers in OpenLayers and drop them if they suddenly become filled with adverts or have commercial restrictions.
Have a look at examples to see if there is one you can use to make your first test application - http://openlayers.org/dev/examples/
GeoExtJS is a collection of extra tools and widgets that work with OpenLayers, built on top of another JavaScript framework ExtJS - also open source. ExtJS is mainly used for building user interfaces - data entry forms, grids etc. using JavaScript, to display in the browser.
If you are looking for tree structures to switch layers on and off and other more advanced UI widgets then GeoExtJS is worth looking into.
Server
If you are only displaying points then you can create dynamic KML or GeoJSON on your web server and reference this in OpenLayers. There are libraries in all languages that you can build on. Python has become a key languages in geospatial technologies, and has GeoJSON libraries you could script with.
GeoServer and MapServer are both server-side programs that allow you to serve out spatial data from databases with symbology, labelling etc. If you are having lots of different datasets then its worth spending time setting this up.
MapServer is written in C++ so it is probably easier for you to try this - however you may be able to get away without needing any specialist server side software, especially if your data consists of X,Y / Lon,Lat values that can be easily plotted as points.
For the beginning (you said that you need to show gps position in a real time) I think that Google Maps are good option here. This solution has very simple API and community support is also an advantage here (I've never compared with something else but I have good experince with GMaps and its tutorials/resources). This is for the client side, for server side any web framework should do the work (I use Django and it also have dupport for some geo things - mentioned later in this answer).
You need probably to build application that follows this rules:
Your GPS device sends data to your server(web application) periodically, data is stored in a db.
Users use browser to display data with map (eg. Google Map) which updates position periodicaly on some scheduled interval (eg. ajax calls to the server for the most current position). Each time response is recieved map need to be updated.
I don't know if there are more specialized solutions for this case.
If you need to improve your application and add some features you need to consider some more sophisticated geo frameworks. I have heard some positive opinions on GeoDjango, mainly because it can be easily incorporated with Django(which is very easy web framework to learn and it has a lot of capabilities).
All technologies I mentioned here are free.
I can recommend using the Google Maps API to render your maps in a browser. You can find my reasons in this answer.
The current version of the API has support for getting geo-location information for mobile devices.
I use Bing Maps for mobile. Mainly because its fast, and provides much better looking maps, 3d models, and satellite views for the UK than Google maps does.
I have also had issues with Google changing their service to provide some enhancements and it breaking my app, where at least with the Bing API theres a bit more compatability considered for existing apps. Not that I dont like the Google maps, I do. Its a backup service for me..
I generate maps from both providers, Bing as the primary, Goole secondary... this means that if ones offline of not working, which happens, my users still get to use my app.
Heres a link to Bing Maps Dev on a WIndows Phone for example
I'd take a look at Cloudmade. They have a number of API's, free options, paid options and use OpenStreetMap which for many places is one of the most accurate mapping solutions out there.
free , open source:
www.openstreetmap.org,
u can build ur own server as well using the same technolgogy:
http://weait.com/content/build-your-own-openstreetmap-server
API: http://wiki.openstreetmap.org/wiki/OpenLayers
Although its still in draft form, HTML5 will be supporting Geolocation API. Most major browsers and hand held devices should be supporting it in the near future and should make life a lot easier for developers who want a service independent solution. You would however still need a mapping service like google maps if you need to display locations.
function showMap(position) {
// Show a map centered at (position.coords.latitude, position.coords.longitude)
}
// One-shot position request.
navigator.geolocation.getCurrentPosition(showMap);
EDIT:
Its already supported in several major browsers:
Mozilla Firefox: supported in Firefox
3.5 and later versions.
Chrome: Supports thru Google Gears
Geolocation API
Opera: Supported in
nightly builds
Safari: Support is
coming soon in the IPhone’s Safari
browser.
Internet Explorer:
experimental support available from
IE8.