dev

mobile website development

以iPhone 6(使用Chrome developer tools)作为参考效果调试界面,iPhone 6竖屏css宽度750px,根据lib-flexible框架计算html font-size为750/10=75px。 px单位与rem换算方法:例如某按钮宽度为150px,则在iPhone 6效果下的rem尺寸为html像素尺寸除以根元素font-size大小,即150/75=2rem。 图片如何自适应?设置到div的background-image中,设置background-size为100%,再调整div的尺寸,即div在不同设备下尺寸变化,背景图全部填充div也会因此而变化。 「像素」「渲染像素」以及「物理像素」是什么东西?它们有什么联系? rem 产生的小数像素问题

dev

region

先说结果,如果你需要构建一个中国大陆地区的省市区数据库,请只参考这里:http://www.stats.gov.cn/tjsj/tjbz/xzqhdm/,目前没有比这里更加准确的数据了,但若你又和某些电商网站集成了订单信息,那很可能还会遇到问题,可以看后面。 region问题说大不大说小不小,如果你需要精确的规划物流(或者以后有可能的话)从而降低配送成本,那么region的问题就躲不过。 我国的行政规划编码挺简单,具体编码规则不谈(如果想了解请搜索相关GB开头的文件),某GB文件提到规则中的一条就是作废了的code不会再被是使用,也许有这一条规则就够用一阵子了。行政规划结构很清晰——三级结构,第一层是省及直辖市,第二层一般是“市”、“县”或“xxx市”

dev

push notification

最近App工作接近尾声,还有几个接口没有完成,其中之一就是需要在某些事件发生的时候通知App的后台,继而由App后台通知App,比如“订单即将被关闭,请尽快付款”、“优惠券即将到期”这样的消息。因为这些消息最终是要在用户的App上出现的,一般的做法是以Push notification的形式出现,主流平台android和iOS都是在屏幕最上方出现一些提示,点击后可以进入App的某个地方。 既然这样我们就直接集成第三方平台发送相应的消息好了,不过App做得实在很遗憾,用户点击消息后总会进入到App的消息中心,再点击某条消息才能看到具体内容,这样做可能是比较快,但体验不太好,至少和现有的主流App做法都不太一样,像上个时代的做法。 以上是背景,基于此我们希望能够把App作为推送会员消息的渠道,因为短信渠道现在变得越来越不可用,仅限于发送验证码等transactional消息,其实以上说的消息都是transactional消息,区别于marketing消息,这些消息一般是由用户自主激活的或满足一定条件触发,最终是区别于用户的,一般不是群发性的,例如营销类信息就属于marketing。将用户的App作为消息推送渠道的前提是能够较准确地获取这个用户的App渠道是否可用,

dev

traps of jushita

2015年1月7日:后来和客服沟通,说是应用需要先上线,即便你还没有开始开发,这点虽然有点怪怪的,但只有这样才能申请到同步服务。应用上线挺简单,创建完应用只是第一步,完善基本信息后点下一步即可进入安全扫描阶段,再提交,瞬间说审核通过,这就上线运行了。 2015年1月9日:商家后台应用有web和客户端两种架构方式,就是你做出一个web应用,一般就是用web的架构方式,用户登陆、授权后,你能拿到用户session,然后就可以用了,和大多数oauth的方式一样,客户端类似。但有一点需要注意,商家后台应用拿到用户的session和refresh token后,文档记载session有效期1年,但这个refresh token无用,只能等session到期后重新授权。 今天开始全面接触聚石塔,就是天猫的云平台,上面服务众多,全都能收费,