This question is an addition to the topic Should Google App Scripts be stored in version control like GitHub
Is there any possibility that source code versioning for Google Apps Script Projects is (or will be) covered by the still Beta "Source Code Tools" (https://cloud.google.com/tools/repo/source-tools)
From documentation of the Cloud Repositories (cloud.google.com/tools/cloud-repositories/docs/) I see:
"Each project you create in the Google Developers Console has an associated Cloud Source Repository. ",
while in the documentation for Google Application Script project (developers.google.com/apps-script/guides/services/authorization) I see: "Every Apps Script project automatically creates its own project in the Google Developers Console to control authorization." (only authorization, but maybe also source code versioning?)
From what I tested so far it seems that sources of Google App Script projects are not covered by the Versioning System.
Thank you,
Ado
There is one project out there that does a pretty solid job with github. What makes it special is that is has some trickery to be able to import and export your project with the associated libraries and Advanced services.
https://github.com/brucemcpherson/gasGit
As for official support the best people can do is star the issues in your linked question.
I have wrote this chrome extension to make it easy to sync your code between GAS and Github.
https://chrome.google.com/webstore/detail/google-apps-script-github/lfjcgcmkmjjlieihflfhjopckgpelofo
This will work on the GAS IDE, simply sync your code between GAS and Github Repo/Gist with the familiar pull/push.
Related
google cast provides sample github links, which uses default cast extension to cast the data by registering from developer console, but how to use this sender/receiver application without using chrome extension by auto detecting the device and cast the data, is there any specific tutorials to follow up?
I've been working on a project that uses a similar approach like the one you're asking about and I came across a couple of repo's on github that helped me along the way but there isn't so much on the internet about it.
Basically you can communicate with the Google cast device without relying on the google extension by applying two steps.
Discover the device on the local network by using a service discovery service such as Bonjure or MDNS, here's a sample repo on github that uses a pure JavaScript implementation.
Communicate with the Google cast device over the network by using google's CASTV2 protocol over TLS and here's one of the most popular implementations can be found here on this github repo and also here's a high level implementation of the same library these libraries are also in written in JavaScript.
I want to program a desktop app in javascript (with web technologies) and looked for a comparison between Electron and Chrome Apps.
Everything I need seems to be possible with Chrome Apps, but there's a big hype around Electron/NW.js. What are the advantages of Electron? Is it due to the large amount of Node packages?
I think the functional differences are clear to me.
Pros and cons like:
+ Chrome Apps can run on Chrome OS
- Chrome Apps needs an installed Chrome Browser
...
UPDATE 2016-08-20:
As Eduardo pointed out, Google announced that they'll discontinue Chrome Apps for all platforms except ChromeOS. So I think the answer to this question is obvious now.
For all of you who developed a Chrome App and are interested in migrating it to the web here's a guide from Google: https://developers.chrome.com/apps/migration
Or, as Google also mentioned, you migrate it to Electron or NW.js.
You can totally compare electron and chrome packaged Apps. They are very similar. For both of them you get:
Develop your Desktop App using Web Technologies
App runs on top of Chrome
Automatic updates. Though in Chrome you get it for free, for Electron you need to do some work.
OS Integration - Both have better integrations with the OS than a normal website, but Electron supports a wider range of OS integration.
Work offline or online.
Both work on Linux, OSX and Windows. Chrome Web Apps also work on Chromebooks.
Here are the differences:
Electron uses node.js. So you can import many modules not easily available in Chrome Apps.
Distribution, with electron you package and distribute the app yourself. With Chrome Apps you distribute them through Chrome Webstore.
Environment. An Electron App is packaged with its full environment. Chrome Apps just use Chrome environment so they are lighter, but may behave differently for different users depending on the Chrome version they use.
Chrome Apps require the user to have Chrome installed, Electron doesn't.
Electron has better developer tools for testing and debugging.
Electron is an open source platform. Chrome Apps is also built on top of multiple open technologies but specially distribution is controlled by Google.
Electron documentation is much better even though it's a much younger platform.
Adoption: There are quite a lot of big and successful apps built on top of Electron such as Visual Studio Code, GitHub client, Slack. Chrome Apps just never picked up as much momentum.
Chrome Apps can be tightly integrated into Google Drive
UPDATE 2016-08-19:
It seems Google recently deprecated Chrome Apps on any platform other than ChromeOS. So I'd say it's no longer a valid option.
http://blog.chromium.org/2016/08/from-chrome-apps-to-web.html
I think it is not really possible to compare electron and chrome-apps. It depends on, what your program should do.
So, when should I use electron?
On the first look electron looks like chrome, because the views of electron is based on the chrome browser. But electron is a full node.js environment with a chrome view on top. So the powerful features are not just insight the chrome part.
Like you mentioned there are a lot of node modules (over 1.700.000), which you can very easy install or update. You should also take a look at the node.js api (https://nodejs.org/api/). All that allows you to write complex apps, which are fully integrated on your desktop. For nearly all problems are some modules available.
With node you can first make your program with a command line interface and after that you can use electron to make a gui.
So, when you already have a online app which is written in JS, maybe a chrome-app is better. Chrome-apps are great for a google drive use. Or if you want to have a full integration in chrome-os.
So my pros for electron:
more than 1.700.000 modules over npm available
very easy integration of jQuery, Angular, React, ...
first make a program with a CLI and then make a gui
works perfect with github
very good desktop integration
provide windows installers
I would like to chime in on Electron vs nw.js.
I have a very popular Chrome App which cannot be converted to neither a web app nor an extension because it uses several unsupported APIs, most notably the chrome.fileSystem API.
The app is still only accessible on Chrome's webstore since app support will be abandoned not before early 2018. Nevertheless, I have already spent lots of thoughts and time on deciding what to do about Google's move.
Until now I have been mainly aiming at Electron since that seems to get most attention, but I have just recently found that nw.js can actually run Chrome apps out of the box because it implements all Chrome's APIs whereas Electron only implements a subset of them.
Simply run your Chrome app like this:
/path/to/nw.exe <folder path of the manifest.json file>
Except for a very few things such as intercommunication between my app and a helper extension, everything works as expected with zero changes even though it is an advanced app with nearly 3000 lines of JS code.
For new cross platform apps, Electron might be the better choice (I have actually no idea) but for existing Chrome apps I would say that nw.js is really something you should consider.
Hope this can help someone in the same position.
all.
My team has been toying with the idea of developing an iOS app using Cordova, and recently, we've been looking into offloading as much of the main JavaScript as possible to our server, in an attempt to speed up fixing critical bugs.
The idea would be to have:
the native app containing all HTML, CSS, plugins and Cordova files
the main JavaScript added to the pages as external scripts from a server
a device-ready function for each page that will set up and start the main JavaScript once it's available
I have seen comments that Apple could be trusting of code that runs in a webview, but it does seem like projects like this could be a security issue.
I am aware of other questions and the like that touch on this, but I feel that the context was always different.
Thanks!
A year ago apple changed the iOS Developer Program Agreement to allow download of code, see the Section 3.3.2
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts,
code and interpreters are packaged in the Application and not
downloaded. The only exception to the foregoing is scripts and code
downloaded and run by Apple's built-in WebKit framework, provided that
such scripts and code do not change the primary purpose of the
Application by providing features or functionality that are
inconsistent with the intended and advertised purpose of the
Application as submitted to the App Store.
So, as you are using cordova, and cordova uses WebKit framework, if you don't change the main purpose of the Application, you won't be rejected
The answer is it depends on how you use the system. The technical ding that hits most people is Apple iTunes Guidelines - 2.12
Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may be rejected
It seems clear to me, but as a volunteer on the "official" phonegap forum, I'm often very blunt with people on this point. Nothing worst than months of work for nothings
On the Javascript idea, loading the javascript file from the web is not good practice. If your app ever loses the network, your app will be non-responsive. One app that I can name, that was growing by leaps and bounds, that has this problem is Word with Friends. I play and I can see the stall every time.
Make sure you App is always responsive and if not, give a short reasonable explanation. LIKE,"Opps, we can't find the Internet."
I have seen comments that Apple could be trusting of code that runs in a webview, but it does seem like projects like this could be a security issue.
Yes, Apple trust code that runs in webview, because it is not a browser. However, that does not make it secure. We have plenty of security issues and bugs. A recent security issues allows rogue code to insert weblinks into webview, and thereby allow the App to be used as an attack vector. Another recent security issue will launch rogue code from and mp3 file! And this bugs goes back to Android 2.0.
The cure is worst than the problem. It's a huge whitelist protocol that is confusing because of the bad documentation. Luckily, I should have a blog post in a few days; other people are working on blog posts too. my raw notes are online or read the current issues especially #10.
I am aware of other questions and the like that touch on this, but I feel that the context was always different.
Feel free to read my notes. The one i give to people all the time is:
Top Mistakes by Developers new to Cordova/Phonegap
But the root has more notes
Best of Luck.
I recently stumbled across the Google .css and. js files by the name of "Google Maia". These appear to be an in-the-works competitor / replacement for Twitter's Bootstrap. Does anyone know where to find the official version?
As of now its internal. Google hasn't released any version for public yet https://groups.google.com/forum/#!topic/closure-library-discuss/YzmT7G1AqQg . However you can get some clue from google style sheet guide https://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml
This is most likely an internal resource for Google, not publicly available.
I've been playing with SourceKit, which is an awesome Chrome app for editing your Dropbox files using the Ajax.org Code Editor. In the release notes for version 0.5 and the readme, the author says
Arbitrary Javascript "plugins" are loaded post initialization from your Dropbox account. It is loaded from /.sourcekit/plugins/"
I've tried putting some Javascript in that directory, but can't seem to get anything to execute. Does anyone know of documentation for or examples of SourceKit plugins?
(I've submitted an issue on the GitHub project, but have gotten no response.)
SourceKit dev here. Forget about the old styled plugins that I was referring to in the old README CHANGELOG entry. I switched internally to use Dojo, Ace and Require JS. I haven't gotten to the point of adding plugin support just yet with this new rewrite...
It'll come in due time! In the meantime, if you have any ideas, I do take in pull requests via github: http://www.github.com/kenotron/sourcekit
It looks like these plugins for Bespin at Mozilla Labs should fit the bill but they don't seem to function at all at the moment. This "plugin_manager.js" file from the pilot library looks like it does just that for the SourceKit project and it was/is the same deal for Bespin/Skywriter/ACE.
I don't think at this stage there are any "downloadable" plugins for SourceKit, but the plugins in the Bespin Gallery might be worth hacking at.