First of all I want to say that I'm I aware that my question is probably way too vague to answer and may be closed/down-voted. I just hope for some inspiring brain-storming on possible solutions.
Here's the story:
My app was crashing on iPad 2, but not on iPad 1. I've fixed the crash related to unarchiving nib and now I have a very strange problem - my universal app still runs without any problems on 1st gen iPad with iOS 4.2.1 and 4.3.3, but not on (some/all?) iPads 2 with 4.3.3. Unfortunately I don't have an access to iPad 2 with iOS < 4.3.3 to test further and narrow down the problem.
My app has it's main screen displayed by using presentModalViewController. My modal VC is MGSplitViewController (it mimics native UISplitViewController and enhances its functionality). When my VC is presented, only "root view" is displayed and remaining part of screen for "detail view" is just black and empty however the controller is loaded and active (debug logs are printed etc.).
So on iPad 2 I have access to, it fails to display detail view properly, however I've heard from one user that it's fine on his iPad 2 (both iOS 4.3.3). App also works ok on iPhone/iPod regardless iOS version, so I assume it's related only to iPad code of my universal app.
I believe it may be more general issue with displaying views. I've tried to read view property of my detail view, which should force view to be displayed, but it didn't help. It may also be related to IB stuff (the initial nib unarchiving crash only on iPad 2??), but I think everything is wired ok in IB...
Anyone has a slightest idea how to investigate this problem?
EDIT: BTW: My iPad 2 is giving me hard time as it drops Wi-Fi connection very often. Other people are also reporting this kind of "feature". Can it be that it's just something wrong with my iPad 2?
EDIT2: the app is also not correctly displayed on iOS 3.2, 4.2 and 4.3.3 Simulator (via XCode 4), but gets displayed correctly on iOS 3.2, 4.2 Simulator via Xcode 3. Strange, isn't it?
Anyone has a slightest idea how to investigate this problem?
If you'll allow a somewhat vague answer to a somewhat vague question, then yes, I do have an idea.
To approach problems like this in general, bisection of the problem field is a great way to go forward:
You identify the general problem area. Could it be presentModalViewController in your case?
Then about halfway through the code in question, you set a breakpoint/write a message to a log file/play a sound/send a mail/tweet/whatever it takes to verify that your code has come that far without a crash.
Run it and see if your message has been produced.
If it has been produced, the problem is not in the first half, so it must be in the second half (a log message at the end of the identified problem area is useful, too, just to make sure that the crash actually happens before that).
On the other hand, if there is no trace of your log message, then the crash must occur in the first half, and you can rule out the second half of your code for this particular problem.
Now you repeat the algorithm by setting your breakpoint/log message about halfway into the culprit half you just identified.
Repeat until you find the problem. It won't take many iterations.
Of course, the crash may be due to some variable stored at a previous step or in another method, but now you know where to look.
Initially the app was crashing due to unarchiving the nib. I don't recall the exact crash output, but it was quite strange for me that same nib was properly unarchived on iPad 1 with same OS version, so I suspected that the problem lies in xib file... I've recreated the xib from scratch routing everything carefully and - bam! - it started working on both iPad 1 and iPad 2! How come some nibs aren't unarchived in a same way on same OS running different HW???
Related
I am adding the iAd framework to an existing application. The application is portrait only and iPhone only. Everything is running in iOS 6, both in the simulator and on an iPhone 5. However, it fails in iOS 5 both in the simulator and on an iPhone 4. It throws the following exception:
'NSInternalInconsistencyException', reason: 'currentContentSize must be one of the requiredContentSizes; 'ADBannerContentSizePortrait' is not in {(
ADBannerContentSizeLandscape
)}'
The exception is thrown on this line:
iAdBannerView.currentContentSizeIdentifier = ADBannerContentSizeIdentifierPortrait;
I see no way of displaying anything other than a landscape banner this way. I'm assuming I must have something configured wrong somewhere, but I don't know where, and find it curious that it works fine in iOS 6.
Any help here is greatly appreciated! Thanks!
UPDATE: I can't answer this because I don't have enough rep points. But I have it fixed:
Background: I'm using the Kobold2D wrapper around ADBannerView. It's class, KKAdBanner, is the one that is actually calling the line causing the error. It turns out, it was preceding this call by configuring ADBannerView to only allow landscape sizes. This was a configuration issue and I can resolve it.
Of course, now I don't know why in the world it ever worked in iOS 6 at all, but oh well :-)
I've never used this, but from what I'm understanding from the documentation you need to set the #property(nonatomic, copy) NSSet *requiredContentSizeIdentifiers
with all the value that currentContentSizeIdentifier could take.
And your exception is saying that in that NSSet you only have the one for the landscape.
The difference you are seeing could be due to a different default values in different iOS version. (I'm guessing)
Reference here.
Consider the above's IB objects listing. Siblings further down the list should be on top of the siblings listed further up when rendered on the screen.
Under Xcode 4.5.2, everything is ok if iphone simulator 5.1 is used. But for simulator 6.0 the map just covers everything. The same if using actual devices (phones) for testing.
Hope that somebody knowledgeable could help.
Please also add comments if you do not (or do) find such a problem on simulator 6.0. Chances are the problem is related to how my project is setup.
Update :
Have setup a new test project with iOS 6 map view myself. There seems to be no problem with z-order at all. So the problem could relate to my code. Unfortunately, quite a lot have already been written, there wouldn't be enough time to go over everything for the time being. I suspect that it has something to do with the rootViewController property. My project initially followed a older scheme in which rootViewController was not used ...
I dont know if that order is reliable at all -- in the past definitly not and I am not conviced it is today :D. (even though apple claims it :D)
see: IPhone Interface Builder: Z-Index, Z-order of a button, image, ui element, etc?
(the 3rd answer currently. 7 votes)
The problem is solved by calling Window's bringSubviewToFront method. But I believe a better and more proper solution can be found given enough time.
I'm going to implement a view similar to the original photo app in iOS.
I created a customized UITableViewCell which has 4 UIButton in it. And it updates the button's image when the image array of the cell changed.
I worked hard to get the performance really satisfying. However, I found a tricky lag problem about it.
When I use my app normally, the scrolling is very smooth without significant lag. But if I keep the app (simulator) running on the "thumbnail grid view", and switch to other applications in Mac OS. After a while (maybe about 1 minute), when I switch back to the simulator, the scroll view gets stuck. It's hard to scroll it. If I click on something switching to another view and then switch back, everything is smooth again. So tricky.
I also tried the TTRemoteExamples which uses three20 to implement the grid view. It also gets stuck after switching between different applications in Mac OS (not in the iOS).
Then I tried not filling the customized cell with UIButton but 4 images. It didn't get stuck. So maybe the reason lies in the conflict between UITableViewCell and UIButton?
I don't know if it only happens on simulator or have potential performance problem when shipped to device (I haven't got the device to test on).
Apple's photo app will never be like this.
So I'm going to implement it from UIScrollView by myself to see if the problem is caused by the UITableView's mechanism. I still want to know the reason for the lag if anyone has come to it and solved it.
Sorry for my poor English, I hope you can catch my meaning.
Who cares what the simulator does, seriously. Let it fart magical evil fairies that hijack the world's financial system causing it to enter a world of collapse...oh wait, maybe it already did that.
Seriously though, look at using code like AQGridView. It's very stable, provides an interface very much like a tableview, and is used in many projects. You also avoid the nonsense that is Three20 going this route. It's win-win.
But remember, always, and I do mean always, care what your app does on a device, if it isn't doing the same thing on the simulator, don't worry about it, you shouldn't be testing on the sim 99% of the time anyway. Users interact with your app on their devices, not your simulator. :)
Referring to Subclassing UITableViewCell section in Table View Programming Guide for iOS,
I finally solved the problem by implementing my custom mimicking the way from the guide, without adding subviews to UITableViewCell.
Apparently, adding too many subviews, only 4 in my code although, caused the strange problem I mentioned above. So, NEVER ADD SUBVIEWS, especially those with UIImageView's in it, to the contentView of UITableViewCell or UITableViewCell itself.
Instead, keep data's in the customized UITableViewCell, and do every drawing related thing in drawRect, using -[UIImage drawAtPoint:] and -[NSString drawAtPoint:withFont:].
In fact, the Apple's guide has mentioned it. It's careless of me skimming the part.
However, I'm still curious about why, as I mentioned, it only occurs when you switch between applications in your Mac OS, not iOS. I don't know the reason indeed.
This may sound like an odd question, but has anyone noticed that their iPhone apps launch quicker when built for distribution over being built for debugging?
Our app initially launches really slowly when compiling it for debugging / running it through xcode. (on device)
So I then dis-connected the phone from xcode and ran some extremely unscientific tests... (To try and quantify the slowness of the app)
Turned iPhone off then on. Booted my app. Counted to 6 mississippi's.
Closed app, re-launched it. Counted to 4 mississippi's.
Turned iPhone off then on. Booted 'contacts' app. Counted to 2 mississippi's.
Closed 'contacts' app, relaunched it. Counted to 2 mississippi's
The reason I compared to the contacts app is that it's pretty similar, UIWise to my own app. (Although its probably doing a lot more than my app is in the background).
My app is a navigation based app and the root view has the following elements:
UISearchBar
UISwitch
UIImageView
3x UILabels.
Not exactly a tasking amount of elements to initially load, so if there isn't a slight speed increase when building for distribution, I need to try and find the cause of whats taking the app so long to load!
One thing I thought could be the issue is that I'm using interface builder for the layout of my view(s). Could I be taking a loading hit as the initial view de-serializes?
Thanks for any input,
Jon
It's because the Distribution configuration is usually duplicated from the Release configuration in xcode, and has the "Strip debugger symbols" option turned on. Stripping symbols only used in debugging means there's less to load - which makes it faster.
I've noticed this before. I've always assumed that it has something to do with the iPhone interfacing with the Xcode debugger. I'm just guessing here, but I just tell myself it's telling the iPhone about any breakpoints and what to do when it hits them and stuff, among other "stuff". The iPhone is also probably talking to Xcode about keeping stuff in sync in case of a crash or something.
Ok so I've got a really annoying bug in my app. It's driving me crazy and I'm sure it's beyond my skill level as I am learning as I go.
Here is the initial rundown of the bug: A shot in the dark - Application bug
However I have found a way to consistently reproduce the bug (only on the device not in the simulator)
First you create a new Pool and save it. Then add 20 blank time entires into one day. Save it and this is where the problems begin. (when you go back to the main detail view the tableview has put itself out of editing mode with being told to do so). Now if you go back to the day to see the time entries you just added they are still there.
If you go back to the main overall tableview listing all pools and now go back to the day you added the times they have dissapeared.
Add one time and it all saves fine. Add twenty and it doesn't save. WTF!!
Main Menu listing Pools:
Detail view:
Edit View:
Time Edit View:
Add a time:
I'd appreciate any more guesses. But as well as this question I'm offering a bounty of £25 (Sorry I'm a poor student) to whoever is good enough to fix this bug first!
if your interested my email is danmorgz[at]gmail.com
Thanks,
Dan
If you haven't already done so, I'd recommend turning on NSZombie support and seeing if you're using any of your objects after they've been freed. As far as I know this can be turned on in the simulator and on the device.
Most likely, you're failing to retain some object somewhere along the way. When an object gets released and then the memory is re-used for something else, you'll get all sorts of bad behavior, including crashes, or mysterious "disappearance" of other objects.
One thing you can try is putting breakpoints into the -dealloc method of your custom classes. Then you can see where they're getting deallocated from. Most likely though, this will end up being when the AutoreleasePool gets drained, which won't tell you much.
Alternatively, look into using some of the memory debugging tools built into Cocoa.
That document is for Mac OS X, but I think most all of this will work in the iPhone simulator, at least. I know that your bug "doesn't happen" in the simulator, but that really only means that the symptoms are different, and you're not noticing them.
Thanks for all your answers. It's now fixed.
For those interested I'd forgotten to add a cellidentifer in the XIB of my cell subclass.
cellForRow: method was therefore creating a new cell every time. The memory got filled up very quick. It then seemed as though my app was automatically trying to cut the fat by forcing another tableView out of editing mode and not managing my instances properly.
Again it's a memory problem. Isn't this always the case!?!
The clue was a one off 101 error in the console indicating my app was using too much memory. Oh and a slow scrolling tableView.