I've got a rather interesting problem. I'm writing a chess engine using bitboards for iOS 7 which I want to work on the iPhone 4, 4s, 5, and 5s. Up till now I was doing all my testing in the iOS 64bit iPhone simulator, but I decided to run it on my phone and all of the black chess pieces were missing. I quickly figured out that this was because my iPhone is an iPhone 5 and I think it is having some issues with bitwise operations on 64bit numbers. Are there any workarounds I can use to get this app to work on the iPhone 4, 4s, and 5? Or do I have to make this iPhone 5s-only? It would be rather frustrating if that were the case.
Update: After further investigation I have determined the problem to be that, while all of my explicitly stated types are unsigned long long integers, because I store collections of them in nsarrays as object literals, when I call integerValue after calling objectForKey, this returns an NSInteger. However, on 32bit phones, NSInteger is 32bits when I need 64. Is there a way to store and retrieve 64 bit integers in and from an NSArray?
Okay, I finally figured out what was going on. I had been storing collections of bitboards as nsnumbers in nsarrays and using integerValue to get them out. This worked fine on 64bit devices because integerValue returns an nsinteger which is a 32 or 64 bit integer based on the processor. Once I changed all of the function calls to unsignedLongLongValue it worked like a charm.
Related
I have been working extensively testing out the BLE capabilities of the iPhone 4s as well as the iPhone 5.
At the moment, all I have been accomplishing is pulling in the advertisement data from multiple TI BLE keyfobs and populating a UITableView with the kCBAdvDataLocalName, ManufacturingData, and ServiceUUIDs for each respective device.
Basically, as I pull in the advertisement data, I am also pulling in the peripheral's UUID and using this to populate the datasource array for the tableview. (i.e. if a new UUID is found and it is not in the datasource array, add it to the array and use that to retrieve the respective peripheral).
With the iPhone 5 this works flawlessly. However, when I test with an iPhone 4S (and I have tested with multiple) the BLE hardware pulls in NULL UUIDs therefore preventing me from adding any peripheral's info to the datasource array. In my console log, the phone does indeed discover each peripheral, and displays its localname, and manufacturing data, but every single device has a null UUID.
I have also ran my testing app on a 4S and a 5 simultaneously with the exact same code, and it will work on the 5 and not the 4S. So I was wondering if anyone has been having this same issue, whether it was a bug in the SDK or the hardware, or if there is a known workaround? Any feedback will be greatly appreciated, thanks.
The problem in iOS 6 is that the UUID's are not generated until you've actually connected to the device. UUID's are generated on the iOS side for each peripheral, so that's why you'll typically see a different UUID for the same peripheral when using different iOS devices. I usually check the UUID, and then if it is NULL, I will go off of the name. If the name is NULL however, then I do not populate it in the device list. Your other option is to quickly connect and then disconnect from the device. A big time hack, but it will generate the UUID and then be non-null from then on. Supposedly this problem will be fixed in the next version of iOS.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Detecting Color of iPhone/iPod touch?
Is it at all possible to detect the color of an iPhone / iPod - either natively or in the mobile browser?
I'm working with a designer who would love to make a web app respond to the color of the device.
I don't think this is possible. The internal hardware (the "motherboard" keeping all the components together and the components themselves) is manufactured without any knowledge about the final casing. The same is true for the software (firmware and iOS), since all devices get an equal copy of exactly the same software, byte for byte identical, except for any serial numbers that might be embedded in the firmware. It might be the case that Apple uses different device serial number ranges for different casings, yet that is just a wild speculation.
It's like building a car: All components (engine, electronics, etc.) are equally manufactured, regardless with what color the final car will be coated. Actual the car is completely assembled, all hardware and all software, and ready to be used before it is color coated; and up to the last second the final decision how to color it may change.
UPDATE
I did some more investigations on this topic and I found out that the "wild speculation" is not as wild as I assumed it to be. It really seems to be the case that Apple uses different serial number ranges for different device colors. The serial number (as well as similar numbers, like the IMEI of iPhones) are the only parts of the device firmware that are different for each device manufactured.
Apple used the following serial number format in the past (not sure if this is still up-to-date, but it was still up-to-date for the iPhone 4):
AABCCDDDEEE
AA = ID of the factory that manufactured the device.
B = Year of production: 8=>2008, 9=>2009, 0=>2010, 1=>2011, etc.
CC = Week number of the year.
DDD = Production index number, is reset every week, base-34 encoded.
EEE = Model ID.
The interesting value is the "Model ID". The same device generation has different Model IDs depending on their color and the amount of available storage.
I haven't found any complete list of all the possible values, though. And even if there was such a complete list, you still have the problem that you need to keep it up-to-date, since Apple is constantly releasing new models, so the list could be out-dated any couple of months (at least once or even twice a year). Here are some sample values for the last 3 digits of the serial number (EEE):
VR0: iPhone 2G Silver 4GB
WH8: iPhone 2G Silver 8GB
0KH: iPhone 2G Silver 16GB
Y7H: iPhone 3G Black 8GB
Y7K: iPhone 3G Black 16GB
3NP: iPhone 3GS Black 16GB
3NR: iPhone 3GS Black 32GB
3NQ: iPhone 3Gs White 16GB
3NS: iPhone 3Gs White 32GB
A4S: iPhone 4 Black 16GB
A4T: iPhone 4 Black 32GB
I haven't found any sample values for the current iPod generations so far.
There's no API exposed for this.
If this is something you'd like Apple to add, you should file an enhancement request at http://bugreporter.apple.com .
I am wondering how good of an idea it is to start creating iphone applications without actually having an iphone?
I found that there are simulators for iphone...
Are they good enough or is it likely that I might encounter some problems down the road when creating an app?
-I don't have an idea of an app yet.
-I don't have a real iphone. There ARE some handsets in my job's office, though, but I don't want to use them too much.
Thanks! And if you think that it is an okay idea to create apps and test them on simulators, which ones would you recommend?
Bad idea.
You can get a lot of work done but you really, really need an actual device to do your final testing.
Remember that it's a simulator and not an emulator. There are significant differences in performance. Lots of things work fine on your Mac but poorly on an real device. There are, perhaps surprisingly, a number of situations where the reverse is true (i.e., faster on the iPhone). You get better at figuring out these differences after a while, but without working on a real device you'll never know.
If cost is the main factor, you don't actually need an iPhone; you could work with an iPod touch instead.
xCode has an Emulator in itself, so why not? All you need is a Mac-PC
check http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/ios_development_workflow/25-Using_iOS_Simulator/ios_simulator_application.html#//apple_ref/doc/uid/TP40007959-CH9-SW1
Do you have a mac?
iOS SDK has a really good emulator where you can try your apps, and i think if works on it, it should work on a real iPhone.
Consider that the simulator is good enough, to create your app, but it all depends on what you use. For example if you use the accelerometer or the Bluetooth simulator is not suitable to your case. Overall, in many respects is very limited, but to begin with can go just fine.
To use the devices of which you speak, you must have a valid license from the developer and associate devices to your license, otherwise you will not use them (though not with the jailbreak)
the iPhone simulator does not support everything, which is supported by a real device. Some things are impossible to test on a simulator, including but not limited to features/API associated with: calendars, camera, gyroscope, accelerometer, music, ...
The iPhone simulator that comes with xCode is fine for the development of most applications. In my experience the area where it falls down is when you are dealing with stuff that runs in real time such as audio and graphics. The processor on the computer is obviously faster and if you are only testing on the simulator you might not realise that what you are trying to achieve is outside the capabilities of the device.
This could have impact on your frame rate (as you will get a higher frame rate on the computer) and in depth audio with lots of DSP faces the same issues.
If you are developing Line Of Business apps the simulator is probably all you need. Of course you need to test on a device before release, but most of the bug testing and debugging is possible in the simulated environment.
The function
[[UIDevice currentDevice] uniqueIdentifier]
Is deprecated in iOS 5 and I found the solution in this project using the MAC address: https://github.com/gekitz/UIDevice-with-UniqueIdentifier-for-iOS-5
Ok, it is solved. But now I discovery that iOS 5 CHANGED the format of code that uniqueIdentifier return.
In iOS 4.x it is in this format:
93F38DEB-3C0B-5C09-B746-0DFDFDDB297C
Now the iOS 5, the same function return in this format:
93f38deB3c0b5c09b7460dfdfddb297c
Anyone know if the code changed at all? It is different only is format or the code in really different for the same device?
A MAC Address is a (supposedly) globally unique identifier attached to a network interface, though they can be changed in many ways.
The uniqueidentifier that Apple used to provide access to was attached to the device hardware and not changeable, which made it excellent for tracking a user across apps and sessions. That's also the reason Apple is removing it, if I had to guess. Not having a way to track users across apps and sessions increases a user's privacy on their devices.
I wouldn't be surprised if Apple removes access to the MAC Address eventually for the same reasons, so it might benefit you to examine other options for tracking devices.
[[UIDevice currentDevice] uniqueIdentifier] will still give you the same result as before. The project that you link to is not a 1:1 replacement, it is an alternative that gives you a similar solution using a different implementation, thus the two string are different.
You shouldn't use unique identifier on iOS 5. That's all you need to know.
The unique identifier on iOS was always something redundant and a big security threat. Other operating systems don't have unique identifiers and they can live without them.
You can always generate unique identifiers on your server and send them to your device.
You can always generate them from some unique system property (e.g. MAC), using system functions. On iOS you can create a unique identifier using CFUUIDCreate. This identifier is unique across devices and across time (you'll get a different identifier every time you call it) but you can save them (e.g. into keychain).
The code CHANGED!!!!!
UniqueIdentifier is no more UNIQUE!!!
The first format have 36 hexa lenght
93F38DEB-3C0B-5C09-B746-0DFDFDDB297C
The second have 40 hexa!!!!!
Because this, it changed. I don't know if it append more hexa to identifier, but the bigger size changed al all.
Is there any way to simulate CMMotionManager's gyroscope output in the iPhone 4 simulator? CMMotionManager's gyroAvailable seems to indicate that the simulator itself won't do it (which is understandable, given that it doesn't simulate acceleration data either), but I figured someone may have written a simple simulator drop-in for testing a project.
The new phone's are in short supply in my city so far and it would be nice to give things a reasonable work out in the meantime!
This is a pretty old post, but may give you a starting point:
http://ifiddling.blogspot.com/2009/01/dummy2.html