adding a non-default plugin to the client

Discuss the company and its products.
randomstuff
Posts: 9
Joined: 15:03, 03 Mar 2015

adding a non-default plugin to the client

Postby randomstuff » 21:13, 14 Mar 2015

how would i add a plugin to my project, a plugin that's not on the list of default pre-included plugins?

i get that if i have a cordova project i should use "cordova plugin add ...", but what about evothings client? does it search for the plugin automatically after i do the cordova plugin add?
or should i manually include somehow?

i have found a file in hyper/libs-cordova/cordova_plugins.js, should i modify that file somehow?

Fredrik
Site Admin
Posts: 196
Joined: 15:00, 18 Nov 2013

Re: adding a non-default plugin to the client

Postby Fredrik » 00:34, 15 Mar 2015

To add a plugin to the Evothings Client, you must build it by yourself. This is a bit tricky. You need:

You'll then need to take a look at the workfile, which contains all the logic needed to build the client. You can either modify the workfile directly (this part), or create a separate file "localConfig.rb" to specify the extra plugins you want.

As I recall, "hyper/libs-cordova/cordova_plugins.js" is a leftover, and can be ignored.

randomstuff
Posts: 9
Joined: 15:03, 03 Mar 2015

Re: adding a non-default plugin to the client

Postby randomstuff » 04:00, 15 Mar 2015

uhh wow, i was kind of hoping it would be easier. the workbench kind of loses the point if i want to use something else than few default libraries :( there are so many plugins out there and this is very limiting

is there perhaps another dirtier but simpler way of including a plugin? (like wiring-in some javascript includes)

or is there a planned release where evothings workbench/cilent would be able to include any plugin?

Fredrik
Site Admin
Posts: 196
Joined: 15:00, 18 Nov 2013

Re: adding a non-default plugin to the client

Postby Fredrik » 12:03, 15 Mar 2015

Sorry, no. Plugins are native code and must be compiled in order to function.

Even if we were to make a client that could load new plugins on the fly (ridiculously difficult), it would be banned from the App Store for violating the "no-dynamic-native-code" rule.

The idea with Evothings Client is to include all plugins that would be useful for developers of IoT apps. If you have a suggestion for a new plugin, we'd love to hear it.

randomstuff
Posts: 9
Joined: 15:03, 03 Mar 2015

Re: adding a non-default plugin to the client

Postby randomstuff » 14:51, 15 Mar 2015

thank you very much for response, now i understand. i will mention any plugins that i think would be useful during development

randomstuff
Posts: 9
Joined: 15:03, 03 Mar 2015

Re: adding a non-default plugin to the client

Postby randomstuff » 01:09, 16 Mar 2015


jdurnwald
Posts: 1
Joined: 11:48, 11 Mar 2015

Re: adding a non-default plugin to the client

Postby jdurnwald » 12:15, 30 Mar 2015

Hi -

Another valid use case is an SMS plugin. It would be nice for the app to be able to send an SMS message when certain conditions occur on a sensor. For example, when a specific iBeacon comes within range of the phone, have the phone send a text message.

Regards,
Jeff.

ardiri
Posts: 58
Joined: 16:13, 28 May 2014

Re: adding a non-default plugin to the client

Postby ardiri » 12:54, 30 Mar 2015

as Fredrik has mentioned; in order to add plugin's that are not supported within our standard client - you will need to go through the various steps to rebuild the client from source code and have build another application and submit it to the various application stores. the complete set of instructions are available within our documentation, but unfortunately there is no "simple" solution at this point.

http://evothings.com/doc/build/build-overview.html

the client application is designed to help build rapid prototypes for your applications - we totally understand the request for adding more plugins. since the client can be used to show case various applications using the evothings:// URI handler, it was important for us to ensure that the client was sandboxed sufficiently to prevent any malicious code from being executed on the device (ie: imagine if someone wrote a very evil application that started to access your files, contacts and personal information). we would not only have problems with users; it would make our application a point of attack.

that being said; we understand the build process is complex - while we have fully documented it so you can do it on your own.. would you be even remotely interested in if we offered it as a cloud service where you could define what plugins you would need and we do as much as possible to generate an xcode project or android build that you could distribute yourself (of course, this may require a small fee)? we love open source and keeping everything as open as possible; but such a build system would require some work from our end.
// Aaron
Chief Technology Officer
Evothings AB http://www.evothings.com/


Return to “General discussion”

Who is online

Users browsing this forum: No registered users and 4 guests