[android研究联系人之四]联系人StructuredPostal/StructuredName数据操作

简介:


技术:Android联系人技术分析


知识点:分析联系人中StructuredPostal和StructuredName数据


重点:数据类型


首先分析第一个字段:StructuredPostal

它代表联系人的地址信息,如图表示字段:



先看看它有的类型吧:



有四种数据类型。


看源码中定义的四种类型:

            public static final int TYPE_HOME = 1;
            public static final int TYPE_WORK = 2;
            public static final int TYPE_OTHER = 3;

还有种定义类型:type=0时,是自定义类型。它没有单独在字段中定义。


按下来分析,StructuredPostal中重要的字段:

先从源码中看起:

 /**
             * The full, unstructured postal address. <i>This field must be
             * consistent with any structured data.</i>
             * <p>
             * Type: TEXT
             */
            public static final String FORMATTED_ADDRESS = DATA;

            /**
             * Can be street, avenue, road, etc. This element also includes the
             * house number and room/apartment/flat/floor number.
             * <p>
             * Type: TEXT
             */
            public static final String STREET = DATA4;

            /**
             * Covers actual P.O. boxes, drawers, locked bags, etc. This is
             * usually but not always mutually exclusive with street.
             * <p>
             * Type: TEXT
             */
            public static final String POBOX = DATA5;

            /**
             * This is used to disambiguate a street address when a city
             * contains more than one street with the same name, or to specify a
             * small place whose mail is routed through a larger postal town. In
             * China it could be a county or a minor city.
             * <p>
             * Type: TEXT
             */
            public static final String NEIGHBORHOOD = DATA6;

            /**
             * Can be city, village, town, borough, etc. This is the postal town
             * and not necessarily the place of residence or place of business.
             * <p>
             * Type: TEXT
             */
            public static final String CITY = DATA7;

            /**
             * A state, province, county (in Ireland), Land (in Germany),
             * departement (in France), etc.
             * <p>
             * Type: TEXT
             */
            public static final String REGION = DATA8;

            /**
             * Postal code. Usually country-wide, but sometimes specific to the
             * city (e.g. "2" in "Dublin 2, Ireland" addresses).
             * <p>
             * Type: TEXT
             */
            public static final String POSTCODE = DATA9;

            /**
             * The name or code of the country.
             * <p>
             * Type: TEXT
             */
            public static final String COUNTRY = DATA10;


类型:StructuredPostal.CONTENT_ITEM_TYPE

StructuredPostal.FORMATTED_ADDRESS:对应Data.data1

StructuredPostal.TYPE:对应Data.data2:表示类型

StructuredPostal.LABEL:对应Data.data3:表示自定义类型名称

StructuredPostal.STREET:对应Data.data4:表示街道

StructuredPostal.POBOX:对应Data.data5:表示邮箱

StructuredPostal.NEIGHBORHOOD:对应Data.data6:表示镇(看英文解释)

StructuredPostal.CITY:对应Data.data7:表示城市

StructuredPostal.REGION:对应Data.data8:表示区域(省级)

StructuredPostal.POSTCODE:对应Data.data9:表示邮编

StructuredPostal.COUNTRY:对应Data.data10:表示国家


最后会分析存入数据库的值。


下面分析:StructuredName

StructuredName中主要保存的是联系人 姓名,其 称呼名和其 拼音名
姓名的表示有以下两种方式:
第一种:DISPLAY_NAME
第二种:GIVEN_NAME+FAMILY_NAME
注:第一种和第二种应该是 互斥的。有些手机支持第一种,有些则支持第二种。但必须支持其中的一种。
称呼名 ,是指对人的称呼。比如 Mr Hu。它只有一个表示形式:PREFIX+MIDDLE_NAME+SUFFIX
注:很多手机都不支持该项。
拼音名是指汉语拼音的形式,或片假名的形式,或平假名的形式等。
它只有一个表示形式:PHONETIC_GIVEN_NAME+PHONETIC_MIDDLE_NAME+PHONETIC_FAMILY_NAME
注:很多手机都不支持该项。

接下来看看模拟器中提供的姓名有多少吧:
先看图:


国外人的姓名字段可真多啊,所以,要操作手机中的姓名,还是要非常的小心。不同的手机可能会有不一样的。

接着看显示的名字,在模拟器中是什么?

用户名的显示,就是上面提到的多个字段组合起来的。

Android手机具体会使用哪种方式表示姓名,可能会一样。但我们还是要看看系统源码中提供了哪些重要的字段:

 /**
             * The name that should be used to display the contact.
             * <i>Unstructured component of the name should be consistent with
             * its structured representation.</i>
             * <p>
             * Type: TEXT
             */
            public static final String DISPLAY_NAME = DATA1;

            /**
             * The given name for the contact.
             * <P>Type: TEXT</P>
             */
            public static final String GIVEN_NAME = DATA2;

            /**
             * The family name for the contact.
             * <P>Type: TEXT</P>
             */
            public static final String FAMILY_NAME = DATA3;

            /**
             * The contact's honorific prefix, e.g. "Sir"
             * <P>Type: TEXT</P>
             */
            public static final String PREFIX = DATA4;

            /**
             * The contact's middle name
             * <P>Type: TEXT</P>
             */
            public static final String MIDDLE_NAME = DATA5;

            /**
             * The contact's honorific suffix, e.g. "Jr"
             */
            public static final String SUFFIX = DATA6;

            /**
             * The phonetic version of the given name for the contact.
             * <P>Type: TEXT</P>
             */
            public static final String PHONETIC_GIVEN_NAME = DATA7;

            /**
             * The phonetic version of the additional name for the contact.
             * <P>Type: TEXT</P>
             */
            public static final String PHONETIC_MIDDLE_NAME = DATA8;

            /**
             * The phonetic version of the family name for the contact.
             * <P>Type: TEXT</P>
             */
            public static final String PHONETIC_FAMILY_NAME = DATA9;

            /**
             * The style used for combining given/middle/family name into a full name.
             * See {@link ContactsContract.FullNameStyle}.
             *
             * @hide
             */
            public static final String FULL_NAME_STYLE = DATA10;

            /**
             * The alphabet used for capturing the phonetic name.
             * See ContactsContract.PhoneticNameStyle.
             * @hide
             */
            public static final String PHONETIC_NAME_STYLE = DATA11;


没想到它会有这么多字段吧。


接下来分析这些字段:

类型:StructuredName.CONTENT_ITEM_TYPE

StructuredName.DISPLAY_NAME:对应Data.data1:表示显示的名字
StructuredName.GIVEN_NAME:对应Data.data2:表示名
StructuredName.FAMILY_NAME:对应Data.data3:表示family名(在国外表示父母的姓)
StructuredName.PREFIX:对应Data.data4:表示姓名前的称呼,如Sir(先生/女士)
StructuredName.MIDDLE_NAME :对应Data.data5:表示姓名中间的字
StructuredName.SUFFIX :对应Data.data6:表示姓名敬语的后缀(不知道是什么)
后面的几个字段,都是语音相关设置的。


今天又折腾了挺晚了,晚上参加一个会议,和朋友喝了点酒,头晕晕的。但还是要坚持,把自己整理的东西,分享给大家。一起学习进步吧!!


后面还有一个数据库存入分析,快点来看看吧:
先看地址存入数据库的字段:




接下来看姓名字段数据:




如果对联系人操作,有问题的,可以结合源码和操作数据库的内容分析,就一定能很快的解决问题。
问题的难,就是思考时间太少。只能多用心,花时间研究。总能解决问题。
做技术,不能太及,需要一步步稳。用事实说话。


好了,今天就介绍到这里,如果对文章中有问题的地方,欢迎 一起交流。。只有交流,才能更好的进步。


加油吧,朋友们!!!



目录
相关文章
|
2月前
|
开发框架 前端开发 Android开发
Flutter 与原生模块(Android 和 iOS)之间的通信机制,包括方法调用、事件传递等,分析了通信的必要性、主要方式、数据传递、性能优化及错误处理,并通过实际案例展示了其应用效果,展望了未来的发展趋势
本文深入探讨了 Flutter 与原生模块(Android 和 iOS)之间的通信机制,包括方法调用、事件传递等,分析了通信的必要性、主要方式、数据传递、性能优化及错误处理,并通过实际案例展示了其应用效果,展望了未来的发展趋势。这对于实现高效的跨平台移动应用开发具有重要指导意义。
208 4
|
5月前
|
开发工具 Android开发 开发者
Android平台如何不推RTMP|不发布RTSP流|不实时录像|不回传GB28181数据时实时快照?
本文介绍了一种在Android平台上实现实时截图快照的方法,尤其适用于无需依赖系统接口的情况,如在RTMP推送、RTSP服务或GB28181设备接入等场景下进行截图。通过底层模块(libSmartPublisher.so)实现了截图功能,封装了`SnapShotImpl.java`类来管理截图流程。此外,提供了关键代码片段展示初始化SDK实例、执行截图、以及在Activity销毁时释放资源的过程。此方案还考虑到了快照数据的灵活处理需求,符合GB/T28181-2022的技术规范。对于寻求更灵活快照机制的开发者来说,这是一个值得参考的设计思路。
|
3月前
|
存储 大数据 数据库
Android经典面试题之Intent传递数据大小为什么限制是1M?
在 Android 中,使用 Intent 传递数据时存在约 1MB 的大小限制,这是由于 Binder 机制的事务缓冲区限制、Intent 的设计初衷以及内存消耗和性能问题所致。推荐使用文件存储、SharedPreferences、数据库存储或 ContentProvider 等方式传递大数据。
108 0
|
5月前
|
JSON Java Android开发
Android 开发者必备秘籍:轻松攻克 JSON 格式数据解析难题,让你的应用更出色!
【8月更文挑战第18天】在Android开发中,解析JSON数据至关重要。JSON以其简洁和易读成为首选的数据交换格式。开发者可通过多种途径解析JSON,如使用内置的`JSONObject`和`JSONArray`类直接操作数据,或借助Google提供的Gson库将JSON自动映射为Java对象。无论哪种方法,正确解析JSON都是实现高效应用的关键,能帮助开发者处理网络请求返回的数据,并将其展示给用户,从而提升应用的功能性和用户体验。
120 1
|
5月前
|
缓存 API Android开发
Android经典实战之Kotlin Flow中的3个数据相关的操作符:debounce、buffer和conflate
本文介绍了Kotlin中`Flow`的`debounce`、`buffer`及`conflate`三个操作符。`debounce`过滤快速连续数据,仅保留指定时间内的最后一个;`buffer`引入缓存减轻背压;`conflate`仅保留最新数据。通过示例展示了如何在搜索输入和数据流处理中应用这些操作符以提高程序效率和用户体验。
61 6
|
5月前
|
编解码 网络协议 前端开发
如何实现Android平台GB28181设备接入模块按需打开摄像头并回传数据
后台采集摄像头,如果想再进一步扩展,可以把android平台gb28181的camera2 demo,都移植过来,实现功能更强大的国标设备侧,这里主要是展示,收到国标平台侧的回传请求后,才打开摄像头,才开始编码打包,最大限度的减少资源的占用
|
5月前
|
编解码 网络协议 Android开发
Android平台GB28181设备接入模块实现后台service按需回传摄像头数据到国标平台侧
我们在做Android平台GB28181设备对接模块的时候,遇到这样的技术需求,开发者希望能以后台服务的形式运行程序,国标平台侧没有视频回传请求的时候,仅保持信令链接,有发起视频回传请求或语音广播时,打开摄像头,并实时回传音视频数据或接收处理国标平台侧发过来的语音广播数据。
|
5月前
|
算法 数据处理 开发工具
Android平台RTSP|RTMP播放器如何回调YUV或RGB数据
在开发Android平台上的RTSP或RTMP播放器时,开发者不仅追求低延迟播放,还希望获取解码后的视频数据(如YUV或RGB格式),以便进行视觉算法分析。使用大牛直播SDK中的SmartPlayer,可在确保播放流畅的同时,通过设置外部渲染器(`SmartPlayerSetExternalRender`)来高效地回调原始视频数据。例如,对于RGBA数据,需实现`NTExternalRender`接口,并重写相关方法以处理数据和尺寸变化。同样地,对于I420(YUV)数据,也需要相应地实现接口以满足需求。这种方式使得开发者能在不影响常规播放功能的情况下,进行定制化的视频处理任务。
|
5月前
|
存储 缓存 Java
Android项目架构设计问题之优化业务接口数据的加载效率如何解决
Android项目架构设计问题之优化业务接口数据的加载效率如何解决
57 0
|
7月前
|
JSON 编解码 Apache
Android中使用HttpURLConnection实现GET POST JSON数据与下载图片
Android中使用HttpURLConnection实现GET POST JSON数据与下载图片
76 1