Android旅行者

Printer 标准ES-POS命令打印，固定IP或蓝牙打印，支持黑白图片打印 预览 screenshot printer_example 要求 minSdkVersion 5 <uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.BLUETOOTH" /> 引用 dependencies { ⋯ compile ' am.util:printer:1.1.3 ' ⋯ } 详情 继承PrintTask来实现打印任务 继承PrinterWriter来实现更多纸张类型的打印 PrinterUtils包含了众多打印指令 使用 1.添加蓝牙权限 <uses-permission android:name="android.permission.BLUETOOTH" /> 或者网络请求权限 <uses-permission android:name="android.permission.INTERNET" /> 2.继承PrintTask类，实现具体打印任务： private class TestPrintTask extends PrintTask { public TestPrintTask ( BluetoothDevice device , int type ) { super (device, type); } public TestPrintTask ( String ip , int port , int type ) { super (ip, port, type); } @Override protected void onPreExecute () { super . onPreExecute();

多个开源项目Bintray一键发布环境部署 　　我们发布到Bintray上共享的一般是一些库，而不是完整的App，而这些库是依附在我的主项目之中，如果我们主项目只维护一个共享库，那没什么问题，但维护多个开源库呢？不规划一下打包发布的流程，那么就会浪费我更很多的时间在打包发布上。截至至撰文时，笔者的ProjectX主项目已经管理维护者16个开源库，不规划一套打包方案，那么妥妥的能把笔者累死。 基础Plugin载入 　　需要实现自动化发包，就必须载入 gradle-bintray-plugin 与 android-maven-gradle-plugin （点击链接查看最新版本号，使用最新版本插件）。载入方式有两种： 传统方式 dependencies { classpath ' com.jfrog.bintray.gradle:gradle-bintray-plugin:1.7.1 ' classpath ' com.github.dcendents:android-maven-gradle-plugin:1.5 ' } 新型方式(Gradle 2.1) plugins { id " com.jfrog.bintray " version " 1.7.1 " id " com.github.dcendents.android-maven " version " 1.5 " } 　　使用新型方式导入的gradle-bintray-plugin会提交不成功，不知AS更新以后是否解决，但是笔者出错的版本是1.7.1，新版本没出来前gradle-bintray-plugin还是建议使用传统方式，android-maven-gradle-plugin可以选择新型方式。 部署方案 在库根目录（不是项目根目录）创建bintray.gradle文件，文件内容（可以直接拷贝给其他项目使用）： apply plugin : ' com.github.dcendents.android-maven ' apply plugin : ' com.jfr

URLConnection从HTTP重定向到HTTPS 　　也不知什么原因，公司项目的服务端一直在吸引着大波攻击，于是服务端的同学打算把所有HTTP的请求都换为HTTPS，他们决定兼容旧版本于是就将之前的所有HTTP请求全部重定向到另一个HTTPS请求。 项目请求框架搭建初期，考虑到应用也不会使用太复杂的请求模式，于是就简单使用URLConnection完成服务端交互。服务端一修改，全部请求都失败了。虽然URLConnection有是否遵循重定向开关（setInstanceFollowRedirects），其默认就是开启的，即便你再强制其打开，也是没有用，问题依旧。找了大量资料，其实问题的关键点不是重定向而是从HTTP重定向到HTTPS，关键点就在URLConnection的两个子类上。 HttpURLConnection与HttpsURLConnection 　　HttpURLConnection为URLConnection的子类，而HttpsURLConnection为HttpURLConnection的子类，在HttpURLConnection基础上对HTTPS进行支持。 URLConnection通常使用URL的openConnection()方法获得，而URL是根据其是否为Https开头来打开一个HttpURLConnection还是HttpsURLConnection。 而当URLConnection进行connect()时，遇到了重定向，如果打开了遵循重定向，那么其会获取重定向的地址，然后尝试连接这个地址。值得注意的是，这时候并不是使用新的链接地址重新openConnection()一个URLConnection，而是直接尝试连接这个重定向的地址，否则也就不存在以上的Bug了。 于是理论上分析，HTTP重定向到HTTP是不存在问题的，HTTPS重定向到HTTPS也是不存在问题的，而HTTP与HTTPS之间的重定向，那么就很可能会有问题了。HTTP重定向到HTTPS，URLConnection会将重定向的HTTPS以HTTP方式继续提交，那么服务端肯定是认为你是错误的提交方式；同理，HTTPS重定向HTTP也一样。 问题解决 使用URLConnection抓取到重定向，就使用重定向的地址重新人为openConnection()一个新

Android版本兼容器 随着Android版本一代代发布，碎片化的问题越来越严重，不过好在趋势上市面上的版本已经开始比较集中了。但我们终究还是要面对版本兼容问题。我们不能因为要用高版本方法而提高最低版本限制，高版本里炫酷的效果及高效的方法只会导致你的最低版本显示越来越高，而官方的解决方案（Support-v4）无疑是给了我们新的启示。 示例 首先我们抽取一个官方的版本兼容器的一部分看看： /** * Helper for accessing features in {@link TextView} introduced after API level * 4 in a backwards compatible fashion. */ public final class TextViewCompat { // Hide constructor private TextViewCompat () {} interface TextViewCompatImpl { ... int getMaxLines ( TextView textView ); int getMinLines ( TextView textView ); void setTextAppearance ( @NonNull TextView textView , @StyleRes int resId ); Drawable [] getCompoundDrawablesRelative ( @NonNull TextView textView ); } static class BaseTextViewCompatImpl implements TextViewCompatImpl { ... @Override public int getMaxLines ( TextView textView ) { return TextViewCompatGingerbread . getMaxLines(textVi