We’re registering devices for users as part of adding two-factor auth and I want to register them as other apps commonly do, for example, “Apple iPhone 6s”, instead of just “iPhone” or “iPad”. The problem I’ve found is that just declaring into UIKit to get the currentDevice and using the “model” or “name” calls, you only get “iPhone” or “iPad” returned.
Thanks for your answer Jason, i’ve tried it also an fail ;-((
I have an advice from Jeremie Leroy to check the Screensize, maybe that’s a work around for this?!
[quote=376134:@Hans-Jürgen Müller]Thanks for your answer Jason, i’ve tried it also an fail ;-((
I have an advice from Jeremie Leroy to check the Screensize, maybe that’s a work around for this?![/quote]
At the risk of being flamed because I posted a non-Xojo solution…this is the method I use in my Swift programs, and should be easily translated to “Xojo for iOS”
This is Device “type” not “name”
THIS IS NOT XOJO CODE… THIS IS APPLE SWIFT CODE AND IS PROVIDED AS AN SOURCE TO BE TRANSLATED
OR IGNORED AS EACH INDIVIDUAL SEES FIT.
func dev_width() -> CGFloat { return dev_metric(true) }
func dev_height() -> CGFloat { return dev_metric(false) }
func dev_scale() -> CGFloat { return UIScreen.main.scale }
//
//
//
let iphone5=1// iPhone5/SE
let iphone6=2// iPhone6/7/8
let iphone6plus=3// iPhone6/7/8 Plus
let iphonex=4// iPhoneX
let ipad2=5// iPad 9.7
let ipad10=6// iPad 10inch
let ipad12=7// iPad 12.9
//
/******************************************/
/*** Determine what type device this is ***/
/******************************************/
func get_device_id() {
switch dev_height() {
case 0568: device_type=iphone5// iPhone5/SE
case 0667: device_type=iphone6// iPhone6/7/8
case 0736: device_type=iphone6plus// iPhone6/7/8 Plus
case 0812: device_type=iphonex// iPhoneX
case 1024: device_type=ipad2// iPad 9.7
case 1112: device_type=ipad10// iPad 10inch
case 1366: device_type=ipad12// iPad 12.9
default: device_type=999
}
}
Thanks Dave for this. I’s really easy to implement this in Xojo.
You only have to read the Height of the First View in your App and implement the Case Statement.
If you want to Test the Device before any view is opened you have to use Declares (see Jeremy’s solution).
Here’s a link to the encrypted but fully functional class. (Link changed!)
Now with a small “demo” in form of event handlers.
Please consult the descriptions of the class for further information on its properties, events and its method (yes, singular).
I did a quick test with an iPhone 7.
Seems that it works (see Screenshot):
ProximityChanged is also fired, but i don’t know when it should?!
There are no crashes so far ;-))
Thank you, Hans-Jürgen!
Do you have any use for the class? If so, tell me and Ill send you the code without nag message box in the build for your assistance.
Edit: About PlayInputClick: There are several requirements to make that work. I honestly don’t have any use for it so I did not invest more time into it, but basically the method should be ok.
From the documentation:
[quote]To enable a custom input or accessory view for input clicks, perform the following two steps:
Adopt the UIInputViewAudioFeedback protocol in your input view class.
Implement the enableInputClicksWhenVisible delegate method to return YES.[/quote]
Edit II: ProximityChange should fire when the proximity sensor state changes, which should be the case when the user puts the device close to his face.
Once again my ISPs work on his lines leave me (as good as) without Internet connection, so I can only hope for this reply to get posted:
Please see the link I posted above, Jason. I am sorry my current situation does not allow me to share projects completely for free anymore, so if you think it could be useful I would add a real model recognition method like in Erica Saduns extension from your link plus a documentation and offer the encrypted class without nag screen for 5 (yes, not more) or the unencrypted source code for 20 .
Hi Ulrich,
because i learned a lot from your codes in the past, you’re always welcome if you need help for testing.
Yes, i would appreciate to get your class.
By the way, i tested your class this morning on an iPhoneX, same behavior, no Errors ;-))
Great, thank you! I included sysctlbyname to read the real model type ( la “iPhone7,1”) and added an enumeration and a method to translate this value into something like iOSDevice.iPhone6Plus.
Ill send you the project later.
Im happy to buy the source for this class Ulrich and thank you for providing this and all the work you do here on the Xojo forum. Please send me payment instructions when you can.
Just conquered sysctl too so I will add CPU frequency, bus frequency and a few more properties to make the class more usable. Ill address you later (but have an appointment today; it could become Friday before I can reply).
To round this up: Here are the main properties available. There are zillions of parameters available to sysctl, so if you miss something, just let me know.
Just drop an instance of CSDevice.Device on your layout.
Available events are
BatteryLevelChanged()
BatteryStateChanged()
DeviceOrientationChanged() (additional information about the orientation is in Device.DeviceOrientation) ProximityChanged()
You might have to use
Me.BatteryMonitoringEnabled = True
Me.ProximityMonitoringEnabled = True, which is why an open event exists too.
and thank you for providing this and all the work you do here on the Xojo forum. Please send me payment instructions when you can.
