-
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
You are reading a single comment by @user140377 and its replies.
Click here to read the full conversation.
user140377
Appreciate you taking the time for this response.
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.
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.
Will 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.