CategoryAndroid

解决Eclipse 3.7.2升级到4.2带来的开发环境迁移问题

摘要:本人原来的Eclipse版本是3.7.2,主要做Android开发,今天准备装个Maven插件编译Github Android客户端看看的,结果死活装不上,遇上了各种问题,果断下了个Eclipse 4.2,试了下M2E,发现完全没问题了,但就是升级Eclipse需要重装Android Development Tools , AnyEditor , ColorTheme等等一堆插件,还有配置,很是觉得麻烦,果断搜了下,Stackoverflow上还是有更好的方法的,不过仅限于3.7以上,简单说一下。

 

  • 下载安装Eclipse 4.2

下载地址:http://download.eclipse.org/eclipse/downloads/drops4/R-4.2-201206081400/,记得不要覆盖了旧的Eclipse版本

 

  • 从旧版本的Eclipse中导入Plugins

选择 File -> Import –> Install -> From existing Installation

image

指向你的旧版本Eclipse,我这里是指向我的Eclipse 3.7.2(图为我导入以后的样子….)

image

  • 最后

还是要记得把Workspace指向以前的Workspace,就可以无缝切换到新的Eclipse了,Enjoy your coding~~

解决Android开发团队代码版本控制中由编码风格不同造成的代码修订混乱

摘要:不知道大家在版本控制中有没有碰到这种情况,某一个文件新push到代码服务器上的修订很大,几乎是全部的代码出现了修改,看了一遍发现原来是由于协作的人之间编码风格不同,其实真实改动就是改了那么一两行,这就影响了了解真正的代码修订,同时是代码修订历史成了摆设。因为马上有实习生进团队,估计很快又会碰到这种问题,本文就是讲我们团队是如何利用Eclipse的工具解决上面的问题的。

 

  • 统一代码风格 — Android Code Style Guidelines For Contributors

首先,统一的代码风格是一个团队协作开发的好习惯,Android Open Source Project 提供了官方的Strict Android Code Style Guidelines For Contributors,和Android的源码要求一样,非常适合做Code Style规定。

 

  • 统一代码格式 — Eclipse Formatter

1. 在Eclipse的Preferences中,找到Java —> Code Style —> Formatterimage

2. 编辑一个新的Profile,在里面按照团队的代码格式编辑,这里我们编辑了“方法首行空行”等,主要是让代码好看一些,编辑好了以后Export出来作为一个xml文件。

image

3. 将这个format的xml发给团队的其他开发者,导入Java —> Code Style —> Formatter,以后只要在Eclipse里Ctrl+Shift+F,就能统一代码格式了。

image

 

  • 统一Imports的顺序

    在Java —> Code Style —> Organize Imports里,可以设置Imports的顺序,和Formatter一样,确定顺序后
      导出后缀为.importorder的文件,发给团队的人员,统一导入。

     

    • 利用Eclipse的Save Action保证规范能应用到代码上

      当然,上面的规范很可能开发过程中忘记Format,就依然会造成摘要里提到的问题,我们可以用Eclipse的
        Save Action,把Format source code & Organize Imports勾上,保存的时候会自动做上面两件事了。

      image

       

      • 最后,利用AnyEditor解决Win&Linux下Tab的空格个数问题

      在Win & Linux下Tab的空格个数不同是个老生常谈了,这也会影响代码提交的修订,修正这个问题需要借助Eclipse的AnyEditor插件(Download),虽然这个比较细节了,但注意下总是好的。

      做法的话,就是记得再提交代码前,将Tab用AnyEditor转换成Spaces

      image

       

              暂时就想到这么多了,从我自己的实践来看,这些做法能让开发团队无论用Svn,Git还是Hg来版本控制,都能保持一个比较好看的ChangeSet记录。

      针对国内Android市场的打包发布统计工具汇总

      摘要:国内的Android开发者上辈子都是折翼的天使,在辛辛苦苦写完代码处理了无数种分辨率,兼容性问题之后,还要面对可能要发布到400多家国内Android应用市场,各种应用中心,下载中心,论坛,QQ群,各种线下推广的巨大悲剧情况,再加上每周一个版本更新的大循环,简直暗无天日了,如果再没有一个很好的数据统计工具来衡量各个渠道的效果,那就真的永无出头之日了….下面就整理一些处理上述悲剧情况的工具,有些我正在用,有些我准备尝试,但本人也还在努力从上述悲剧中解脱出来….

      一,数据统计分析工具 —— 友盟

      老前辈们说“兵马未动,粮草先行”,数据统计其实跟粮草差不多,木有统计数据有时候真是不知道产品应该升级什么,所以我似乎去年刚开始写Android的时候就先挑了下到底用什么统计工具来统计Android程序,因为之前Web都用Google Analytics,所以那时候对刚听过的友盟和Google Analytics做了简单的对比:

      当然,因为当时项目比较紧,我对比的很不仔细,Google Analytics Mobile也没有仔细用,只是觉得友盟提供的功能比我想得还要全,就直接用了,当然这两个现在应该都有了改进,我之后会Update下。

      我自己用友盟主要是基于下面几个Feature:

      1.渠道打包统计,这样方便分开渠道来计算用户增长,对于国内这种Market推广费用极高的地方,这个非常重要。

      2.自动更新,毕竟多版本线的管理非常讨厌,自动更新能加快用户升级,虽然会有点有损用户体验….这个功能我看Google Analytics是没有的,需要另外加jar包实现,所以友盟这个挺方便的。

      3.访问页面分析,这个很像Web Google Analytics里的那个,用起来比较熟,尤其是可以分版本来查看访问分析,可以清晰知道升级后效果如何,比如我们“校园招聘求职”Android App,自从把收藏夹升级为求职管理以后,这个Activity的平均停留时间从8s升到了20s,说明这个功能被一定程度上有效使用了。

      当然,友盟还有一些需要改进的地方,我也经常意见反馈给他们,比如把本版本查看统计的层次升高,可以看到更详细的版本升级效果等,好在回复都比较快,而且态度比大多数国内互联网公司正常多了。

      二,渠道打包工具 —— 友盟渠道打包工具

      渠道就是我们平常说的Android市场,因为国内安卓市场数量庞大,我手头就有个@dicky 前辈整理的400多个市场的总表,不过我一直没能成功读完…..当然从数据统计看的话,估计有上传价值的也就20个市场左右,也就说起码需要打包20多次,这其实是个很费时间的事情,我们有两个方法解决(前提都是你有完整Eclipse项目代码):

      1.使用Ant写打包脚本

      这个方法网上很多了,就是需要为Ant打一个循环扩展包,可以参考《为Android应用增加渠道信息 自动化不同渠道的打包过程》,这个方法我没试过,因为不太熟悉Ant,就没用这个方法,不过这个方法适用情况比较广,估计在公司会用的比较多。

      2.使用友盟渠道打包工具

      我个人使用的这种方式,其实原理很简单,因为是For Windows Only的,就是用PowerShell跑个自动Ant打包过程,这里有两个需要注意:一是初次使用PowerShell如果有权限问题可以在网上查一下,就能解决,我就碰到了,忘了具体是什么了;二是一定要按Readme提供的填,我把Channel和Value写反了就识别不出来了….

      当然,这是用来打包友盟渠道的,可能不具普遍性,不过有需求的话,稍微定制一下Ant脚本,或PowerShell脚本,应该都能满足的。

      三,一站式应用上传工具 —— 抓猫

      上传应用真是个繁琐,而又没办法的事情,谁让中国特色呢(配图抓猫版权所有)…..我这周就深受其痛,每个应用市场都有不一样的截图要求,说明要求,真是非常无语,不想吐槽,最近通过@felixonmars的推友找到了抓猫,可以一站提交10来个Market,并且在不断增加中,正准备尝试一下,优势的话,自己感觉有下面两个:

      1.大部分市场可以绑定自己在各个Market的账号来发,这样不会太依赖工具,有自主权

      2.来自各大市场的统计可以一站查看(不过这个我还是建议用友盟或者Analytics,国内Market的数据实测来看太不靠谱了)

      虽然我可能会有保留的使用这种工具,但我很看好此类工具在国内市场的前景,这实在是一个刚性需求,说不定友盟也会尝试下的。

      Android:利用Google GeoCoding API替代Geocoder & 解决地址语言问题

      摘要:Android定位开发中碰到GeoCoder间歇抽风问题,查证后得知可以用Google GeoCoding API来Workaround,这里记录此过程中遇到的两个收获吧,一是对这个Workaround给出自己的简单多线程解决方案,并未做太多封装。二是解决解析结果中地址的语言问题。

      一.问题描述

      最近在使用Android SDK中Geocoder类进行地址解析时发现有很大概率发生下面的悲剧…..

       java.io.IOException: Service not Available

      具体原因有各种说法吧,也有文档

      The Geocoder class requires a backend service that is not included in the core android framework. The Geocoder query methods will return an empty list if there no backend service in the platform. Use the isPresent() method to determine whether a Geocoder implementation exists.
      意思应该是Geocoder类的使用描述在使用的前提是必须有 后台服务的支持,但是andorid sdk中不包含该服务的,Google可真够开玩笑的。在真机上不一定存在。据称可以用isPresent() 检测一下,就知道有没有了。

      二.锁定解决方案

      我在Android 的Google Code上发现各国的Developer都碰到这个问题了(http://code.google.com/p/android/issues/detail?id=8816),当然他们也提出了一些解决方案,简单总结下:

      1.使用GoogleMap请求KML来解析位置(KML的Wiki传送门),当然要了解怎么使用KML的话,还得去http://code.google.com/apis/kml/documentation/,看看文档。具体的解决方案是使用URL请求,这是Issues里给的示例,Comment 20 by musicwit…@gmail.com

      http://maps.google.com.tw/maps?f=q&source=s_q&hl=zh-TW&geocode=&q=%E5%8F%B0%E5%8D%97%E7%81%AB%E8%BB%8A%E7%AB%99&ie=UTF8&0&om=0&output=kml

      2.像Comment21里说的我们可以直接利用http地址,实现地址查询:如:

      根据地址查询经纬度:

      http://maps.googleapis.com/maps/api/geocode/json?address=SFO&sensor=false

      根据经纬度查询地址:

      http://maps.googleapis.com/maps/api/geocode/json?latlng=40.714224,-73.961452&sensor=false

      bounds的作用

      http://maps.googleapis.com/maps/api/geocode/json?address=Winnetka&sensor=false

      http://maps.googleapis.com/maps/api/geocode/json?address=Winnetka&bounds=34.172684,-118.604794|34.236144,-118.500938&sensor=false

      region的作用

      http://maps.googleapis.com/maps/api/geocode/json?address=Toledo&sensor=false

      http://maps.googleapis.com/maps/api/geocode/json?address=Tole

      具体可以查看GoogleMap服务的文档http://code.google.com/intl/zh-CN/apis/maps/documentation/geocoding/

      因为项目时间的原因,我果断采用了第二种我比较熟悉的方法。

      三.多线程完成HTTP地址解析

      这方面的教程网上已经有很多了,我就不列出我的方案了,给大家一个传送门吧

      四.中文地址问题

      我的需求是由地理位置解析出中文地址,但由Google Map  GeoCoding API返回的确实英文地址,我试过在HTTP请求中带Charset参数,但并没有成功返回中文…..

      在网上搜了一大圈以后才发现一个解决方法,原来可以直接在Url里带language=zh-CN参数,服了,估计经常使用GoogleAPI的才知道吧,也没发现相关文档,示例:

      http://maps.google.com/maps/api/geocode/json?latlng=39.9727642,116.3753401&sensor=true&language=zh-CN

      可以返回中文了,Problem Done!

      Update 2011-09-22:使用使用Google GeoCoding API过程的问题

      千万别觉得这就结束了,下面列举在实际使用Google GeoCoding API过程中发现的几个问题:

      1.HTTP连接不太稳定,注意多次尝试,而不是仅发送一次请求就使用,而要判断在没有返回值的时候尝试一定次数。

      2.有时候Google GeoCodingAPI会返回错误格式的地址,记得做处理,例如:

      请求:返回formatted_address字段,Url:

      Request URL: http://maps.googleapis.com/maps/api/geocode/json?latlng=30.511381,114.401893&sensor=false&language=zh-CN

      返回: “formatted_address”: “中国湖北省武汉市洪山区鲁磨路118号 邮政编码: 430079”

      崩溃了,居然错带了邮编…..所以还要人工处理下,防止以上情况的发生!

      参考文献:

      Android Google Code Issue 8816: service not available

      Android:用户定位User Localtion和利用HTTP解析地址—GeoCoding

      Google Geocoding API 开发语言问题

      Android REST Client架构实践 第二篇

      摘要:本篇主要针对Google I/O 2010当中提到的Android REST Client架构做个解析,对比说明Google提出的最佳Android REST Client架构的优势。

      一.传统REST客户端架构分析

      传统的REST客户端的层次架构如图1.1所示。

      图1.1 架构图

      层次结构图简述:

      (1) 当用户对资源做出操作(增删改查)时,在Activity里开个独立线程进行REST请求。

      (2) 线程执行REST请求,用相应的REST方法从REST服务上取得相应的数据。

      (3) 将取得的数据交给相应资源的Processor解析出资源的内容。

      (4) 将解析出的资源的内容直接放入相应的模型中,即存在内存中。

      (5) 最后用Cursor去取内存中的数据。

      架构劣势:

      (1) 系统可能会随时强制关闭程序。由于Android系统是为有限资源的手机设计的操作系统,这就意味着如果系统要启用一个新程序,又没有内存了,它就会强行关闭一个不在用户屏幕上而运行着的程序,很可能这个REST客户端就被杀掉了,这时候如果已经执行了GET等REST方法,则所有的数据都会下载,但没法被显示,带宽被浪费了。

      (2) 下载的数据存储在内存上。这使得可能会重复从REST服务器上请求数据,这会浪费手机CPU资源,浪费电池,浪费带宽,同时造成REST服务器上大量的请求。

      二.Google I/O上提出的REST客户端架构

      系统架构的具体层次结构如图2.1所示。

      图2.1 系统模块的具体层次结构图

      层次结构图简述:

      (1) 由用户在Activity上所做的操作(如增、删、改、查)和相应的被操作的资源的REST服务URI组合成表达式树

      (2) 将表达式树传给SyscAdapter解析

      (3) SyscAdapter解析后决定用相应的REST方法从REST服务上取得相应的数据

      (4) 将取得的数据交给相应资源的Processor解析出资源的内容

      (5) 将解析出的资源内容放入SQLite数据库相应的表中

      (6) 完成数据入库的操作以后,向发出请求的Activity发出重新读取数据库的提醒,则该Activity用Cursor来重新读取数据库显示请求数据给用户

      本章针对传统REST客户端架构进行劣势分析,然后对Google提出的REST客户端架构进行简单的解析,简要说明为何此套架构可以解决传统REST客户端架构的问题。

      下一章开始将针对Google I/O提出的REST客户端架构如何实现做实践讲解……..