Overlay Notifications #5437
Replies: 1 comment
-
Posted at 2022-09-16 by rigrig Using I'm working on my own messages app (also WIP), some thoughts: I took the route of changing the In general, what I think would be the thing to aim for:
Especially hoping we can get "fast app switching" to work, so we could have e.g. different music players/message viewing apps working smoothly together. Posted at 2022-09-16 by Sir_Indy Hi rigrig, I like your ideas, and different apps handling I've not been keeping up with fast app switching, it sounds promising! Posted at 2022-09-17 by Alessandro Hi! Didn't know about setLCDOverlay, it's awesome! Just installed your test apps, really nice concept, I really like it, thank you! Posted at 2022-09-21 by @gfwilliams I guess from my point of view, quite a lot of work has gone into trying to de-duplicate code and use the messages library for Gadgetbridge and iOS, so ideally we'd keep that. Also @rigrig has some code (which I really do want to get in soon, honest!) that uses a different way of storing messages which should be a lot better. Sending events sounds good though... Or potentially we could do:
And then if something was installed that could handle messages we could defer to that. That could be a good solution that worked without causing trouble for everyone else that just had the default apps installed.
That would be great - I think right now there is only a fullscreen option for Bangle.js 2 which really isn't very good at all. Posted at 2022-09-21 by rigrig I like the idea of just keeping the default messages app/widget with the library and deferring to custom apps if installed. Maybe we could even do something like this:
Posted at 2022-09-21 by @gfwilliams
Yes, I think this makes a lot of sense. Having one extra file (for the app) is not a big deal even if it's not used, and it would still be good for managing messages. Maybe later we can split it out, but right now I think it makes a lot of sense to keep it.
Yes - that looks great to me. That seems like a really neat pattern that we could probably use in other places too. Posted at 2022-09-21 by Sir_Indy Thanks for your input everyone. I agree that we shouldn't duplicate code, I only made my own version rather than changed the Android app so I could go back to the standard one if I needed to (i.e. when I mucked it up!). The Overlay Notification is coming together well, at least well enough for a first version. I really like the idea of adding something that a custom app can tie into, but would fall back on the default if nothing is there. Let me see if I understand @rigrig's idea:
I'll have a go at incorporating that into the Android app code and trying it! Posted at 2022-09-21 by rigrig That's the basic idea, except we don't want to do it in the So it becomes
I've pretty much already done this here, except that is written as a replacement And as @gfwilliams noted above, there is a PR waiting which also makes some drastic changes to the library. Also rewriting it into an event driven system might complicate merging "a bit" ;-) Posted at 2022-09-22 by Sir_Indy I'm confused, let me try and explain more what I'm trying to do. My use case for notifications on the Bangle is to see if it's something I need to do immediately, or if it will keep. When I hear the bing on the phone, or feel the buzz of the bangle, I can look at the Bangle, read the whole message, ideally as much text as possible without having to touch the screen. Then, I can ignore it, wait for it to time out or manually dismiss it, or if it's something I need to do something about, I go to the phone. I can see that the new messages app will be great, but I'd like something much, much simpler: no storage, no responses, no widget, just very fast and clear text. So the idea to put a switch in the Android app (and match it in the iOS app) to emit a signal, check if it's handled in a custom app, launch the Messages app if it is not handled, sounds ideal to me. As a bonus, it creates a way for anyone to make custom apps that tie into messages, or music, or calls, but the standard Messages will still load for everyone by default. I'll try making the changes to make the Android/ios app emit messages. If I do it correctly, it won't make any difference to anyone else. If it turns out to be a terrible idea I won't submit it to be merged, but I'd like to try. Posted at 2022-09-22 by rigrig
The point is that the Android and iOS apps both call Posted at 2022-09-23 by @gfwilliams
This is really not something I want to include in the app loader, given we've spent a lot of time trying to avoid duplication. If you actually benchmark it, I bet you'll find that the actual time saved by duplicating the code vs just putting it in the messages app is 1/1000th of a second or so... Really not worth it.
Ahh, sorry - I misunderstood... So if you don't want any storage, I think the best bet is for you to come up with a complete replacement for the Right now, Android and iOS apps have a So then all anyone has to do is install the Android app, and your new It's worth adding that some of the delay between the phone buzz and the Bangle showing the message can also be from the phone sending the message to Bangle.js. You could do Posted at 2022-09-23 by rigrig
I tried that and reverted it, as it turned out to be a bit tricky: if you change And hopefully you won't have to anyway, my Plan now is:
Posted at 2022-09-23 by Sir_Indy Thank you @gfwilliams, I think I understand now. I will leave the Changing the So @rigrig, thanks for looking into it, but don't worry about making any changes to your Sorry for causing confusion! As for speed, in my tests so far I have a bit of boot code that listens for a message and shows a notification. It feels instant, certainly fast enough. I think it's just avoiding launching a whole app and waiting for the 'Loading...' screen to pass that takes the time. I'll avoid tweaks that would reduce battery life, that's one of the best things about the Bangle! Posted at 2022-09-24 by rigrig @Sir_Indy Oh, it isn't solely for your benefit ;-) It would also allow me to remove duplicate code from
Posted at 2022-11-04 by Rarder44 sorry, english is not my mother tongue and i may have missed something. Couldn't you implant the message event emit directly from the Android app? Posted at 2022-11-05 by rigrig Yeah, it's a bit complicated :-(
I am trying to separate the library/app code some more, so that it will really be like just two things (library and app) that just happen to be installed together. Posted at 2022-11-07 by Sir_Indy
I agree that breaking out the message library functions would be a good idea. My problem with using the message app to pass events on to a custom app, is that the message app still shows as installed, and listed in the launcher. I think this would confuse users. Thank you @Rarder44, I've been thinking similar things. Is there anything eslse we could do to make it less complicated? Ignoring for a moment what we already have, what would be the best way to handle communications? Do we even need a message library if we change to firing events rather than importing Posted at 2022-11-07 by rigrig
Good point.
The library also handles storing messages and buzzing/icons, we don't want to duplicate all that code for every custom app. (And moving it to a module would mean it getting included into boot code) Here's an idea: change the
Posted at 2022-11-07 by @gfwilliams
You could yes, but then the messages library would have to be loaded at the start every time so it could respond to the event. Given the effort we've just spent reducing loading times, adding more time+complexity to the boot process seems like a step backwards. However maybe the way messages are stored could be swapped out by different apps (eg @rigrig's code for using a StorageFile instead of Storage, or even just not storing messages at all).
Yes, this might work - I think rather than adding This is probably more flexible going forward and I think there are a few existing dependencies we could probably implement better that way too? There is the potential to split things out into special apps that handle each bit :
However I would rather do this at the point where we can merge in replacement apps/libraries that folks can actually use. Right now, as @rigrig has proved, absolutely nothing stops you from forking the app loader and providing your own messages app implementation (or even a separate app that overrides some functionality). Until contributors have things they feel ready to contribute to the main app loader, I think we're just solving a problem that doesn't exist. Posted at 2022-11-07 by Sir_Indy Thank you Gordon for taking the time to explain that. I think I understand slightly better now. I will try and work with the current system, and if that doesn't work run it from my own app loader. I haven't had time recently to work on this but hope to get back to it soon. The thing I really want to avoid is going in a different direction that can't be merged in! Posted at 2022-11-07 by Rarder44
I believe this can be a good solution.
you are right; this is the solution i am currently using. another solution (a little less event-driver, I don't know if you like it) is to divide the graphics from the logic into 2 separate files (or something similar) in the message app; the graphics file could be a standard name (message.GUI.js) and so if everyone wants to customize the graphics, they could "just" write their own app, which overwrites that file. Posted at 2022-11-11 by @gfwilliams
Interesting - so you mean the code itself that displays the message on the screen? So there'd be an app/file that shows the list of messages, and then that calls out to another one to actually display them? Posted at 2022-11-11 by Rarder44 a premise: I was thinking more of an app that manages the receiption of the message, (saves in the storage, sets the additional parameters to the msg, etc.) and another that ONLY implements the show functions Actually these days I was thinking about it, especially the optimization speech and two ideas came to mind that could be used (at least partially): to manage everything in events, it is not necessary to move all the code during the boot phase, but only the "pushMessage" function which at this point could be cleaned of all those references to the actions to be done (load message, turn on the screen, etc.) leave only the code that "understands" the type of message and launches the appropriate event. The message app, (or who will intercept the event) will not necessarily have to load everything in the boot, but something similar will suffice Bangle.on ("message", msg => { so in the boot area only a few references will remain and each app will manage the events independently. we would only have to think about a question of "priority" and handling of the event, but I think that is the least of the problems. the advantage of this methodology is that multiple apps could register and handle the same event (for example an app that tracks a specific notification, along with the standard messsage app) if instead we want to keep the performances to the maximum, then we could:
When loading the app from the appstore, we can merge all these files to create a single file that works exactly like the actual message app. we could therefore think of a way to "choose" the GUI part that you want to install (such as customizing the app from the AppStore, or a separate app that does the same procedure during installation). I know it's a bit of an overkill but it should allow you to logically divide the "graphics" from the "code" without practically affecting performance (the message app would work exactly as it does now) Posted at 2022-11-15 by Rarder44 Posted at 2022-11-15 by @gfwilliams Hi - Thanks for the PR. Obviously it's a draft but there are some issues I can see...
As you say If we did something like:
It would solve the 'handled' issue as long as other apps 'numbered' their boot code so they could ensure it got executed first. I'd be inclined to push What do others think? Adding a handler for the
Right now, a message comes in from the phone, is handled by the Android app, goes to the messages library where it is stored, and then the messages app displays it.
Posted at 2022-11-15 by Rarder44
yes yes, I know there are some problems, before continuing I wanted to know if the methodology could be good.
that's more or less the solution I was thinking of (and which is currently implemented as a workaround in the "message")
at the beginning I had implemented only one event; logically it seemed clearer to me to divide it ( message, call, music, other... ).
certainly a more "open" program uses more resources but I think it's more convenient, in a modular environment like this, to manage the various apps as separate things. the point is to try to understand if we want to implement a logic where multiple apps can manage various types of messages, or if the "notifications" world must be closed (it is true that everyone can implement their app as they see fit, but this means code fragmentation and poor management/updates). I think so:
if, on the other hand, we don't want to give the possibility of managing notifications to multiple apps, it would be convenient to be able to change the app that is called by the Android/IOS app give the possibility to write the name of the app to be called in the "android.settings.json" file (by default it would be "message") and then replace the occurrences with:
so that if one wants to implement his own app he could do something like this:
all apps should work as usual and you would have the possibility to manage messages with any app (if desired, the custom app could still call the require("message").pushMessage(...) ) let's say this solution is a hybrid. it shouldn't add any boot code, just an additional variable in the "android.settings.json" file (which is already read during boot so it doesn't slow down / take up more space)
it was an idea, but perhaps much more complex to apply and which made everything even more restrictive in some respects. Posted at 2022-11-16 by rigrig
It feels rather hacky, but it works, and is cleaned up automatically when you uninstall the app. Posted at 2022-11-16 by Rarder44
yes it works, but I don't really like the approach... I think that keeping these methodologies leads to some apps struggling to communicate with others in the end. At this point I would override the "require" function so as not to directly load the "message" library (and its pushMessage ) Posted at 2022-11-17 by Rarder44 since at the moment there is another PR who is modifying the app message ( espruino/BangleApps#1498 ) and who is implementing some sort of events; I would say that it is useful to understand how to proceed (so as to avoid writing unnecessarily code ) Posted at 2022-11-18 by @gfwilliams One reason I'm a bit against this is that you assume that As I'd said above we can trivially modify the dependency field in the app loader (the code for this is already there now I've pulled out the icons to messageicons) so that the 'messages' library can be provided by any app that wants to handle messages. For example right now we have I don't think you ever really answered this, but IMO it's important:
It makes a difference where we need to open up the API. For instance it's no use implementing the event as you say if all you want to do is change the way messages are displayed in the messages app - because then you'd just end up duplicating all the code to handle reading/writing In that case, what we really care about is what you said initially - a way to split off the GUI parts to different apps/files. And I'm all for that, because I think it solves a real problem - one of the main complaints is people want to display messages differently (although nobody is yet to make a PR to actually just improve the standard message app :( ). Posted at 2022-11-18 by @gfwilliams @rigrig obviously you're working on espruino/BangleApps#2205 at the moment As we are sending an event, do you think it's compatible with just sending the event direct from Android/iOS? Right now the messages app probably wants to handle I think it would really help to think about what we want to use this for All I can think right now is: MusicWe get the event in the music app, mark it handled so it doesn't get stored in Although if we split out the GUI for the existing music app in the messages app, that could maybe fix this more nicely, and would reduce duplication on the watch. 'new message' overlayWhat this thread was initially about. Personally, I'm imagining that the message (or part of it) would appear in an overlay in the current app, but then if you tap it, you go to the messages app where you can see it in more detail (maybe scrolling). Swiping the overlay could dismiss it and mark it read. So in that case, we probably still want the messages library to be storing the message? but we don't want it to automatically load the messages app - we want to let the overlay do that. So maybe we want Or do we want to not store the message until there's a user interaction with the overlay? That could be tricky, and if something happens (maybe an alarm goes off and the alarm app is loaded?) the message could get lost. Messages widgetWe already have CallsAgain, I guess an overlay for this is good. And in this case maybe we don't want to store anything in ....... is there any other use case I'm missing? But I'm still struggling to see why we need to emit the event from Android/iOS (apart from it maybe being a bit tidier). I think we can pretty much do what's needed as-is? As I mentioned in the last post, there can always be different apps implementing the By having the event, we potentially end up in a situation where we have multiple apps storing the same message in different ways. And then if you delete the message on one app, it's not deleted in the other one. It also doesn't ensure that when a user installs The more I think about this, the more I feel like we could have one messages library that all apps can interact with to add/remove messages. But we make sure that library can be implemented by any app that wants to (eg like Posted at 2022-11-18 by Rarder44
that's exactly what I meant, move all the logic ( saving messages, managing music... ) to an app/library/... and move the GUI to a separate app (perhaps with an app type like for example "clock" ) I believe this "library" should provide the basic methods which can then be used and configured by the user / by whoever will program the GUI. for example I find it "wrong" that the pushMessage automatically saves the messages that arrive; I believe that the two things ( message management / message saving ) are 2 separate things and the library should give the possibility to use the two functions separately. ( PERSONAL OPINION: I find that the management of saves, views, etc via "handled"/"noMessageApp" is confusing and in the long run difficult to manage, maintain and document correctly; but I repeat it is a PERSONAL OPINION )
however it could also be that different apps need to store different types of messages and therefore not centralize everything in a single list... mine are just hypotheses
this methodology for me has a "problem" (I'm not saying it's serious but more "annoying") in theory, these problems could be solved (at least partially) by providing a specific type of app for displaying messages. (I saw that the "notify" type exists but from what I understand it's an "old" method for handling notifications, right? ) TL;DR;
PS: with @rigrig 's suggestion i implemented a message app which i'll ask for a PR.
I think the problem is that everyone would like an ad-hoc app, and honestly I wouldn't want to touch the GUI/functionality of a program when others like it, I prefer to implement my own version. Posted at 2022-11-18 by rigrig
Well, I'm working on my own messages app, but it makes big changes to how messages are displayed, so I'd be reluctant to make a PR to "completely replace" the messages app.
My idea was that
We can save it in
A problem with
Yeah, that was the idea. Same goes for widgets.
I agree, and I think right now things are confusing because a) we bundle the library with the default GUI, and b) the library+GUI are too tightly coupled. What I'd like to do:
I think that since this commit, we can split the library into a "module". Proposed
The overlay notification app can then
And we could think about adding music/call overlays either to the default GUI, or as separate apps. Posted at 2022-11-18 by @gfwilliams Ok, great! I think we're basically in agreement then.. So we'll split out:
(I already split out the icons) And maybe we'll have to think about how the messages app can be split up such that we can have override-able displays for messages/map/media.
Yes, I think so...
Yes, unfortunately - although we should now at least make a proper notify for Bangle.js 2 that uses overlays
Yes, I agree. It's just how to handle each of:
But maybe as @rigrig says we make the save explicit? I'm not sure I've got my head around how yet though. But potentially with the new fast load functionality, we don't even have to save the messages before loading the messages app (and then we leave the messages app to save them when it exits). ... and if it can 'fast exit' and go to the clock, it wouldn't even need to save then either.
Could do... The messages app (and notify icon) was an easy way to get to music though... I don't know if people use it, but it seemed convenient Posted at 2022-11-18 by @thyttan
There're metrics hinting regarding this, namely installs and favourites of Messages Music in the app loader, 5 and 7 respectively when I view it now. How to interpret those I'm not sure though. Posted at 2022-11-21 by rigrig I made a draft PR. How it works now:
Note that the Some things I ran into:
Yeah, probably best to leave it in, and custom music apps can catch the event before it leaves the default GUI. Posted at 2022-11-21 by @gfwilliams Only just saw this - I made some comments on the PR though: espruino/BangleApps#2297 This seems great. I'm not sure if you have any thoughts on this, but (as a second step after this) it would be nice to split out the different GUI parts - so if you tapped on a message in the list in the Messages app, it could be handled by a different app. I'm thinking something like:
Then the It's not great, but it's hard to have something that: a) doesn't take up RAM (or extra boot time) all the time We also do similar things for settings, recorder plugins, and clock_info so this isn't that new Posted at 2022-11-21 by rigrig
On the one hand, it seems a nice idea. Another thing we might look at is response actions, I'd like to have an easy way to just add custom response actions for e.g. Home-Assistant notifications, without having to code up a new screen. (But that's on the list below figuring out responses, and whether we can get GadgetBridge to pass action buttons) Posted at 2022-11-23 by @gfwilliams
That sounds neat! I guess in that case your new messagesgui app (that is the list) just always says 'yes I can display this message'. I guess it still leaves open the possibility that some other app (like navigation?) might be installed and would want to handle the message instead, in which case I guess that is still fine?
Yes, that'd be a neat one for later.
I hope so... I seem to recall it can pass some info already? Posted at 2022-11-29 by fanoushs-punching-bag @gfwilliams, navigation directions staying up with a large direction arrow, etc, this would be awesome. An active google maps navigation session would be cool. Pebble's NavMe might be a good starting point. Posted at 2022-11-30 by @gfwilliams There's already something in Gadgetbridge that handles OpenStreetMap directions at https://codeberg.org/Freeyourgadget/Gadgetbridge/issues/2387 - unfortunately Google Maps doesn't appear to expose directions in anything other than a notification but I think that if the above code is merged in, it shouldn't be too hard to parse navigation directions out of the Google Maps notification (at least for english language) Posted at 2022-12-06 by fanoushs-punching-bag @gfwilliams, ya! That's what I was thinking. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-09-16 by Sir_Indy
I've been wanted to change the way notifications work for a while, and finally have a proof of concept ready to work with, using the new
Bangle.SetLCDOverlay
from Gordon.Firstly, big thanks to Gordon for this new feature , it's fabulous! Exactly what I was looking for, though I didn't know it before!
Goals:
My new notification system replaces the Android app on the watch with a very slightly tweaked version. Instead of linking into the Messages app it emits events, which can then be picked up by other apps.
The notifications themselves use
SetLCDOverlay
to show a message over the top of whatever you have on screen at the time. They're scrollable (sort of) for long messages, but have no actions, they simply show you the notification.It is very, very low quality at the moment, lots of missing features, but does show notifications. To try it out, remove your
Android
andMessages
app from your Bangle, and install the two apps here: https://sir-indy.github.io/BangleApps/?q=aaBe aware that I'm actively working on this and it could change or break without warning!
Things to do:
notify
type app, so others can use it.If anyone has any thoughts they'd like to share about my way of doing this, or suggestions to make things work better, please let me know. Just be aware that I'm primarily making this for myself and my use case, so may not implement every idea.
PS. there was supposed to be a screenshot attached, but I can't use
g.dump()
to get an image of the Overlay. Sorry!Beta Was this translation helpful? Give feedback.
All reactions