Category Archives: 开发

Android 物联网SDK

原文链接

支持库

主要包含两方面的支持:外部器件 IO API用户驱动API

  • 外部器件 IO API实现了相关的工业标准协议和接口,可以让App与传感器和制动元件进行通信。支持的接口主要有:GPIOPWMI2CSPIUART

https://developer.android.com/things/sdk/pio/index.html

  • 用户驱动API扩展自Android framework的Service组件,它允许App注入硬件事件到framework层,其他的Apps就可以通过标准的Android API来访问这些事件信息。

https://developer.android.com/things/sdk/drivers/index.html

与AndroidOS相比的变更

  • 应用变化

Android Things中系统应用将不复存在,Content Provider也消失了,所以在开发应用时就不要通过Intent调用如下API了:

CalendarContract
ContactsContract
DocumentsContract
DownloadManager
MediaStore
Settings
Telephony
UserDictionary
VoicemailContract

  • 显示不再是必须

Android Things的应用与传统的应用开发一样,提供了相同的UI工具集来支持显示,在图形模式下窗口会以*真实*全屏的方式显示,没有状态栏和导航栏,即便你从底部滑动也不会出现,整个屏幕完全交由用户操控。

当然了,Android Things的显示屏并不是必须的。在一个无屏的设备上App的activities还是主组件,framework依然会分发输入事件到获得焦点的前台activity上。应用不能通过其他应用的组件(比如service)来接收键盘事件或者移动事件。

  • 主Activity支持

Android Things自动运行一个App在manifest中定义的”home activity”作为系统启动后入口,这个activity必须包含一个由CATEGORY_DEFAULT和IOT_LAUNCHER组成的intent-filter。

为了方便开发,这个activity还需要包含一个CATEGORY_LAUNCHER的intent-filter,这样Android Studio才能在发布和调试时作为默认activity来启动。

  • Google Services支持的变化

Android Things支持一系列的Google APIs。在这里需要用户输入和授权的API都不支持。下表列出了支持的API和不支持的API:

支持的APIs 不支持的APIs
Cast
Drive
Firebase Analytics
Firebase Cloud Messaging (FCM)
Firebase Crash Reporting
Firebase Realtime Database
Firebase Remote Config
Firebase Storage
Fit
Instance ID
Location
Nearby
Places
Mobile Vision
AdMob
Android Pay
Firebase App Indexing
Firebase Authentication
Firebase Dynamic Links
Firebase Invites
Firebase Notifications
Maps
Play Games
Search
Sign-In
  • 权限

运行时授权在这里不能够提供支持,因为没有UI来提供授权对话框的显示,所以App开发者需要在manifest中将所有权限列出。所有正常和高危权限均会在安装时统一授予。

  • 通知

由于没有系统级别的状态栏和UI窗口支持,所以通知服务不会支持,在App中要避免调用NotificationManager。

Java WEB系统微服务化迁移

  1. Docker
  2. 微服务
  3. Spring-Boot

支撑互联网公司运行的庞大后端服务系统经历了原始的BS架构设计、前后端分离、模块化组件、系统分层设计的进化,从计算资源的虚拟化到今天容器技术的应用,互联网一直在朝着资源高效配置、分布式集群服务的方向进发。

Docker作为当下最流行的容器化技术,相比于运行在实体物理机上的虚拟机技术,它具有轻量级资源隔离、快速部署、持续交付、版本控制、 可移植、开放技术等特点。

如果采用虚拟机技术去部署一套系统,需要几个步骤:

1、分配物理资源(CPU\内存\网络)

2、开机启动运行

3、安装系统运行时支撑环境(模版)

4、发布生产系统

5、上线。

采用Docker需要如下几个步骤:

1、拉取Docker Image

2、发布生产系统

3、上线

相比来看可能就会发现,Docker相当于把最繁琐最耗时的工作帮助我们解决了。Docker运行在(特定)操作系统之上,只需要一条命令即刻启动;通过Docker Image将运行时配置、依赖管理、版本管理集成一个Dockerfile描述文件中标准化,快速解决原始虚拟机技术中的1、2、3步骤。如果再搭配Google出品的Kubernetes容器管理工具更加得心应手。

与Docker并行出现一个架构模式-微服务,它并不是一种全新的架构体系,更确切的说是一种架构的思考。在经历了模块化、组件化、服务化之后,系统的架构设计实现复杂、服务调用关联度高等问题困扰着一个系统的稳定性和开发难度。微服务是在原有的服务治理的基础上,将原有系统服务的粒度进行再切分使得服务之间的耦合性降至最低,同时不依赖于过多的外部运行时环境,对外暴露的输入输出可能只是一个JSON、XML数据集,可以实现大规模的快速部署运行。这些特点与Docker的容器化优势不谋而合,这也是当前微服务实践采用比较多的一种方式。

Spring Boot在微服务概念出现之前已经发布了有一段时间,但并没有大行其道,大家对于Java Web的项目更倾向于原有Servlet Container Server的部署模式。随着微服务的出现,Spring Boot再次引起了大家的注意,同时Spring在被收购后也在朝着云服务商的方向上进发,推出了自己的云服务平台。

相比一切全新的服务系统,遗留的Java WEB系统如何进行更好的迁移使用微服务,是需要考虑的一大问题。当前的项目中框架采用了Freemarker+Spring+Hibernate的方式,Spring的配置是原有的XML配置方式,与Spring-Boot推荐的注解配置相比,迁移难度较大。

Spring-Boot使用注解配置剥离了XML的配置方式,使用内嵌式Servlet Container(Jetty\Tomcat\Undertow)来实现服务的HTTP通信、监控、交互。与此相对照,能否维持XML配置不变,仅使用内嵌Servlet Container来提供服务呢?答案是:可以。

采用Tomcat Embed作为默认的Servlet Container,通过Tomcat Bootstrap中Host、Port配置来实现HTTP服务,指定WEB路径的方式来提供Spring XML配置部分和其他WEB资源,这样就基本实现了原有Java WEB系统的服务化迁移。

在迁移测试过程中,也遇到了几个坑。

1、Gradle编译工具对JAR包的支持度不够完善,需要额外的插件来实现Eclipse FatJar的功能。

2、如果自定义Jar合并时,一定要注意Spring Schema文件的合并。在不使用插件的情况下,会导致spring schema XSD文件的丢失。需要在插件支持下通过tramformer来合并。

如果单独使用Maven来打包之需要通过修改POM文件来实现。

相关资料     Docker Spring-Boot Gradle FatJar Plugin Tomcat Embed

Android TextInputLayout升级后的坑

Google自从推出全平台的Material Design的设计风格以来,各位大神都贡献了很多符合这一风格的custom组件,直到Android官方的design支持库推出,大家对Material的追捧简直是蜂拥而上。

之前有用过其他自定义的EditText,但是design的TextInputEditText更好的支持了Error、Hint和Material风格,遂用上。

代码如下:

 

TextInputLayout在使用时默认visibility=gone,运行时根据逻辑置为visible或者gone,当在Java代码中操作时是通过id=code的TextInputEditText来操作(getParent())父组件TextInputLayout的。

在design support version=25.0.0之前,一切都正常,setVisibility都能正常操纵父组件,但升级之后一切失效了,WHAT!?WHY!?。

通过DEBUG才发现,TextInputLayput做出了更改,添加对密码显示隐藏的支持,在Java代码中又增加了一层FrameLayout导致通过getParent()获取到的并不是TextInputLayput组件。

最新TextInputLayout的源代码更改,移步

问题还是归因于正确(非怪异???)的使用组件~