Open camerojo opened 1 month ago
camerojo
commented
1 month ago Hi @MuhannedNoman . You have probably already found this - but if not here is what Chat GPT had to say about Angular support for this:
https://chatgpt.com/share/6711b46b-9610-800f-a68c-5426a211afd3
Also https://angular.dev/ecosystem/service-workers/getting-started
camerojo
commented
1 month ago Take a look at Stomp and Websockets. It supports our chats - using subscribe and publish.
https://spring.io/guides/gs/messaging-stomp-websocket
Hi @MuhannedNoman - you also mentioned Firebase Cloud Messaging (FCM) for notifications. Thanks for drawing this to our attention. I don't think it will replace our basic websocket based chats. But I think that we might consider using it for efficiently delivering notifications to mobile phones (even when our app is not running).
FCM is only one option of a few which seem to all be the same - mainly from browser makers. Seehttps://stackoverflow.com/questions/33687298/how-to-send-push-notification-to-web-browser
Below is what Chat GPT had to say about the advantages (in response to my question: "How is FCM battery efficient"). Not something to be focussing on now (let's get that Minimal Viable Product going) - but just noting it for the future. fyi @sadatmalik
Firebase Cloud Messaging (FCM) is designed to be battery efficient, which is crucial for mobile applications that rely on notifications but want to avoid excessive battery drain on users’ devices. Here’s how FCM achieves battery efficiency:
High-Priority vs. Normal-Priority Messages: FCM offers two types of message priorities:
Push Notification Consolidation: FCM consolidates push requests to avoid multiple notifications being sent separately. By combining notifications from different sources, it reduces network traffic and, in turn, power consumption.
Adaptive Sync Intervals: FCM automatically adjusts the frequency of sync intervals based on user activity patterns, network conditions, and device state. This adaptability reduces the frequency of network requests, lowering battery usage when the device is not actively in use.
Network Management: FCM optimizes how and when network resources are used. By minimizing the amount of data sent and leveraging lower-power connections where possible, it avoids the more energy-draining use of cellular data for push notifications.
Doze Mode and App Standby Support: FCM respects Android's Doze Mode and App Standby Mode, which reduce network access and restrict CPU-intensive tasks when the device is idle or apps are unused. FCM waits to send normal-priority messages until the device exits Doze Mode, which conserves battery.
These mechanisms enable FCM to deliver notifications reliably without frequent or unnecessary wake-ups, maintaining responsiveness while being mindful of battery impact.
camerojo
commented
4 weeks ago Progressive Web apps. Good intro with major real life examples https://business.adobe.com/blog/basics/progressive-web-app-examples
Angular notifications https://blog.angular-university.io/angular-push-notifications/
MuhannedNoman
commented
3 weeks ago Here are some interesting links that I found:
As developers we need to understand exactly what candidates see as the advantages of having a "mobile app" so that we can explore all alternatives for providing that functionality.
Speaking to users, this is what they consider as an "app":
It may be possible for us to deliver all the above functionality from a web browser application - ie our standard Angular code.
Regarding the icon appearing on their phone, there is an "installation" challenge here. But perhaps that could be addressed by a minimal "bootstrap" app that we write that does nothing more than install a TC icon, and on launch does a login if necessary and then delegates to our standard candidate portal browser app (running within the mobile's browser - eg Chrome, Safari etc).
What we will be missing by not actually having a standard native Android or Ios app is access to some low level native functionality of the phone. But we will probably lose that as well using technology like Ionic - and we have already agreed that we don't need native functionality that is not already available from a browser app (we already have access to the phone's camera, Geo location etc).