Check if current device is older than a certain device? about devicekit

[dennisweissmann]

Hey :)
Currently unfortunately not! ☹️ I'm currently completely rewriting DeviceKit to be protocol oriented and Swift-3-ready. If you have an implementation in mind (other than comparing them by hand) a pull request is very welcome! :)

Considerations: How would you compare an iPhone4s to an Pad3? Would you add dates of publications to all of them and compare those?

[drosenstark]

On the absurdly simple/stupid/practical side, I'm doing this. I wouldn't recommend it, but I think it works:

public extension Device {
    public func isWorseThanIpadAir() -> Bool {
        let slowDevices: [Device] = [.iPadMini, .iPad2, .iPad3]
        let slowDevicesOnSim : [Device] = slowDevices.map( { device in .Simulator(device) } )
        let device = Device()
        return device.isOneOf(slowDevices + slowDevicesOnSim)
    }
}

// bridge to Objective-C (there must be an easier way)
@objc(DeviceInfoFromDeviceKit)
public class DeviceInfoFromDeviceKit : NSObject {

    public class func isWorseThanIpadAir() -> Bool {
        return Device().isWorseThanIpadAir()
    }
}

Admittedly, it doesn't speak to the question directly, but hopefully it's useful.

[dennisweissmann]

Okay, this is yet another use case / feature (PO asked about devices being older than a specific one), this is not necessarily equal to their CPU/GPU power. Since you already implemented it, is there really a need to know which device is slower / older than another one? If there really is interest in those questions I'll try to create something (I have an idea that could maybe work).

[drosenstark]

@dennisweissmann personally I'm glad for what you've built and not really looking for more at this time. I'm amused (and this might be due to my lack of knowledge) at how inaccessible this stuff is from Objective-C, but them's the breaks of truly embracing a new lang. And of course, there are workarounds, so all is good.

Thanks!

[dennisweissmann]

@drosenstark Thank you :) The inaccessibility is mainly due to the fact that I use an enum (which belongs to the group of "not so easily bridgeable to Objc" - at least when they don't implement a raw value, which in turn is not possible if you use associated values). To be honest, it was never my intention to make it work from Objc, but again, if there is a need in this area I'm willing to provide a wrapper (or accept a PR that provides one 😉)

[drosenstark]

@dennisweissmann hint taken, but I think the most coherent thing to do is to continue to advance as you are. An Objective-C port would make more sense than a wrapper, since there's not much to wrap, functionality-wise. Which perhaps somebody will do at some point... Regarding enums, I think an API like this is not only useful, but it's a good case to study on Swift...

Keep up the good work, thanks!

[dennisweissmann]

Since there is no way other than manually maintaining the dates I decided to not include this. If there is a strong need for it, we might have to find a better solution.