In the previous development, I did not integrate the communication SDK, so I will try it this time. I chose Huanxin IM. He provides two types: fast EaseUi integration and the other is to integrate according to documentation and API. Personally, EaseUi is already pretty good. We add a little, delete or replace it, which can basically satisfy most of them. demand. As a developer, I wanted to learn more and slowly integrated.
It is difficult for me to write down every detail and problem of my lock integration, but the ideas can be rationalized
1. Dependencies and things needed for integration
2. Log in to register, test the Demo by yourself, register and log in by your own code
3. Get contacts and add, delete, modify, check, and blacken contacts. The core of this piece of processing is monitoring and timely refresh. The following is the personal code directly pasted:
/**
* Add and delete your own contacts
* I was invited
* Your request is approved and rejected by others
*/
class MyContactListener implements EMContactListener {
@Override
public void onContactAdded(String s) {
Log.e("TAG", "New friends:" + s);
if (!ContactListManager.getInstance().containContact(s)) {
ContactListManager.getInstance().saveContact(s);
}
localBroadcastManager.sendBroadcast(new Intent(Constact.ACTION_CONTACT_CHANAGED));
}
@Override
public void onContactDeleted(String s) {
Log.e("TAG", "Deleted friends:" + s);
if (ContactListManager.getInstance().containContact(s)) {
ContactListManager.getInstance().deleteContact(s);
}
localBroadcastManager.sendBroadcast(new Intent(Constact.ACTION_CONTACT_CHANAGED));
}
@Override
public void onContactInvited(String userName, String s1) {
Log.e("TAG", "Friend invitation received:" + userName);
//Delete messages sent before userName in batches and replace them with the latest ones
GreenDaoHelp.getInstance().getSession().getInviteMessageEnityDao().queryBuilder()
.where(InviteMessageEnityDao.Properties.From.eq(userName))
.buildDelete().executeDeleteWithoutDetachingEntities();
// save invitation as message
InviteMessageEnity msg = new InviteMessageEnity();
msg.setFrom(userName);
msg.setTime(System.currentTimeMillis());
msg.setReason(s1);
// set invitation status
msg.setStatus(InviteMessageStatus.BEINVITEED);
notifyNewInviteMessage(msg);
localBroadcastManager.sendBroadcast(new Intent(Constact.ACTION_CONTACT_CHANAGED));
}
@Override
public void onFriendRequestAccepted(String userName) {
Log.e("TAG", userName + "Accept my request:");
GreenDaoHelp.getInstance().getSession().getInviteMessageEnityDao().queryBuilder()
.where(InviteMessageEnityDao.Properties.From.eq(userName)).buildDelete().executeDeleteWithoutDetachingEntities();
InviteMessageEnity msg = new InviteMessageEnity();
msg.setFrom(userName);
msg.setTime(System.currentTimeMillis());
// set invitation status
msg.setStatus(InviteMessageStatus.BEAGREED);
notifyNewInviteMessage(msg);
localBroadcastManager.sendBroadcast(new Intent(Constact.ACTION_CONTACT_CHANAGED));
}
@Override
public void onFriendRequestDeclined(String userName) {
MyToast.showToast(userName + "Rejected your friend request");
}
}
My personal understanding is to add, delete, modify, check, etc., all operations will eventually be monitored in this hub, so as long as I perform unified processing in this place, there will be no performance consumption caused by non-refresh caused by missing processing or repeated refresh. .
4. Message sending and receiving also has a core monitor. I also use this monitor as the center to refresh the message. I refresh the View in the message Adapter (send, receive, read, fail... ):
EMMessageListener msgListener = new EMMessageListener() {
@Override
public void onMessageReceived(List<EMMessage> messages) {
//Received the news
List<String> justRemoveList = getJustRemoveList();
for (int i = 0; i < messages.size(); i++) {
EMMessage emMessage = messages.get(i);
String from = emMessage.getFrom();
if (justRemoveList.size() > 0 && getJustRemoveList().contains(from)) {
GreenDaoHelp.getInstance().getSession().getRemoveConverSationEnityDao().deleteByKey(from);
}
}
localBroadcastManager.sendBroadcast(new Intent(Constact.ACTION_MESSAGE_CHANAGED));
Log.e("TAG", "Message received");
}
@Override
public void onCmdMessageReceived(List<EMMessage> messages) {
//Receive a transparent message
Log.e("TAG", "Receive transparent message");
}
@Override
public void onMessageRead(List<EMMessage> messages) {
//Receipt of read receipt
localBroadcastManager.sendBroadcast(new Intent(Constact.ACTION_MESSAGE_CHANAGED));
Log.e("TAG", "Receipt of read receipt");
}
@Override
public void onMessageDelivered(List<EMMessage> message) {
//Receipt of delivery receipt
localBroadcastManager.sendBroadcast(new Intent(Constact.ACTION_MESSAGE_CHANAGED));
Log.e("TAG", "Receipt of delivery receipt");
}
@Override
public void onMessageRecalled(List<EMMessage> messages) {
//The message was withdrawn
Log.e("TAG", "The message was withdrawn");
for (EMMessage msg : messages) {
// if (msg.getChatType() == ChatType.GroupChat && EaseAtMessageHelper.get().isAtMeMsg(msg)) {
// EaseAtMessageHelper.get().removeAtMeGroup(msg.getTo());
// }
EMMessage msgNotification = EMMessage.createReceiveMessage(EMMessage.Type.TXT);
EMTextMessageBody txtBody = new EMTextMessageBody(String.format(getCuurentActivity().getString(R.string.msg_recall_by_user), msg.getFrom()));
msgNotification.addBody(txtBody);
msgNotification.setFrom(msg.getFrom());
msgNotification.setTo (msg.getTo ());
msgNotification.setUnread (false);
msgNotification.setMsgTime(msg.getMsgTime());
msgNotification.setLocalTime(msg.getMsgTime());
msgNotification.setChatType(msg.getChatType());
msgNotification.setAttribute(MESSAGE_TYPE_RECALL, true);
msgNotification.setStatus(EMMessage.Status.SUCCESS);
EMClient.getInstance().chatManager().saveMessage(msgNotification);
}
localBroadcastManager.sendBroadcast(new Intent(Constact.ACTION_MESSAGE_CHANAGED));
}
@Override
public void onMessageChanged(EMMessage message, Object change) {
//Message status changes
Log.e("TAG", "Message Status Change");
localBroadcastManager.sendBroadcast(new Intent(Constact.ACTION_MESSAGE_CHANAGED));
}
};
4. There is no monitoring, you have to send a message. The message mechanism I use is broadcast. Strictly speaking, it is a local broadcast LocalBroadcastreceiver. It is simple, easy to use, and convenient to control registration and anti-registration. In addition, broadcast, as one of the four major components, can cross-process
5. The message sent and received View display is a Recycler. Its core is the Adapter. His core is the View divided into various message types. I divided the View into two left and right views without multiplexing. This is not difficult. The only thing that needs to be done is to display different types of ViewHolder layouts during the entire process of sending messages according to different message states (sending, success, failure, read, unread, etc.), which is troublesome, you can Refer to the Demo to do what needs to be changed, it is no problem to change it
6. Click on the smiley face, Emoji picture, select the picture camera file to open the voice to open the video function, here I refer to the Demo process, but it is slightly different, the essence is the same thing. Just note that in this kind of complex business with more logic and more functions, it is best to be as neat and uniform as a square matrix. For example, switch and case are similar. These different click events are managed uniformly by a large interface, which is easy to read and manage.
Summary: Instant messaging is mainly to find the central monitoring, perform unified management and send it to the relevant interface through broadcast to update the status. In addition, it is to achieve the standardization of the code, especially when the logic is many and complex, but sometimes belongs to a large part. Export clearly one by one through the interface. The last part is the data cache. Of course, it is also to improve performance, and it also focuses on the central monitoring for updates, inserts and other operations.