-
• #2
Yes - this already happens. You have a few options:
- Libraries that are on espruino.com - for instance the graph library at http://www.espruino.com/graph get automatically pulled in
- Libraries in https://github.com/espruino/BangleApps/tree/master/modules get pulled in by the app loader and are included into the app's JavaScript
- Or other apps can provide functionality as a module as part of the app - like notifications. Apps can then request notifications are installed with
"dependencies": {"notify":"type"},
.
The nice bit about the third option is an app can request notifications, but you have a choice about which app you install that provides notifications (so you can for instance have ones that look a bit different)
- Libraries that are on espruino.com - for instance the graph library at http://www.espruino.com/graph get automatically pulled in
-
• #3
Ok, thanks for the info!
-
• #4
Nice,
"dependencies": {....}
slipped by while I had some low Espruino activity times. -
• #5
I was thinking about adding simple
Settings
library, just something like
require('Settings').get('app.settings.json', 'option.to.get', 'default');
and
require('Settings').set('app.settings.json', 'option.to.set', 'value');
Probably wouldn't be much work to implement, but we could get rid of (almost?) all of the defaults-handling boilerplate in apps.
- Does this seem like a good idea, or would it add too much overhead for apps? (I think it would be ok, as they are already loading+parsing a settings file anyway)
- Having a separate library just for two functions feels a bit cluttery, maybe a "Core/Standard/Basic/Bikeshed" library with
getSetting
/setSetting
would be better? (I can't really think of similar functions right now, but going through all apps to change it later would be a shame.)
- Does this seem like a good idea, or would it add too much overhead for apps? (I think it would be ok, as they are already loading+parsing a settings file anyway)
-
• #6
It could be a good idea, yes. Something in the
modules
folder will get packaged in with each app and shouldn't take a bunch of extra memory. I think the issue with a 'core' library is stuff always gets added to it, and then to use two functions you end up having to pull in something with another 20 you don't care about :)I'd argue that maybe we should enforce
settings.jsĀon'
so justrequire('Settings').get('app', 'option.to.get', 'default')
might be better, and it'd mean less chance of bugs?If we find it's something that every device is using, it could always be built into Bangle.js at a later date I guess?
-
• #7
the issue with a 'core' library is stuff always gets added to it
Good point,
Settings
it is then.enforce
settings.json
so justrequire('Settings').get('app', 'option.to.get', 'default')
might be betterYou're right, I think I mostly avoided it because I couldn't think of a nice way to ask for global settings from
settings.json
(passing in an empty first argument seems error-prone). But we can pass inBangle
(the object) and check for that. (unless that would lead to some issue like huge RAM usage I didn't think of?) -
• #8
Ahh - good point. I didn't think about the global settings. Maybe just leave it blank for that?
Not sure if this has been suggested before, but I think it would be useful to have custom libraries. Say, two different apps need to draw graphs. We could give every app separate code to draw the graphs, but it would be more efficient to create a graphing library and then have both apps use that library. Then, it's described in each app's .info file that it requires that library (e.g.
requires: ["graphing"]
), so that when the app is downloaded it can also download the libraries it needs.