Develop Reference

Not sure how to design in app notifications from interactions (likes, share, etc...)

I am developing an Android application in Kotlin that can be thought of as similar to Instagram.
I am designing how to implement my in-app notifications. By "in-app notifications" I mean interactions such as likes, publication sharing, new chat message, etc.
For the moment, I do want foreground notifications. The notifications would not involve any view component.
The proposed flow would be:
Interaction action from Client_1 (like, share, message) triggers an Event_A in the server.
Event_A produces a state change and generates a notification to Client_2.
Client_2 receives the notification
a. Display a badge in the notification icon bar.
b. Generates a new item in the notifications list when Client_2 open it.
I make this clarification because, while searching this, I've seen "in-app notifications" are related to campaigns, publicity, new features, etc.
So far, I though two possible implementations but not sure if they are the right ones.
1 - Web Sockets
My app already uses Web Sockets for handling chat messages. However, so far, the connection is only open when the user enters to the chat view.
I consider easy to implement but this implies having an open connection the entire time the user is on the app and may be an unnecessary load for the server and an increment on Web Socket's time session.
2 - SNS + FCM
I've found that AWS SNS and FCM (Firebase Cloud Messaging) is a common approach for handling notifications.
However, reading the Firebase's documentation and examples, I understand it's mostly used for the other kind of in-apps notifications (campaigns, publicity, new features, etc).
In this FCM's documentation, it defines two types of messages: Notification Messages and Data Messages. I understand, Data Messages would be more appropiate for my use case.
Don't know it is worth the complexity of configuring FCM and handling the token's lifecycle.
So, my questions are:
Are the above scenarios good approaches? Is there any other way to achieve this?
Which is the correct term for this kind of notifications?

FCM is just normal push messaging. It can be used for any type of data. It's just a general method for a server to push data to an app, even if the app isn't running at the moment. So it's the right answer. The problem with web sockets is it won't work if your app is shut down either by the user or by the system.

Using push notifications to trigger code within Android app?

Using a serverless architecture built on AWS, I'm looking for the best way to have users receive near-instant notifications of new "chats" within my Android app. I don't necessarily want to see a push notification appear in the phone's notification tray - I just want the app to listen for new messages, and update the view accordingly.
Here's my thinking: every time a user sends a chat, I'd basically trigger a Lambda function which would call SNS or IoT to publish the notification to any subscribed users of this chat.
But since SNS / IoT both work by sending "push notifications" to the phone, does that mean the message would have to appear within the phone's notification tray? I'm just looking for a way for my app to silently receive near-instant notifications from AWS and execute code to update its view.
Some other notes:
1) I don't want to build this using a server / EC2 with websocket listeners - I'd rather go serverless.
2) I've looked in Google's Firebase real-time DB which looks very capable, but as the rest of my architecture is on AWS, I'd like to stay there if possible

If you are making app for Android only, you can make use of the data message in FCM from Firebase. You can handle the message in onMessageReceived no matter your apps is on Foreground or Background.
Apart from that, firebase provide integration with most server side language. You should be able to send the message in your lambda function.

my suggestion is using FireBase...
and make your Json tag with "data" than "Notification"

create my own push notification service without fcm , pusher ,

I want to create a notification system provider that is not based on Google services or similar. In fact, I want to get information about its overall architecture and needed Android sdk functionality.
The most weird point for me is to understand how to send a notification to an Android device.
I mean, how can I identify the Android device on which my application is installed from millions and millions of other Android devices on the Internet?
And how do I send information to him?
Should I use sockets for this or similar stuff?

simple answer: YOU CAN NOT
before everything else i should correct your question, pusher and FCM are not in the same group at all! you can build somthing like pusher or oneSignal or etc but you can not build something like FCM/APNS
you should understand three simple yet important sentences below:
when you want to pull anything from place_1(e.g. api) to place_2(e.g. browser_client) you most have an identifier of the place_1_resource (which commonly is the uniform-resource-locator of api)
when you want to push anything from place_1(e.g. notification_central_server) to place_2(cellphone_client) you most have an identifier of the place_2_resource
you must know the differences between a real server push with server-push-like technologies like long-pulling or ... and you should be aware that what is intended in this concept is a real server push not any kind of pulling with a push jacket!
if you don't have any identifier for a cellphone which you want to send it a notification, your server dont know where to send that notification so we need a resource_identifier_like for cellphones which is actually a device_token_like and you have just one approach to get this device_token_like and that is the FCM/APNS
FCM is like a dns server containing all identifiers of every android device that google supports (almost every android device) and APNS is just the same but for apple devices
note1: even if your app can obtain it's corresponding device device_token_like it can not be used for push notification if its not registered on FCM/APNS
so when you get that device_token_like identifier of your desired clinet_device now you can use different approaches for sending sth to that clinet_device. there are several approaches like SSE, Webpush, HTTP_server_push, Pushlet and etc but none of these approaches supported by mother_companies of these devices, the only approach that is completely supported and standard is the same approach that FCM/APNS official websites suggests
for example an iranian Incorporation named najva uses webpush to send notifications because of USA sanctions but webPush method works good on browsers and android devices but they didn't even apear on an apple devices
finally i should say that i admire your curiosity to less using anything from a benefit_based Inc. like FCM/APNS in your developing but i strongly recommend these articles and books for you cause i think you didn't learn enough:
wikipedia of push technology
story of some guy who tries to make his own push notification service
Push Technology A Complete Guide - 2020 Edition
Data Push Apps with HTML5 SSE

Short, direct answer
You can't (At least till you create your own ROM)
TL;DR, Reason why?
Before you build your own push notification server, you first need to know how it works internally in android.
Whenever you/your server sends a push notification message to the android client, the SDK processes it and shows you the notification. But when your app is not running (or being killed), your app cannot respond to it since it was not running. In such a case, your notification message is sent to a system service which is known as Google play service. For this even to work, you will first need to bind your app with Google play service and that is what FCM does. FCM SDK registers your app to the operating system service on the first initialization. That FCM service is opened to a port which listened to the incoming message from the server and when it receives the message, it publishes a notification on behalf of your app with a PendingIntent containing the data. Then the PendingIntent is delivered to your app when the user clicks it and then finally your app process the data (or the push message)
So basically, for your server to communicate with the client, It first needs to communicate with the FCM service and for that, FCM gives you a token which identifies the application to register with the internal Google play service.
Simplified furthermore, the workflow is as follows:-
Server send push message ---> FCM ---> Google play service,
If your app is running, it is directly handled by the client SDK So, Google play service --> Your app
If not, then it is delivered by the service itself using PendingIntent So, Google play service --> PendingIntent --->| Publish notification
Totally impossible, Workaround?
There is nothing like impossible because an absolute impossibility doesn't exist. Saying impossible generally means near to impossible. (This is similar to math where also we say tends to infinity because no one has achieved it yet).
To make it work, you need to somehow bind your app to the Google play service and you can't because Google hasn't exposed any direct API to do that. The only possible way is using the FCM ;-) (Bad luck again). So the only possible way is to build your own custom ROM with a custom push service that acts as a client for your Push server and a Server for your Push client (which is your app).
Since the above option tends to impossibility, you have to choose a workaround.
The best among the worst workarounds are:-
To make a malicious SDK.
Malicious because it needs to keep the app running in the background with a service that is connected to a WebSocket endpoint of your server. (Harder in new android versions).
Make use of a database where your push notification is saved and your app checks it periodically using AlarmManager.
Hope you have got the point.

Amazon SNS Push Service - used for friends request in android app

I have a question concerning the design of my app. I have different users, which I want to socially bound as friends. This requires a proper notification for the other user as well as accepting the request.
My question is how to do it with AWS? I have users stored in Cognito Identity Pool. Should I use push notifications informing the user about friend request? If so, how to send a push notification from one android device to the other?
If not, how else should I design it? And if I want to implement notifications inside the App is Push service still valid (encoding by Lambda, something like this?) or should I use something different?
Kind regards,
Grzegorz

In general you don’t want your app to have permissions to send push notifications directly to other devices. Assuming you have each users device tokens, using a Lambda function as you mentioned to send an SNS push notification to the potential friend's device which could then trigger a flow which could allow them to accept and link as friends (depending on how your friend flow works).
You can find some helpful SNS documentation at http://docs.aws.amazon.com/sns/latest/dg/SNSMobilePush.html. Mobile Hub can help you get started quickly, and will create an app that can receive push notifications, and trig (https://console.aws.amazon.com/mobilehub). You can also use Mobile Hub to add Lambda to your mobile app.

In-App messaging vs Push Messages: Pros and Cons

I am finding difficulty to know about in-App messaging.
And how to do it.
I have the following things in my mind,
in-App messaging:
Is an idea to receive contents from a server only the app is alive on screen.
This is possible only the app is active.
App should make a call to server and needs to receive contents.
Push messages
Is an idea to receive contents from a server even though the app is not active.
This is possible at any time, we can notify users while our app is closed and running also.
App do not need to make a call.
But the app should have code implemented to receive push notifications.
We can use GCM for Android and Push Notification for iOS.
Am i right with my understandings ?
If i am not and i missed something , please give your hand to take me out of this confusion.
Thanks,

When I think of in-app messaging, to me it means that you're sending a message from one part of your app to another. "Sending a message" is a very generic term that can be accomplished in a number of different ways. Among others:
Sending a broadcast to a message receiver. You'll need to call sendBroadcast to a BroadcastReceiver.
You can pass a Handler to another component and it can post messages to your handler where they're processed
You can use a third party library such as the open source "otto" library
You can build your own version using the observer pattern.
For push messages, your understanding seems about right. However, look at this post for details on the last item, "We can use GCM for Android and Push Notification for iOS".

You are right, though I would change the term in-App Messaging to Pull Messages, since you are referring to the app pulling messages from the server, while in-App Messaging implies that the application is sending the messages.
You points are mostly correct, though Pull Messages does not require the app to be in the foreground (on screen) - a part of your app can run in the background and fetch messages from the server. This is more doable on Android, since iOS limits the operation an app can do in the background.
Another point that should be added to your list is that Push messages also have the advantage of conserving battery life.

In-App Messaging can also be viewed from another standpoint. AT&T has an API for In-App messaging that allows you to send SMS cross carrier. The API can be found here. along with others. From this you can imagine the ability to message from within an app, say a game or a social app and retrieve responses. There are examples for all the platforms you have added as tags. It might be good for you to look this over as it can expand your understanding of the concept in a different direction than the other answers, Somewhere in all of these you will find what you are looking for.