-
• #3
Sorry for the delay - I'm on holiday at the moment but when I return next week I'll be putting some development devices for sale in the store.
I currently have around 3000 of these new watches on order (with Covid/etc everything takes ages now) and I'll likely be doing some kind of crowdfunding/pre-order for them.
While the hardware is sorted and the watch firmware is basically there, I'd still like to try and get apps/etc a bit more sorted this time before I call it a 'proper' release.
-
• #4
Does it have all the same features of the previous Bangle Js because the hackaday.io page says that the HR Sensor doesn't work.
-
• #5
.
-
• #6
the hackaday.io page says that the HR Sensor doesn't work.
that's outdated info, there was not much info about that vcare vc31 chip however situation has improved, some interesting stuff appeared on github
-
• #7
Where can I get updated info?
-
• #8
Going forward, https://www.espruino.com/Bangle.js2 will have more details.
I do have a build for the heart rate sensor at https://github.com/espruino/Espruino/tree/VC31 - it still needs some work but I hope it'll be merged this week and at that point I'll update the hackaday page's status
-
• #9
Just a quick note to say the developer edition is now on the shop: https://shop.espruino.com/banglejs2-dev
It's a bit pricey but that's just because it was pretty painful for me to get this first set (high postage/customs), I think there will be a bunch of questions about how to use it, and I also only think you should get this if you're really desperate :)
It won't be long to wait until I'm ready to ship a proper device that's a lot quicker to get started with!
-
• #10
How much modification requires the bangle.js code to work?
Can the firmware for Q3 map buttons and functions to avoid too much code modification? -
• #11
I did originally start off with fake buttons (using the RHS of the touchscreen) and the ability to scale the 240px screen down.
However honestly, every app I tried was still barely usable, so those changes ended up getting backed out. The plan is to try and move apps over to a Layout library: https://github.com/espruino/BangleApps/blob/master/modules/Layout.js
So changes required might look like this: https://github.com/espruino/BangleApps/commit/0410a0dd8e1eaef230e69e4904c1305876b0977c
I still have to do some work on it to improve speed (I may even build it into Espruino), but it feels like a better way forward. It should make life easier for most people, but also allows other devices with different screens (or even just different layouts of widgets/etc) to be targeted in the future.
-
• #12
I looked at the code changes. Bottom line: introduction of an abstraction layer. Replacing direct display/input control with metadata driven display/input control, where the meta data is the layout, and handling of the display/input is in the layout interpretation code (scaling, etc.).
I can understand the expectation that a scaling (using the templates) can handle the different hardwares. When it comes to screen size with congruency, it may work... but that is about it. I'd rather have the layout being device specific... and, in a 1st phase with templates that are static after construction, and in 2nd phase enabled to dynamically perform some transformations - out of the box as well as custom. Btw, the template constructor has to accept a config or parm object to make it data controlled.
This raises the number of moving parts but makes it much easier to implement, and second adapt to the uniqueness of the devices that cannot be handled by scaling, such as colors, different input, physical limitations, omitted elements, etc. and avoid compromises, better runtime performance in cycles and footprint.
In other words, every app has its (across devices shared) core components (file(s)) and some complements that are device specific. On application (down)load/install, the shared core components are loaded and then only the device specific one/s is/are loaded.
After having built the espruino.com/ui (more - pics - at Modular and extensible UI framework and ui elements) for 240x320 262 Colors TFT w/ touch screen, I tried to adapt it to non-touch screen - just buttons - and then to Pixl.js, I come to this conclusion / recommendation: rather draw the line tighter on 'auto-adjust to underlaying hardware / constraints' and provide a support system to handle the efficient, hardware specific/dedicated components, then avoid device specific components and do everything automatically. This approach allows also an easier life cycle management, because at one time Bangle.version x-n phases out and Bangle version x+m joins the family, and bangle.version x-n support can be dropped without code change, and version x+m can gradually phase in with apps of interest get the device dedicated components built on demand.
It is also much easier to write a display/input emulator to develop and verify the device specific compoents.
-
• #13
In an ideal world yes, we could just have static layouts for each device - but I think it's a lot of tooling to do, and I'm not sure most app developers would be interested in trying to develop a layout for a second (or even third) device that they don't have...
-
• #14
Either way, is it planned to have the emulator or emulators do the device specifics?
...like: espruino.com/ide/emulator.html?banglejs1 ...html?banlejs2 ...?dev=banglejs1 ...
-
• #15
is it planned to have the emulator or emulators do the device specifics?
Yes, although I need to figure out a nice way of doing it. Hopefully eventually we can have Pixl.js as well.
Is there a new Bangle.js? :-)