Route
Contact us
2026-02-18 02:50:35
初涉仿微信导航的生手,最怕的就是在消息提醒这个环节出错。不少人做出来的小红点,要么始终亮着不熄灭,要么该亮起来时却不亮 ,用户体验糟糕透顶。实际上 ,解决这个问题并非如想象那般复杂 ,通过本地广播进行处理 ,便是一条极为可靠的便捷途径。
不少人一下就想去用全局广播,或者要用到 EventBus ,然而,在这样的场景当中,实际上是略微有点大题小做了。本地广播仅仅只是会在你自身身处的应用内部进行传播的,它是不会会被别的应用给阻挡拦截,也不会被窃取偷听的,安全性是更高一些的。我在去年做的一个企业 IM 项目,就是由于使用了全局广播,結果里头的消息提醒时不时就会延迟好几秒的。
本地广播所能带来的另外一个好处在于,其生命周期是能够得到有效地控制的。你无需去操心其他应用层面所产生的干扰,仅仅专注于自身应用内部所具备的逻辑就可以了。在FragmentActivity或者Fragment当中进行注册,以此来与整个生命周期相互配合并且使用,会显得极为顺手。它所具备的效率相比于全局广播而言也要高出许多,毕竟它并不需要进行跨进程通信。
android:id="@+id/message"
android:layout_width="0dp"
android:layout_height="match_parent"
android:layout_weight="1" >
android:layout_width="wrap_content"
android:layout_height="match_parent"
android:layout_gravity="center_horizontal"
android:gravity="center"
android:orientation="vertical" >
android:id="@+id/message_imgv"
android:layout_width="@dimen/dp_30"
android:layout_height="@dimen/dp_30"
android:layout_marginTop="2dp"
android:src="@drawable/selector_message" >
android:id="@+id/messagetext"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_gravity="center_vertical"
android:layout_weight="1"
android:button="@null"
android:gravity="center"
android:textColor="@drawable/radio_text"
android:text="信息">
android:id="@+id/hint"
android:layout_width="@dimen/dp_14"
android:layout_height="@dimen/dp_14"
android:layout_gravity="top|center"
android:layout_marginLeft="10dp"
android:layout_marginTop="2dp"
android:background="@drawable/tab_msgnum_textbg"
android:textSize="8sp"
android:gravity="center"
android:textColor="#FFFFFF"
android:visibility="visible"/>
你所提及的那三个布局,属于标准的底部导航结构样子。正常情形下,一般会运用Fragment去达成这三个页面的呈现,每一个页面依靠自身单独施行状态的管理。消息页面常常会被放置在中间位置或者最右边地方,这得依据具体的需求状况来定。借助ViewPager并搭配FragmentPagerAdapter,这是较为常见的一种操作办法。
对于导航而言,其选中状态的切换同样是相当重要的。能够采用Selector文件去规定处于不同状态之际的图标以及文字的颜色,如此一来,相应的切换过程就会显得极为顺畅平滑。要是期望让用户所体会到的点击感觉愈发良好,那么适量添加些许比较微小的动画效果是可行的,比如说图标的略微进行缩放。然而需要牢记,所添加的动画不要呈现出过于繁杂花哨的模样,不然的话就会致使其他内容沦为重点的陪衬,显得主次颠倒了。
新消息抵达之际,先是要于服务端也好、本地数据库也好做好记录。你的思路不失为正确,此时应发一则本地广播。广播当中能够携有特定简单数据,诸如未读消息具数、最新消息之内容预览之类。接收到广播之后,主页面实施相应的UI更新。
这里存在一个需要留意的细节,若当下已然处于消息页面,那是否还应当展示小红点呢?依据微信的交互设定,在转入消息页面过后小红点理应消失。故而在咱们这边的广播接收逻辑当中,需要去判别当前所呈现的Fragment是哪一个,要是属于消息页面的话,便不展现红点,并且与此同时将未读计数予以清空。
@Override public void updaUI(Listresult) { if (this.list != null)list.clear(); this.list = result; int i = 0; if (list != null && list.size()>0){ for (MessageResult mag:list) { //判断是否收到新的消息 if (mag.getRead().equals("0")){ i++; } } } if (i > 0){ LocalBroadcastManager.getInstance(getContext()).sendBroadcast(new Intent(Constants.ACTION_IMAGE_MESSAGE).putExtra("id",1).putExtra("num",i)); }else { LocalBroadcastManager.getInstance(getContext()).sendBroadcast(new Intent(Constants.ACTION_IMAGE_MESSAGE).putExtra("id",2)); } adapter = new MessageAdapter(getContext(),this.list); listView.setAdapter(adapter); listView.setOnItemClickListener(this); listView.setOnItemLongClickListener(this); }
说到代码方面,能够先于底部导航的item上安置一个自定义View,像是借由ConstraintLayout去包覆ImageView以及TextView。小红点能够是一个独自的View,默认状况下被设定成gone。在接收到广播之后,将这个View设为visible,并且设置出一个圆形的背景形状。
相同较为关键的是潜藏着的逻辑,当使用者依据指令进入到消息页面,或者对全新消息予以查看时,此时另一要求得以明确,即你必须运用发送另一广播这一行为去提示主页面将小红点予以隐藏,在该情形之下,数据库里相关未读状态能够实施更新操作,与此同时,需把小红点再度设定为消失不见的状态,要牢记在特定的onDestroy里取消广播注册这一操作,以此防止出现内存泄漏的状况。
IntentFilter intentFilter = new IntentFilter(Constants.ACTION_ENTER_HOME); LocalBroadcastManager.getInstance(this).registerReceiver(message_br, intentFilter);
登记注册广播必然应跟取消此注册一并出现啊,于activity的onCreate或者onStart之中去操持注册事宜。于onPause抑或onDestroy里实施取消行为呀 ,是要具体依据你的需要状况来定夺的,要是期望在页面呈现未曾可见的阶段依旧能够接收到广播资讯呢 那么就在onDestroy环节实施取消。但若不需要保持这种状态 那么在onPause阶段当中进行取消操作会更契合需求哟。
另外存在一个坑,那便是通过匿名内部类来注册广播,这般情形极易致使内存出现泄漏。建议将广播接收器定义为一个内部类的成员变量,或者在Activity被销毁之际务必要保证不存在未处理的消息。采用弱引用亦是可行的,不过相对较为复杂,新手能够先掌握基础的用法。
private BroadcastReceiver message_br = new BroadcastReceiver() { @Override public void onReceive(Context context, Intent intent) { int i = intent.getIntExtra("id",0); if (i == 1){ hint_tv.setText(intent.getStringExtra("num")); hint_tv.setVisibility(View.VISIBLE); }else if (i == 2){ hint_tv.setVisibility(View.INVISIBLE); } } };
最初我着手制作手机社区应用程序那会儿吖,仅仅只这个广播注册先后顺序的事儿,就让我白白耗费了整整两天时间。你想想,要是在注册接收消息的部件之前把广播发出去,那么,这则讯息可就直接消失得无影无踪。故而,必须得百分百保证在广播被发送出去之前,接收通知的部件已然成功完成注册进程。可以选择在应用程序初始化的创建阶段先对此进行登记,或者坚决落实到使得加载主页面完成过后才准予发出提示音。
另外存在一个坑,即多个页面会同时去接收同一个广播。举例而言,倘若你打造了消息页面以及会话列表页,在这两边都需要对未读计数予以更新。在这种时刻,就必须留意数据同步的问题,以此来防止出现一边显示为已读,然而另一边却依旧呈现为红点的状况。能够借助一个具备全局性质的未读计数管理类,所有的更新操作都经由这个类来进行分发。
请问最后,想问问你,实际当中在开发里,你是怎样去处理于用户清除全部消息当下小红点状态的?是直接进行隐藏吗?还是存在一个渐变消失这种动画效果?欢迎来到评论的区域分享你的做法,要是觉得文章具有实用性而言的话点个赞去支持一下。
@Override protected void onDestroy() { super.onDestroy(); ButterKnife.unbind(this); LocalBroadcastManager.getInstance(this).unregisterReceiver(message_br); }
搜索您想要找的内容!
地址:广东省广州市 电话:020-66889888 手机:13988889999
Copyright © 2012-2023 开云麻将胡了模拟器 版权所有 ICP备案编号:粤ICP备88889999号