最近动态

编程

iOS线性布局?

前几天通过比较了iOS和Android端BLE蓝牙开发时,订阅Characteristic的不同,得出了Android订阅特征相当复杂的结论。但是在结尾我也替Android开发洗了一次白,因为今天说的这个东西,在iOS上非常难搞,而在Android上相当容易!

Context

新的码表产品,是一款为广大骑行爱好者省钱的GPS码表!

这个硬件会记录骑行时候的速度,位置,海拔,心率,踏频,等等等等信息,并在表盘显示实时的状态。所以,手机的用处就是,将骑行记录导出,然后对数据进行备份,为骑行者分析骑行过程。

咱们不仅仅是价格很厉害,在同步方式上也很厉害。因为我们可以通过Wi-Fi同步,而不仅仅是蓝牙同步。Wi-Fi的速度可比蓝牙高得多。不过这些都不是今天的主题,今天是要说app中,展示某一次骑行详情时候的图表展示。

废话不多说,先上图

iOS
Android

这里的图表的表项,是不确定数量的。比如说,这个用户没有踏频器的话,那么数据分析中就会没有踏频的图表。没有心率计的话,就会没有心率的图表。

Android

Android实在是,太方便了吧!

用了LinearLayout之后,我们把所有有可能出线的图表,都写在LinearLayout中,外面再套一个ScrollView。

不需要的图表我们直接把它setVisibility(View.GONE)就完事儿了,后面的图表会紧紧的挨上来,不会留出一个大空白来。

而且ScrollView会随着LinearLayout的大小来确定是否可以滑动,最多可以滑动多少距离。

iOS

没有LinearLayout,只有frame或者auto layout,你说怎么办?

用框架!

是的,有MyLinearLayout,很方便,就是对标Android的LinearLayout做的,其原理也是逃不掉frame和auto layout的。

如果我用框架做,那还写这篇干什么呢~

因为如果不手动写,是完全不会遇到UIScrollView和AutoLayout的一个大坑的!

Step 1

想法很简单,我只要给一个变量叫做lastChart,其实就好了~

@interface ChartViewController () {

    UIView *lastChart; //用了表示上一个图表的指针

    UIScrollView *scrollV;
    UIView *contentView;
    __weak ActivityDetailPresenter *presenterReference;

    ChartBlockView *distanceView;
    ChartBlockView *timeView;
    ChartBlockView *cadenceView;
    ChartBlockView *heartView;

}
@end

这里ChartBlockView表示图表,他是UIView的子类,所以lastChart完完全全可以引用他们。

Step 2

每次从Presenter中reload图表数据的时候,我会一个图表一个图表的去渲染。

比如,我先去检查,有没有速度信息,有的话就搞一个速度的表,没有的话就跳过。

再获取踏频的数据,有数据搞一个踏频的表,没有的话就跳过。

每次在渲染一个表的时候,会去检查lastChart是否为nil,如果为nil,那top就以顶端为参考;如果不为nil,那top就以lastChart的bottom做为参考。

根据这个准则,便很容易实现。

Step 3

当我兴高采烈的run了之后,发现可以显示,但是scrollview完全不能滑动!

查看了view Hierarchy,发现UIScrollView的ContentSize竟然是(0,0)!

因为……autolayout并不能填充scrollview……

所以,后来我又花了些时间,解决了这个问题……

End

所以,iOS没有LinearLayout还是蛮讨厌的……

虽然iOS原生推出了一个新的控件,就是LinearLayout,但是需要iOS 11……

预知后事如何,请听下回分解……

阅读剩下更多

学习

G3-PLC 学习历程

Context

好像很久很久没有更新博客了,最近事情确实太多了。新产品的app,教研室新项目,两个大头。还有毕业设计的开题,虽然我想好了题目,但是,磨人的开题报告,也是个很头疼的东西。

这次教研室的项目是电力线通信,使用G3-PLC协议,这也是第一次做一个偏硬件的项目了,一开始老师在问大家有没有兴趣的时候,还是蛮犹豫的,但是还是因为兴趣,决定搞一下试试。

花了几周的时间好好的熟悉了一下这个协议。在电力线通信的场景中,会有很多意想不到的情况。比如A->B是直连的,B->A就不能直连,需要绕一条路走。而且电力线网络的拓扑结构是会随时随刻在改变的,这一时刻你和他直连,下一时刻他就不见了。

对于这种物理层这么不可靠的连接,需要在它的基础上构建一个相对可靠的网络,还是比较麻烦的。G3-PLC借鉴了ZigBee的技术,并且引入了6LowPan技术,使得这个网络的可靠通信成为可能。

ZigBee?

ZigBee不是无线的嘛?

这电力线是有线连接的,竟然还需要用无线的协议。其实他们还是挺像的,ZigBee每个节点的发射功率有限,为了与不在射程范围内的节点进行通信,就只能通过其他节点来帮助它传递消息。电力线虽然说大家都是有线连接在一根主线(总线)(插线板)上,但是他的衰减比较严重,那么中间节点就需要充当一下”中继”,将收到的消息进行转发,以实现全网的通信。

6LowPan?

这个概念倒是很有意思,大家都知道ipv4的地址就要分配完了,所以赶紧推广ipv6是非常重要的,而物联网时代,网络节点的数量会比互联网时代大的更多,毕竟每个物联网外设都很便宜,他们要入网也需要一个地址来标识。大概是出于这一点的考虑,G3-PLC在设计的时候就引入了6LowPan,是一种有超大地址空间的一个协议。这个名字很奇特6LowPan,他的意思就是低功耗的,ipv6的,个域网。

为了低功耗,它甚至省去了很多数据,通过减少数据量来降低功耗,真是很拼。

Router

网络通信,最重要的一个部分,莫过于路由了。

G3-PLC的适配层用了LOADng协议,这个东西的资料比较的少。不过另一个东西的资料我在图书馆里找到了很多——AODV,是Ad Hoc网络中的按需询问的路由协议。LOADng是,新一代轻量级按需路由协议。

怎么个轻量级,我现在还真是说不准,按照我自己的猜想,这个轻量级只是减少了一些操作,少维护一些内容,数据发送频率低一些。

比如说,在刚加入网络的时候,AODV协议里需要节点对整个网络进行一下”摸索”,比如发送RREQ询问一下距离本节点x跳的各位节点,维护一张路由表。中间节点也会根据这个RREQ请求,自己建立一张表,在未来出现链路中断现象的时候可以发送RERR信息告诉上游节点,路线断了。

不过,按照我的理解,以及我对官方给的非常简略的协议的理解,以及我对借的各种书的理解,我觉得这个低功耗大概是第一次获取路由的时候只获取一跳的节点、出现断路不通知、之类的操作。通过这一系列的优化来达到轻量级低功耗的目的。

Oops…

其实在理解这个协议的时候还是走了不少弯路的,比如我一直无法理解自己的地址是怎么来的,直到我明白了这个系统有coordinator和device两种设备。我一直不知道我怎么获取别人的地址,知道我想明白,这个地址不用我们获取,而是上层指使就好了。

这个项目从最早的无从下手,到现在感觉有把握了。我觉得自己还是学到了不少新东西,说明自己还没有老。作为一个学生还是要有这种学习能力的嘛~

下面大概要好好研究一下Keil和嵌入式开发了!

阅读剩下更多

日记

东西多啊

最近真的是很忙呢。

上周刚刚把公司官网勉强整好,写前段并不是主要的目的。做官网主要的目的是学习一些先进的前端技能。虽然光靠html,css,js就确实可以完成所有的网站需求了,但是,要提高效率,与时俱进,这些必然是不够的。所以通过做官网,我顺便补充了一些技能,什么node.js,gulp,vue.js,angular之类的高端东西。不过实在是太忙了,所以就只能空了再整理到博客里面去。

教研室项目也是很多……包括做不出来的,以及不可能做出来的东西…

比如二维码防伪,你别以为是简单的用二维码防伪…而是验证一个二维码是不是真的,仔细想想,是不是没可能…?

G3PLC电力线通信协议??好难啊!如果我能把这个做出来,估计可以在嵌入式领域装个逼了~哈哈

还剩一个比较轻松的,就不用说了。

12月要出一个新产品,感觉时间也是非常的紧。虽然前面花了一些时间,整了一下socket的知识,但是感觉这个项目还是蛮大的(而且有iOS和Android两个版本呢)…希望可以按期完成吧。

生活很艰辛,抽空还是要吃几盘鸡的,对吧!

阅读剩下更多

返回顶部