-
Appreciate you taking the time for this response.
While I can not really argue against refactoring code into extra
functions: Please note that every function you add generates some
overhead = slower program. In the (I think it was the) calendar app I
once inlined the code of a function I previously extracted because it
slowed the execution by 100ms (It was called multiple times).While this might be true in alot of real world projects, there isn't any direct correlation between oo approach and slower code. Javascript was never designed for it, which makes it harder to do well.
What would you change e.g. for GPS? You have setGPSPower(), isGPSOn(),
getGPSFix() and the GPS event on the Bangle-Object.I was thinking higher level. I can give good examples once I look at the source code more and start making an app - which will almost certainly result in a side library for gps stuff.
Those examples you give are of the core functions. So firstly on those. If you call getGPSFix() and gps power has not been set on, what happens? I wouldn't suggest changing the core function to auto turn it on, as may be a reason you call getGPSFix without turning on GPS. However in most cases I imagine turning GPS on first is a requirement. So if create a higher level object like a GPS manager, calling myGpsManager.getFix() would check if GPS is currently on, if not set it on first.
At even higher level, its likely alot of apps actually want to do the same thing once they have GPS location, like overlay position on an openstreetmap tile. So having pure helper libraries which are not apps themselves, just code to import can massively speed up new projects.
I see your points, I'm just skeptical that every refactoring someone
would make in a Browser/Node.js environment is a good idea in a
resource constrainWill come back with examples once I have started building an app. I think some of the stuff is that I am coming from a world of large scale apps, typescript with webpack or similar to tree shake and remove unused stuff, minify if needed, flatten to single file if needed.
charlie-
Those examples you give are of the core functions. So firstly on those. If you call getGPSFix() and gps power has not been set on, what happens? I wouldn't suggest changing the core function to auto turn it on, as may be a reason you call getGPSFix without turning on GPS. However in most cases I imagine turning GPS on first is a requirement. So if create a higher level object like a GPS manager, calling myGpsManager.getFix() would check if GPS is currently on, if not set it on first.
Well for the GPS example: If on GPS will drain the battery in ~4 hours. Also after turning it on it needs ~30 seconds (can be much more, up to nearly 15 minutes or a bit less, simplified for this example) until you receive valid data. So what a user usually does not want is
- Have GPS powered on randomly
- Enable GPS, read data, disable GPS
Instead I want to control when to power on GPS or not. When reading the position continously I just want to power on GPS on start and never disable it again (until the app closes). If the use case is to get a position every hour or so the myGpsManager.getFix() (as promise I assume?) might be ok, but if needed can be written a less then 5 minutes, no need to import a big library with maybe 100 functions that are unused.
At even higher level, its likely alot of apps actually want to do the same thing once they have GPS location, like overlay position on an openstreetmap tile.
Currently the only use case I see for overlaying the current position on a map is the openstmap-app and it already does that. Well you could maybe combine "GPS Navigation" or "GPS Trekking" with "openstmap" e.g. overlaying current waypoint and your position on a map (your turn @halemmerich) but you will quickly run into memory constraints, at least on Bangle.js 1.
Will come back with examples once I have started building an app.
Cool every PR brings the ecosystem forward.
- Have GPS powered on randomly
user140377
Let me try to answer at least some of your questions:
However I do not find it useful to automatically have a settings-file in every new app I create. If the settings-file is unused it just creates useless overhead. While there is some annoying overhead when creating a new app (metadata, icon add about 5 minutes of work) I currently do not see much potential of improvement here.
While I can not really argue against refactoring code into extra functions: Please note that every function you add generates some overhead = slower program. In the (I think it was the) calendar app I once inlined the code of a function I previously extracted because it slowed the execution by 100ms (It was called multiple times).
Needs more memory, Bangle.js 2 has 256kB of RAM, Bangle.js 1 has much less and we already are at the limit the memory can handle, e.g. the run app on Bangle.js 1.
What would you change e.g. for GPS? You have setGPSPower(), isGPSOn(), getGPSFix() and the GPS event on the Bangle-Object. What would you make different? There are also some extra modules like modules/buzz.js
Lets take the Anton clock as an agument against, there are two versions of it: Anton Clock and Anton Clock Plus. The latter includes some extra code that you notice when starting the clock (feel free to try it out).
Do you have a specific (small) example, e.g. an app where you would refactor something? Or maybe comment on an existing pull request on what you would make different? (However I can not speak for all authors if they want your comments)
Disclaimer: I'm not an espruino expert, I'm just someone who made one or two changes to Bangle.js apps.
I see your points, I'm just skeptical that every refactoring someone would make in a Browser/Node.js environment is a good idea in a resource constraint one.