Have you ever encountered a situation where you want to build some record or music app ? But you need to somehow react on a phone call which in many cases break recording or playing in more advanced app (mostly when it comes to CoreAudio) or switch UI in case of call? CoreTelephony is a great library which will help in most of the situations.
To detect phone call on your iPhone or iPad app (this may be the case now when we use continuity) simply use this piece of code:
CUICatalog: Invalid asset name supplied: (null), or invalid scale factor: 2.000000
This error may happen when you try to load UIImage and your asset string is nil. For now this will not crash your app but may case some future problems. This may also lead to some UI inconsistency. To track down issue like this we need to set symbolic breakpoint:
Internationalizing the users interface in Xcode is really easy. Xcode separates all the texts from your views in a dictionary. However, we can make it better, using extensions and @IBDesignables. How handy would it be, if setting localized strings were as easy as the following?
There are a lot of tools in Xcode that help us during the debugging process. No doubt. Breakpoints for example are these tiny signals that tell the debugger to temporarily suspend execution of program at a certain point. My favourite type of breakpoints are the exceptional ones. Exceptional breakpoint is this guardian that pauses the execution of our program, as soon as it knows that things are going to be pretty bad.
When this happens, we are usually presented with all the stack trace and in the blink of an eye we know what happened that was bad. This is the usual scenario.
But sometimes we see things like that:
1
*** Assertion failure in -[UITableView _endCellAnimationsWithContext:], /SourceCache/UIKit_Sim/UIKit-3347.44/UITableView.m:1623
Which with tells us literally nothing, when we are not familiar enough with the code that we are working. We get sterile error message that tells us that we are doing something wrong with UITableView animations, but it’s all we get out of the box.
However, there is a way to get more detailed info. The thing that we can do to know the issue of our crash is this:
Go do debug navigator
Select objc_exception_throw frame
Go to console
Type in: po $eax when using simulator or po $r0 when debugging on a device.
This way you get more detailed error description which tells you a lot more about the place that you should be looking for to find your mistake.
iOS Simulator has a feature that slows animations, you can toggle it either by pressing ⌘T or choosing Debug > Toggle Slow Animations in Frontmost App. It’s very useful, but what if we want to do the same on device? It’s easy, fast and simple.
CALayer has a property called speed, which is a time multiplier. This means that if we have an animation with a duration of 1 second, and set the layer’s speed to 2, it’ll take just 0.5 seconds to finish. The best thing about it is that it’s related to the parent layer. So when we change the speed of a particular CALayer, every child layer will be affected. So, if we change UIWindow layer speed, every CALayer in our application will perform animations with that custom speed value. That leaves us with this two extensions: