WeatherMap
by Takefive Interactive
Swift be96ac377759f6bedd050cadf002337ffc546388d9fbc7031e01a14ac965c322

最初因为在上HCI方面的UI Design课程,动手做了这个App,想要尝试一些新的交互方式;也有因为意识到市面上没有很好的 地图 + 天气,用来 Road-Trip 的App,于是就和小伙伴们试着做一个。

 

从开始做的时候就是开源的;拒绝 Objective-C,从头到尾都是 Swift,用了以下开源库: •Alamofire for network request •SwiftyJSON for handling JSON api •Spring for code-less animation •FMDB for data storing •GPUImage for image handling •HanekeSwift for cache •Shimmer for animation 就连整个图片 UI 都是开源的。

 

我们从 Sketch Resources 等取得了原始的一些非常不错的 Sketch 素材;确认了这些素材的 CC 协议符合我们的使用之后就做了更一步的修改,有了icon 和 整套天气图片。想要使用他们的人也可以在我们 repo 中看到我们的矢量 Sketch 素材。欢迎使用。

 

做到一半的时候遇到了几个比较麻烦的问题,最大的问题是,穷,以及各种 API 坑。比如在这个repo 的 wiki 里我们写过:

 

## Temperature unit inconsistencies OpenWeatherMap returns temperatures either in Celsius or Kelvin. There is no indication of which unit is currently in effect and the API does not document this inconsistency. (有省略) ## Incorrect Geo-info in Europe and Asia City data was taken from OpenWeatherMap API. We received complaints from Russian customers saying that it provided them with wrong city information. Similar problems happened in China, where incorrect city names are occasionally reported. Below are some relevant screenshots.(有省略)

 

当俄罗斯的用户 Review 说城市地理信息彻底爆掉,搜不完全不准的时候,留下了一个2 stars 和评论「Even City detection is wrong; Fix your geo」……我们也是完全崩溃的;研究一圈发现是 OpenWeatherMap API的 geo 坑了,然后谷歌的城市搜索在大俄罗斯也坑爹了……欲哭无泪。

 

还有就是OpenWeatherMap的温标也是个大坑货;在很多国家天气信息被当做机密处理,完全没有爬到温度;然而这个 API 经常会开氏度摄氏度 乱返回 (有些国家气象站是开氏度记录等等),然后 OpenWeather 数据量大了之后就没有处理,胡乱返回……

 

于是我们只能在前端程序里根据地理信息等等判断这个温标到底是不是返回抽风了(直接判断是不是零下太多这种也想过,在大俄罗斯这招不行) 。

 

穷,或者说,没人捐款也是很大的阻碍。

 

大部分参与这个 App 的人,以及Takefive Interactive 的很多成员都有自己的商业项目。我们希望这个小 App 可以给更多人启发,特别是关于纯 Swift 使用;跨国 API 稳定性等等。

 

虽然本来是为了 UI 设计课做的 demo,但到最后 UI 反倒成了一个附加值(当然 UI 也是开源的)。至今只收到了200RMB 的捐款,考虑再三之后,只能暂且无后端,把很多后端工作放到前端。

 

举个例子,比如 QTree 的使用。如果大家还记得数据结构里 QTree(在二维地图上,是 QuadTree,四叉树) 是干嘛的话应该能猜到我们为什么用。。。没错,WeatherAPI 在很多国家访问慢到爆,在获取城市点的时候勉勉强强,但是如果一个地方城市密密麻麻呢?一个简单的处理方法就是用缩放所在的 Scope 来决定显示多少城市,给予不同城市不同权重——比如在纽约附近,如果只能显示一两个城市,那首当其冲是纽约——用户缩放了之后,在显示出曼哈顿,长岛等等。

 

用这个思路,加上我们后端服务器没有,于是我们询问了Open WeatherAPI 的许可协议等等,发现对方允许我们把 geo 点给抓下来本地处理(可见他们更新多慢 orz)。抓下来之后先各种去重去脏数据一遍(果然有 orz),然后zip,用 QTree处理……

 

做了一个全球范围内的空间索引(Spatial index)。 详细可以自己看代码,这里也有 wiki 对于这个的介绍:

 

https://zh.wikipedia.org/wiki/%E5%9B%9B%E5%8F%89%E6%A0%91

 

当然最大的坑,还不是这些……是天朝内网。

 

谷歌挂掉,flickr 的 API 挂掉(选择 flickr 是收到雅虎天气启发,他们用的是 Flickr的私有 api,而我们用了一大串正则去处理搜索 index 等等,再返回热点图)……

 

有段时间特别崩溃怎么处理,甚至想过发两个版本。后来一直在看 Airbnb 和 Uber 到底是怎么处理的,发现 Airbnb 处理的也不是很给力,但是 Uber 处理的是最好的;奈何架构差距和体量差距毕竟不一样,我们连后端都没有(没有捐款收入),只能最后还是采用保守的 Mapkit 结合了 高德地图和 谷歌地图的办法(为什么不直接自己写切换之类什么的呢……因为高德地图的 pod 包会跟谷歌地图冲突……)

 

这几天还跟 Nokia Here Map 的朋友们稍微扯了两句,发现这个坑真是大的不得了。 here他们处理的很好,也有想法要不要多试试看多折腾下。

 

Again,光看你可能会觉得这只是一个 UI 比较讨巧,元素 ok 的 App,不过要知道它可是在全世界都可以正常使用的,就在API 范围的温标 bug 都强行 fix……

 

希望我们开源出来的 Swift 用法;那些 API 的坑;包的冲突的坑 & 用法;开源的UI 元素;以及在前端强行做一个全球级别的 Geo-info 索引的方法,能给大家一点启发和帮助。

 

如果大家感兴趣也可以一起参与 pr;做点折腾——我想这就是开源的意义。

 

2015 tk5.us from UIUC

 

作品简介

结合了地图&天气,为Road-Trip设计的 App; 曾被 The iOS Times 推荐的 Swift 开源项目(完全用 Swift 写就);已经上架 iTunes。

分享:
0
 128
活动介绍
「寻找实干和坚持的技术力量」是100offer互联网人才拍卖平台独立策划举办的Side Project赞助活动,只是为了向那些视程序为生命、不断在前进的人致敬。
Ad 9482dbb9a1a2921bad6fd499d6d31682c63adfa80c64e8207eea49c78530cdac
Close 44c5a73a048146b9665e653b76f391a9ea025b4eea85f5fff01b8b686e69d372
Smile 144711c94a3fb669870f9d809cc27e690ec118adb5ac8c333830d888b8b81202
谢谢你的支持。100offer Side Project赞助活动投票已结束,但正能量不会结束。