Posts

BuildConfig.DEBUG 首先在Gradle脚本中默认的debug和release两种模式BuildCondig.DEBUG字段分别为true和false，而且不可更改。该字段编译后自动生成，在Studio中生成的 ...

merge和include的区别是 ...

在工作过程中，各种文本框的输入有各种特殊需求，如输入整数、字母等等需求。现公司业务需求，要求某文本输入框，只能输入整数，并且不能出现以“010”，数字出现以0开头的情形。 经过查询文档，发现EditText可以通过addTextChangedListener方法，添加文本变化的监听器。我们可以通过该监听器对以0开头的情形进行处理。 ...

在知乎上开到这个问题，我只能说提问题的人，你还搞不懂“喜欢一个人”和“对一个人有感情”之间的区别。 我举两个不恰当的例子。比如说养狗，虚构两个情景。 情景一：  某天你去宠物市场闲逛，发现有一只泰迪很可爱，伶俐活泼聪明漂亮，还特别粘着你。你当时就动心了，打算买下它。  一问价格，要1500块钱。你身上没带这么多钱，也没带银行卡。当时是下午了，宠物市场马上要关门了。你只能第二天来买了。  于是你嘱咐店主千万不要卖给别人。一定要等你明天早上过来卖给你。店主答应了。 可你回家了还是不放心。晚上在床上都睡不着觉。生怕店主不守信用，把这狗狗卖给别人了。那感觉，就像是爱上了一个姑娘一样。  第二天一早，你就揣了1500块钱奔向宠物市场。  这次，你是从市场的另外一个门进去的，还没有走到昨天那个摊位，你突然发现了另外一只泰迪，比昨天那只更漂亮，更聪明，更可爱，更粘你，价格还更便宜，只要1200元。  我相信，只要你智商正常，你都会选择买1200的这一只。虽然，你为了1500的那一只牵挂了一晚上。但那又如何，遇上更好的，你立刻就移情别恋了。 我们都是这样的人。 因为，我们对那只泰迪，没有感情。 情景二：  某雨天你下班回家，看到一只流浪的小狗趴在你的家门前瑟瑟发抖。你一下子恻隐之心上来了，把它抱回家，给它洗澡，给它喂食，让它睡在毛毯子上。  从此，它就成了你的家人。  接下来的一年，每天早上是它叫你起床。每天你疲惫的下班回到家中，是它在门口等着你。你出去逛街，它走在你前面。有小偷偷你的包，它疯狂吠叫。你看电视，它就睡在你腿上。你上网，它就趴在你脚尖。 它已经成为了你生活的一部分。  一年后。有一个人，也不知道脑子怎么进水了，想要拿一只名贵的纯种狗狗来换你这只不值钱的收养的流浪狗。 你会换吗？ 如果是我，当然不换。 因为我对它有感情了。 这就是感情。

慧极必伤，情深不寿，强极则辱，谦谦君子，温润如玉: 这是金先生<书剑>里,乾隆送陈家洛佩玉上的刻字。大意：一个人太聪明智慧便会对自己有损伤，过于沉迷和执着的感情不会持续长久，过于突出的人势必会受到屈辱，君子应该如玉一般的温润沉稳，含蓄坚毅，不张扬，却自显价值。 金庸在《书剑恩仇录》中，借乾隆送陈家洛佩玉上之刻字，道出自己人生特别推崇的境界，正是这四句十六字。 但很有意思的是，如此佳句居然没有人能查其出处（人们都认为其境界颇深定有出处）。有人查遍孔孟老庄，以及四书五经，均无所获，故将此难题贴于网上，一年多来终无所获，故被称为“武侠与国文的一个绝题”。其中，最接近的答案是《国风·秦风·小戎》里有“言念君子，温其如玉。”，《易经》第十五卦中有“谦谦君子”，但仅此而已。 金庸“谦谦君子，温润如玉”之说不知其出处，但从《书剑》所蕴涵的他早期的人生 理想来看，这似乎是金庸所推崇的一种人生境界。 飞扬跳脱的个性不属于谦谦君子，因为，玉的光芒是凛于内而非形于外的。雍容自若的神采，豁达潇洒的风度，不露锋芒，不事张扬，无大悲大喜，无偏执激狂，生命的状态在这里呈现出一种成熟的圆润。 佛家有一个词，圆融，是跟这种成熟的圆润颇为相似的境界。是以佛家讲求戒嗔、戒痴、戒贪，无欲无求，尔后能不动声色、不滞于心。谦谦君子的圆润亦同此理。 而要达到这种境界是需要修炼的。修炼是一个很奇妙的词语，人生在世实质上就是一个修炼的过程，只不过并不是人人都可以修成正果。 修成佛、修成仙是尘世之人遥不可及的梦想，但磨去棱角、收敛光华、修成谦谦君子却并非太难的事情。容人之量是修成谦谦君子的前提。斤斤计较、小肚鸡肠修不成君子，开阔的心胸、通透的眼光，才是君子的气量。 于是，我们常常可以看到这样的人，荣损得失面前，总能一笑置之。正所谓，宠辱不惊，闲看庭前花开花落；去留无意，漫随天外云卷云舒。 剑有双刃，谦谦君子亲切柔和，少了无拘无束的冲动莽撞，却也少了率性率真的刚猛豪放。正如一个人磨砺的过程一样，成熟的获得是以天真童趣的无可追回为代价的。 当然，“情深不寿，强极则辱”的背后，似乎也透着一种淡淡的无奈。试想，人活一世，谁人不想追求恒久？只是恒久不可强求，于是退一步海阔天空。这何尝不是一种迂回的战术、以求得宛转的余地？谁能说这种淡淡的无奈不是一种生存的智慧。

原文链接 : Composition over Inheritance，What it means for your Activities 原文作者 : Josh Brown 译者 : chaossss 校对者: Mr.Simple 状态 : 完成  事实上我们在很多 Java 进阶书籍上看到过“开发时应该更倾向于选择组合而不是继承”的建议，为什么建议我们更倾向于而不是完全代替呢，因为当类 A 能完全代替另一个类 B（我们想让 B 成为 A 的父类）时，我们就应该使用继承，如果 A 仅仅是和 B 有着某些共同的行为，是不应该使用继承的（更多的讨论戳我）。然而，在我阅读别人的源码时，滥用继承的情况实在是太多了，多少人创建了一个 BaseActivity 后，就让所有 Activity 继承它，在子 Activity 中实现业务逻辑。  而且这样做问题大大的有，最鲜活的例子就是：Joe Newguy 加入到我们组，并实现了 ShinyFeatureActivity，那会组里没有任何规定强迫他必须让 ShinyFeatureActivity 继承于 BaseActivity，但他还是这么干了……万幸我们在 Code Review 时发现了这个问题。此外，如果每一个 Activity 都继承于 BaseActivity，在某些情况下，你可能要继承的是其他 Activity（例如：PreferenceActivity、ListActivity）。尽管大部分 Activity 的子类都有相应的 Fragment 代替，但还是有一部分是没有对应 Fragment 的，某些库仍然需要相应的 Activity 子类。  有些更潜在的问题是：有时候某些 Activity 需要这些行为，其他的 Activity 需要其他行为，而 Java 并不支持多继承，这就意味着我们得将行为有交集的 Activity 的所有行为放到一个独立的类里面。但这样做会降低可维护性，甚至带来性能影响。...

语法（SYNTAX）： <receiver android:enabled=["true" | "false"] android:exported=["true" | "false"] android:icon="drawable resource" android:label="string resource" android:name="string" android:permission="string" android:process="string" > . . . </receiver> ...

目前在Android中通知的使用还是很常见的，为了做版本兼容，常用兼容包NotificationCompat.Builder和 Notification.Builder。 NotificationCompat.Builder位于v4扩展包内（version 4 Support Library） Notification.Builder在Android 3.0 开始引入(API level 11). 最近在Android5.0设备上发现一个问题：通知图标突然变成了白色的方块而不是代码中设置的icon。 问题原因 细读开发者文档其实也可以发现一些线索，虽然笔者是直接查的源码发现的问题原因。http://developer.android.com/design/patterns/notifications.html 一文的Use distinct icons部分介绍了几点关于通知的建议，其中的有两点是建议开发者不要做的行为。 Don’t Place any additional alpha (dimming or fading) into your small icons and action icons; they can have anti-aliased edges, but because Android uses these icons as masks (that is, only the alpha channel is used), the image should generally be drawn at full opacity. Don’t Use color to distinguish your app from others....