is not that hard, you just need to copy - paste the #define functions in your extension, and create functions in the namespace calling them and return the result, so you can call those functions from haxe with Lib.load().
Ah, I must have seen an old copy of Cabilities.os, which (at the time) was always three capital letters, or perhaps it’s different if you’re in Flash than if you’re in AIR
Would be happy to have help deciding how to do this string in a way that feels consistent, but also accounts for our additional platform targets
I would not recommend an extension – you might notice that I made the default extension template in a way to mirror the architecture of how the older NME/Lime 1 legacy code, and in ways, the newer Lime 2 code, work at a native level, in order to make it simpler to integrate working extensions into the core, or to help extension developers understand how to contribute to the project.
Some things make sense as an external extension (like AdMob) but other things (like the device type) are things I think we should put in the core
For other platforms Cabilities.os returns info the same way it’s described at Adobe Docs.
But for iPhone/iPad, it adds extra info, like device model.
Can we have something like Capabilities.device?
So, Cabilities.os returns OS, “Window 7”, “Android 4.4” (Adobe AIR returns something like “Linux 3.4.83”), “iOS 8.2” and so on.
While Capabilities.device will return “PC”, “Mac”, “iPad2”, “Kindle Fire”, “Samsung Galaxy 4”.
Answering to my question, a dirty fix could be getting screen WIDTH/HEIGHT aspect ratio and checking if it’s >=1.5 - then it’s iPhone, otherwise it’s iPad.
I would prefer not to add anything to capabilities, but we can devise a Lime API that provides a sensible way to get the device hardware name, if we can decide what to call it and where to put it, perhaps under lime.system somewhere
perhaps lime.system.DeviceInfo with things like DeviceInfo.operatingSystem or DeviceInfo.platformName, DeviceInfo.model perhaps
I’m not sure if screen resolution or RAM should be in here, maybe, but we not only want the full current display screen resolution, but also support for reading multiple displays (or no displays), supported display modes, etc, I’m not sure where to put that. Then there’s RAM that’s total on the system (if that’s possible), total usable, total used currently, etc
for (i in 0...System.numDisplays) {
var display = System.getDisplay (i);
trace (display.id);
trace (display.bounds);
trace (display.supportedModes);
trace (display.currentMode);
}
I think you can also:
var display = stage.window.display;
…to get the primary display of your current window (in case of a multi-monitor setup)
EDIT: As for a device name, that isn’t available in Lime at the moment, I’m not immediately sure what we would return on different platforms (not sure most operating systems expose this?)
This is a old post but for those googling into this. As long as you know that you are on IOS you can always check if it is a IPad by the aspect-ratio. iPads always have a 4/3 aspect-ratio, iPhones do not!. So for haxe a easy runtime way to figure out if you are on iPad or not could be something like this.
class Apple {
// Boolean for IPad.
public static var isIPad(get, null):Bool;
static function get_isIPad():Bool {
#if ios
// IPads are ALWAYS 4/3 aspect-ratio!
var min = Math.min(openfl.system.Capabilities.screenResolutionX, openfl.system.Capabilities.screenResolutionY);
var max = Math.max(openfl.system.Capabilities.screenResolutionX, openfl.system.Capabilities.screenResolutionY);
return ((max/4*3)==min);
#else
return false;
#end
}
// Boolean for IPhone, or better said NOT IPad. :D
public static var isIPhone(get, null):Bool;
static function get_isIPhone():Bool {
#if ios
// IPhones are NEVER 4/3 aspect-ratio!
return !isIPad;
#else
return false;
#end
}
}
Now Apple.isIPad should only be true only when on a iPad, and Apple.isIPhone should only be true when on a iPhone.!