Blog Archives

Yii rules验证中可以使用的占位符列表

Here’s a list of many placeholders and the validators that are using them:

  • CBooleanValidator: {true} {false}
  • CCaptchaValidator: {id}
  • CCompareValidator: {compareAttribute} {compareValue} {operator}
  • CExistValidator: {table} {column} {value}
  • CFileValidator: {file} {limit} {extensions}
  • CNumberValidator: {min} {max}
  • CRequiredValidator: {value}
  • CStringValidator: {min} {max} {length}
  • CTypeValidator: {type}
  • CUniqueValidator: {table} {column} {value}
  • CUrlValidator: {schemes}

Of course, {attribute} is known in all validators. So, which placeholders are known depends on the validator and the condition as well: By default {min} is only used when the value is below the min value (as defined in rules) and {max} when the value is above the max value.

选择

人一辈子总在不同阶段需要面临各种选择,选择真是个不容易的事情, 总是需要权衡得失和面临放弃,从心理上要过好多关。

而今,若干年前的类似选择又摆在面前了,这次还有些许不同,这次选择能容错的空间要小很多,也就是难度系数增大了不少。

这些天事情也多,忙活着好几个项目的事情,其中最有小乐趣的项目是突然奇想产生的,得到一个朋友的实战经验启发后,夜间睡觉中突然奇想想到搞个小东西,用一套目前看来合理的数学算法预测足彩,目前算法模型已经出来了,正在进行一些数据验证,期间也不断的在调整程序算法,过些天有空弄个手机端出来试试。

足彩算法的事情,多少可以让我纠结的内心得到时不时的休息,但选择终究是需要到来的,该怎么决定呢?

国税这个衙门真不好伺候!

最近要给一个废弃多年的公司补税交罚款,还得填一百多张乱七八糟的表格,崩溃了!

想起不久前和一个税务的哥们聊天开的玩笑话。

我: 你们这些腐败的GCD啊!
哥们:都你们害的,你们能做到不让我们腐败么?
我: 汗。。。

setenforce 0

不重启机器就得时不时来这么一下,不爽,习惯了FreeBSD,突然切换到CentOS,还得磨合!

互联网创业的些许体会

看着上一篇BLOG的日子越来越远,心里不禁有一丝惶恐和不安,通常久不更新blog,都不是什么好事,要么生活没规律,人也懒惰,要么就是真的没什么可以写的,这两者都不好,尤其后者,有激情的人,每天都能从平淡中发现精彩,没什么可写,从一个侧面上反映出激情的流失,这显然不是什么好状态。

回顾一下过去这段“空白期”,发现主要还是因为懒惰而疏于更新,今天打开一个朋友的blog,连续读了几篇最近的日志,内心受到莫名的触动,朋友是个工作忙碌的人,全世界到处跑,但是多年来一直都坚持很高效率的更新日志,近期的几篇文章,大多和在柏林的新家有关,一些生活琐碎的事情,比如搬家、宜家买家具、植物园一类的,但通篇读下来却使人觉得很舒服,淡淡的真实。

受到朋友的鞭策,于是决定也奋发图强一番,在输入标题的时候,思考了良久,纠结的关键在于一个词,原本顺手写了这么个标题“互联网创业的些许感悟”,后来怎么都觉得“感悟”一词不恰当,总觉得自己离那种意境有那么点差距,弄不好会有一些误导作用,最终还是决定用“体会”代替了“感悟”, 恰到好处的感觉。

创业,很多人眼里认为那是很牛逼的,好像都是牛逼的人干的事情,其实对身临其境的人,经历创业时间久了,会时不时的从心里对创业一词感到些许的刺耳, 常常和朋友聊起去过,北漂十多年了,经历过大小公司几个,经历过创业若干年,错失过大小机会不计其数,放弃N多职业经理人的路,而今,依然还在所谓的创业路上,干脆一点,依然还在所谓的创业路上“挣扎”

大多数人认为创业是牛逼的事情,主要因为他们眼里看到的大多是那些成功的案例,尤其在互联网行业, 一个成功的创业案例会很快通过网络传播到世界各地的各个终端,进而影响到更多人进行追逐,事实上,我们99%的时间,看到的都是那1%不到的成功案例,还有另外那99.99%的失败或者正在梦想成功的道路上是看不到的,这个行业的特点非常鲜明,一个硅谷的成功神话,会带来全世界成千上万追随者,他们省吃俭用、熬夜加班、不拿工资、吃得苦中苦只为了有一天也能和那个神话一样的成功,最终的结果是99.9%的以失败告终,不管怎样,也算经历了一次创业。

08年开始,我和美国回来的朋友一起创业至今,总结起来,经历得比收获的多! 08年刚开始的时候,正是FourSquare带来的LBS风刮遍全球的时候,我们成为国内第一批LBS创业的团队,蹦心网不仅有网站, WAP站、android客户端、ios客户端,相继在我们夜以继日的工作中诞生,那个时候,我们的产品确实在行业中算是领先的,我们团队的成员时刻充满激情,不停的改进,总觉得没有完美的时候,在追求完美产品中度过了最初的两年时间,用户的增长却是非常的缓慢。

就在彷徨踌躇之际,Groupon又刮来了更猛的一场飓风,瞬间让业界和用户的目光都转移到了团购上,一夜之间,已经很少听到LBS相关的声音,好吧,团购确实来势太猛了,门槛又是如此低,不到一年时间,几千个团购网站出来了,一个个身边的神话诞生中,仿佛整个互联网的春天来到。 对于我们来讲,当时面临的抉择是困难的,有包袱的人舍不得放下,曾经为了LBS所做的那一切总是牵绊着我们前进的步伐,在面对团购的机会之际,我们举棋不定,在好多团购网站都火起来的时候,我们才下决心暂停LBS的产品改进,推出了一个介于团购导航和自己独立团购的不伦不类的产品:乐搜网,后面的结果就不用细说了。

再后来,我们在有些迷茫中,又腾出部分精力,追逐了Pinterest的步伐,尝试性的推出了一个瀑布流的图片产品每日美图(包括android客户端),结果当然也不甚满意。

回顾过去几年的经历,体会到创业途中的苦辣酸甜,总结一下,大致有这么几点。

1. 我们的团队太过偏于技术产品型,推广和运营严重不足是我们创业没有开花结果的最大障碍
2. 我们的产品设计上总是太过复杂,追求尽善尽美成为了我们发展的绊脚石
3. 推广和运营真的需要有钱才行,寻找到合适的投资人加入是创业必须的
4. 我们总是走在行业的热点中,那里真是一片红海,根据自己团队的情况,选择合适的项目进行起步非常关键
5. 在面对机会的时候,犹豫不决舍不得放弃,导致多次没有走在热点的第一波,后来者的结果基本都是悲剧
6. 爱因斯坦说,成功需要99%的汗水+1%的运气,其实那1%的运气非常重要。

前不久和一个打算从大公司出来选择创业的朋友吃牛蛙,席间谈起他一个朋友的创业经历,让我颇受触动,他那个朋友前两年弄了个网站,上面罗列了国内外各种汽车配件的价格,仅此而已,在大家都在追逐LBS、团购、瀑布流的时代,这样的东西显然很不入流,却没想这个网站挺成功,保险公司的介入给他们带来了发展的机会! 这个故事告诉我们,互联网创业追逐热门固然有一些好处,比如行业和用户都在关注,投资领域的钱也都在涌入,从成功的机会上来说,确实具备更多有利条件,而最大的不利条件是,参与竞争的对手太多,杀得红海一片, 而那些我们不太关注的领域,做精做细做深入,才是真正的蓝海。

而今,移动互联网的热潮越来越猛,在这个领域里面,貌似充满了无数的机会,今年,我们的团队度过了4个多年头的创业时光,在经历了LBS和团购两场风暴的洗礼以及Pinterest跟风之后,我们冷静了很多,也可以说有些疲惫了需要好好调整,在面对未来的选择问题上,我们变得谨慎而小心。 最近,我们一直在关注health领域,医疗健康、运动健身很明显是下阶段的热点,但是时间窗口似乎也快要关闭了,寻找到一个属于自己的小片蓝海在里面畅游,是我们接下来最需要做的事情。

关于ListView的性能,推荐一篇老外的好文章

对于纯文字内容的ListView,基本可以不看了,除非你数据量巨大,那你还是需要看。

对于有大量图片的ListView,这篇文章必须看,我之前在Android上开发应用时遇到一个ListView,每个Item里面都是若干张小图片,纠结于性能的改进很长时间,最终受益于这篇文章得以改进!

原文很长,我就不贴内容了,这里是链接地址: Performance Tips for Android’s ListView

新浪微博 Android SDK中OAuth2.0隐式授权部分的一个代码逻辑问题

在最近使用新浪微博android sdk开发微博登录的时候,从日志中发现一个问题,就是自定义的WeiboDialogListener里面的方法,比如onComplete或者onCancel等,经常会被两次调用,这样其实会导致一些隐性问题,比如增加额外的客户端和服务端的开销,因为我们通常会在onComplete()里面完成更多后续逻辑的处理,而发生这样的情况时,会被处理两次,一开始我犯懒,就在方法外面加入了一个变量 isCompleted 来进行判断,算是暂时解决了问题,后来在好几个地方要开发类似功能的时候,总感觉心里有点儿不爽,于是决定找找到底啥原因

看了看微博sdk里面的代码,在 WeiboDialog.java里面找到了问题,这个java文件主要实现的是创建OAuth的UI,并且通过实现和调用WebViewClient的方法来访问微博的api以及咱们app的callback url, 进而通过WebViewClient里面捕获当前请求的URL,分析URL参数后进行相应逻辑的判断,通过分析,问题应该是在这部分。

在WeiboDialog.java里面有个函数 handleRedirectUrl(),这个函数就是用来判断认证和授权过程中返回参数的,代码如下:

private void handleRedirectUrl(WebView view, String url) {
        
Bundle values = Utility.parseUrl(url);
 
        
String error = values.getString("error");
        
String error_code = values.getString("error_code");
        
        
if (error == null && error_code == null) {
            
mListener.onComplete(values);
        
} else if (error.equals("access_denied")) {
            
// 用户或授权服务器拒绝授予数据访问权限
            
mListener.onCancel();
        
} else {
            
mListener.onWeiboException(new WeiboException(error, Integer.parseInt(error_code)));
        
}
    
}

一看就知道啥意思了,关键的逻辑就在这里面,回调我们自己实现的WeiboDialogListener里面的方法,顺藤摸瓜,调用该方法的代码就在实现WebViewClient里面,研究了一下该部分代码,找到了原因

在WebViewClient中,我们需要实现至少shouldOverrideUrlLoading()方法,该方法在每次加载新url的时候调用,另外,我们还通常会实现onPageStarted()方法,该方法也是在新url开始加载的时候进行调用(注意:在frame里面加载是不会调用的,详细文档见http://developer.android.com/reference/android/webkit/WebViewClient.html)

在WeiboDialog.java实现WebViewClient对象的时候,在shouldOverrideUrlLoading()和onPageStarted()里面都同时调用了handleRedirectUrl()来进行回调url和参数的判断,结果就导致了我遇到的问题,于是我们可以把里面的一个去掉,或者增加一个参数来进行判断,避免重复调用,目前一切正常了!

onClick / onLong / onGesture 同时存在时,点击、滑动、长按屏幕的事件处理顺序

在Android开发中,如果一个Activity里面同时继承实现了 onClickListener、onLongClickListener、onGestureListener, 此时手指在点击、滑动、长按屏幕是各个事件处理的顺序是如何的呢,通过实际项目中写日志得到如下的结果:

点击松开: onDown / onShowPress(稍长会有) / onSingleTapUp /onClick
滑动松开: onDown / onScroll(多次) / onFling / onClick / onLongClick
长按松开:onDown / onShowPress / onLongClick / onLongPress
长按并滑动后松开: onDown /onShowPress / onLongClick / onScroll(多次) / onFling

知道这个顺序后,就知道如何处理各个需要的逻辑了,同时需要注意一点:在每个过程中,任何一个事件里面return true了,后面的就将不再执行,如果要同时执行多个事件,可以在每个事件内部处理完后,return false, 后面的事件就将继续进行

RelativeLayout的选中状态变化

在layout的xml文件中设置focusable以及background,并定义background指向的xml文件中有关selector,到此还是不够的,如果不在java文件里面定义onClickListener事件的话,在手机上运行并不会看到选中状态的变化。

Android动画背景图自动播放的实现

我们在开发android应用的时候,经常会遇到类似从网络加载大图,在加载的过程中,在图片要显示的ImageView位置,先显示一个转圈的loading动画图,给用户的体验会更好一些,要实现这个动画图很简单,使用在/res/anim中定义xml的方式,通常使用…. 来实现。

不过大多数朋友都会遇到的问题是,动画是做好了,但是界面在加载的时候,动画并不会自动播放,还得通过屏幕点击等事件来触发,这就失去了意义了,实际上,android的动画AnimationDrawable 组件里面有个start()方法用于启动动画播放,但是这个方法不能直接写在onClick,onStart,onResume里面,写进去也是无效的,无法启动动画,只能写在比如事件监听当中,于是我们可以使用点小技巧来实现自动播放

目前我知道的有三种方法:

ImageView imageView = (ImageView)findViewById(R.id.xxx);

方法一:使用Runnalbe()来加载

imageView.setBackgroundResource(R.anim.xxxxx);
final AnimationDrawable animationDrawable = (AnimationDrawable)imageView.getBackground();
imageView.post(new Runnable() {
    @
Override
        
public void run()  {
            
animationDrawable.start();
        
}
});

方法二:使用AsyncTask异步加载启动

imageView.setBackgroundResource(R.anim.xxxxx);
AnimationDrawable animationDrawable = (AnimationDrawable) imageView.getBackground();
RunAnim runAnim=new RunAnim();
runAnim.execute("");
 
class RunAnim extends AsyncTask<String, String, String> {
        @
Override
        
protected String doInBackground(String... params) {
            
if (!animationDrawable.isRunning()) {
                
animationDrawable.stop();
                
animationDrawable.start();
            
}
            
return "";
        
}
}

方法三:通过添加addOnPreDrawListener来自动加载

imageView.setBackgroundResource(R.anim.xxxxx);
AnimationDrawable animationDrawable = (AnimationDrawable) imageView.getBackground();
imageView.getViewTreeObserver().addOnPreDrawListener(preDrawListener);
 
OnPreDrawListener preDrawListener = new OnPreDrawListener(){
    @
Override
    
public boolean onPreDraw() {
        
animationDrawable.start();
        
return true; //必须要有这个true返回
    
}
};

以上三种方法经过测试没有问题,另外网上有一些说使用重写Activity的onWindowFocusChanged()方法来实现,但是还是有不足,得改变焦点才能触发,虽然理论可以自动实现改变焦点,感觉还是不甚可取。