资讯专栏INFORMATION COLUMN

swift开发中那些值得借鉴的写法

tinna / 1788人阅读

摘要:写在前面最近在学习,从上下载很多进行学习,收获不小,发现了一些不错的写法,记录一下方便以后查询,同时分享给大家,共同成长。

写在前面

最近在学习swift,从github上下载很多demo进行学习,收获不小,发现了一些不错的写法,记录一下方便以后查询,同时分享给大家,共同成长。

UI相关的一些常量和辅助方法

以下代码主要定义了一个swift工程中的UI部分的常量亮和定义,当然,这只是demo,正式工程可以按照这个思路进行扩展。
一个XYUI结构体囊括了ScreenColorFont三个子结构体,分别定义了屏幕、颜色、字体相关的常量和方法,结构清晰,方便后续扩展。

struct XYUI {
    
    struct Screen {
        
        static let  Width        : CGFloat       = UIScreen.main.bounds.width
        static let  Height       : CGFloat       = UIScreen.main.bounds.size.height
        static let  NavH         : CGFloat       = XYUI.Screen.IphoneX == true ?  88 : 64
        static let  StatusbarH   : CGFloat       = XYUI.Screen.IphoneX == true ?  44 : 20
        
        
        static let IphoneX: Bool = Int(XYUI.Screen.Height/XYUI.Screen.Width) == 216 //判断是否是iPhoneX序列
        
    }
    
    // 颜色
    struct Color {
        
        /// 主色调
        static let primary       =   UIColor.hexString(color: "#FFCA07")
        static let black         =   UIColor.hexString(color: "#333333")
        static let white         =   UIColor.white
    }
    
    struct Font {
        
        static func fitFont(size:CGFloat) -> CGFloat {
            
            if UIScreen.main.bounds.size.width == 320 {
                return size * 0.8
            }
            return size
        }
        
        static let f10 = UIFont.systemFont(ofSize: 10)
        static let f11 = UIFont.systemFont(ofSize: 11)
        static let f12 = UIFont.systemFont(ofSize: 12)
        static let f13 = UIFont.systemFont(ofSize: 13)
        static let f14 = UIFont.systemFont(ofSize: 14)
        static let f15 = UIFont.systemFont(ofSize: 15)
        static let f16 = UIFont.systemFont(ofSize: 16)
        static let f17 = UIFont.systemFont(ofSize: 17)
        static let f18 = UIFont.systemFont(ofSize: 18)
        
        static let f20 = UIFont.systemFont(ofSize: 20)
    }
}
关于cellIdentifier使用

关于tableviewcollectionViewcellIdentifier定义,在objective-c中,我之前是这样定义的:

static const NSString *kXXXIdentifier = @"XXXIdentifier"; //XXX换成对应cell的类名

后来发现了一个更简便的写法,就是在对应的cell中,定义一个类方法,在类方法中使用反射机制进行类名的获取,从而生成复用标识。代码如下:

+ (NSString *)cellIdentifier{
    
    return NSStringFromClass([self class]);
}

这样就不用绞尽脑汁去想复用标识的常量名了,而且更为简洁。

在swift中通常的做法和在objective-c中一样,定义一个常量,

static let kXXXIdentifier: String = "XXXIdentifier"; //XXX换成对应cell的类名

更为简洁的写法:

 public class func identifier() -> String {
        
        let name: AnyClass! = object_getClass(self)
        return NSStringFromClass(name)
        
    }

从代码上看,不管是objective-c还是swift,使用反射获取的cellIdentifier和对应的cell绑定在一起,不仅可以直接进行代码的copy复用,而且免去了在绞尽脑汁想复用标识常量名的麻烦,何乐为不为呢。

根据对应的屏幕尺寸进行缩放

我们开发中进行UI布局的时候,即使采用的是自动布局,一些控件的尺寸、控件间的间距也是应该按照屏幕的大小进行缩放的,这样才能做到标准的UI自适应。以下是以iPhone6iPhone6s的屏幕尺寸为基准进行缩放的方法,特别收录一下。

// 宽度比
let kWidthRatio = kScreenW / 375.0 //iPhone6、iPhone6s的宽度为基准
// 高度比
let kHeightRatio = kScreenH / 667.0 //iPhone6、iPhone6s的高度为基准

// 按比例自适应
func Adapt(_ value : CGFloat) -> CGFloat {
    return AdaptW(value)
}
// 自适应宽度
func AdaptW(_ value : CGFloat) -> CGFloat {
    return ceil(value) * kWidthRatio
}
// 自适应高度
func AdaptH(_ value : CGFloat) -> CGFloat {
    return ceil(value) * kHeightRatio
}

ceil函数从网上查了一下,意思是向上取整。

关于通知

iOS开发中,通知也是我们经常使用的观察者模式的一种实现。在OC中,我们通常把通知名定义成一个全局的常量,这样方便调用和修改。

在OC中,我们之前是这样做定义的:

NotificationGlobalName.h

extern NSString *const buildRouteNotification;
extern NSString *const placeDeletedNotification;
extern NSString *const centerPlaceOnMapNotification;

NotificationGlobalName.m

//`XXX`替换成工程名
NSString *const buildRouteNotification = @"XXX.buildRouteNotification";
NSString *const placeDeletedNotification = @"XXX.placeDeletedNotification";
NSString *const centerPlaceOnMapNotification = @"XXX.centerPlaceOnMapNotification";

我们可以在内部使用#pragma mark -模块名分模块定义,这样方便后续的更新和查找。

swift中我们可以这样做:

extension Notification.Name {
    static let buildRoute = Notification.Name("buildRouteNotification")
    static let placeDeleted = Notification.Name("placeDeletedNotification")
    static let centerPlaceOnMap = Notification.Name("centerPlaceOnMapNotification")
}

利用扩展把通知名定义成常量,方便后续的调用。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/17303.html

相关文章

  • 优雅地书写 UIView 动画

    摘要:原文作者译者闭包成对出现时会恶心到你代码里的闭包是很好用的工具它们是一等公民如果他们在的尾部时还可以变成尾随闭包并且现在里还默认为以避免循环引用但每当我们不得不使用那些包含了多个闭包参数的的时候就会让这门优雅的语言变得很丑陋是的我说的就是你 原文: Swift: UIView Animation Syntax Sugar作者: Andyy Hope译者: kemchenj 闭包成对出现...

    omgdog 评论0 收藏0
  • Java与groovy混编 —— 一种兼顾接口清晰和实现敏捷开发方式

    摘要:原文链接有大量平均水平左右的工人可被选择参与进来这意味着好招人有成熟的大量的程序库可供选择这意味着大多数项目都是既有程序库的拼装,标准化程度高而定制化场景少开发工具测试工具问题排查工具完善,成熟基本上没有团队愿意在时间紧任务重的项目情况 原文链接:http://pfmiles.github.io/blog/java-groovy-mixed/ 有大量平均水平左右的工人可被选择、参与...

    LittleLiByte 评论0 收藏0
  • Swift锋芒毕露 无脑意译

    摘要:建议尽量避免无用选项关键字。在选项关键字也是这样的原理,也只有两种情况有值跟中选项与布尔同样都用枚举定义。如果你要存一个布尔或者字符串的字典,你可以使用作为值。如果我们擅自添加了一类情况,我们需要更新所有用到该类枚举类型得代码。 前言 作者自己说自己很喜欢swift,因为他喜欢Haskell。可能看上了swift支持函数式编程的缘故。 中间扯皮各种略。。。 扯到函数编程刚开始不习...

    APICloud 评论0 收藏0
  • fir.im Weekly - 如何打造真正工程师文化

    摘要:英文原文链接中文翻译链接中文翻译来自微信公众号董老师在硅谷前豆瓣首席架构师如何保持团队的技术氛围在技术团队建立起技术导向的价值观良好的工程师文化,才能保持一个技术团队的创新与活力。 好的工程师,无法忍受低效且无趣的工作。优秀的技术团队应该自上而下的地推进技术平台化建设、DevOps、自动化构建、测试和部署流程,积极采用合适的第三方工具或创造工具,进行周期性的前沿技术分享等等。 先来看看...

    Raaabbit 评论0 收藏0
  • fir.im Weekly - 如何打造真正工程师文化

    摘要:英文原文链接中文翻译链接中文翻译来自微信公众号董老师在硅谷前豆瓣首席架构师如何保持团队的技术氛围在技术团队建立起技术导向的价值观良好的工程师文化,才能保持一个技术团队的创新与活力。 好的工程师,无法忍受低效且无趣的工作。优秀的技术团队应该自上而下的地推进技术平台化建设、DevOps、自动化构建、测试和部署流程,积极采用合适的第三方工具或创造工具,进行周期性的前沿技术分享等等。 先来看看...

    codecook 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<