I've been debugging a complication of mine for several weeks now, and I am completely unable to figure out what runtime behavior (crash? hang? out of budget?) causes it to go completely blank.
I've left the exact same complication running overnight in the simulator as on my real watch, and my real watch (Series 2) will go blank yet the simulator catches no crashes or other failures that I can tell.
Does anyone know what going blank means for a complication on watchOS?
Sometimes it’s just watchOS, I think. When was the last time you power cycled the Watch? Also, have you looked at the Watch log files for your app? In devices from Xcode, you can view all the logs. See if there are any crash logs for your app on the Watch.
Related
X-Post from here, for exposure: https://community.onsen.io/topic/222/monaca-ide-console-log-never-appears
Odd question, but only once while using Monaca IDE has anything ever shown up in the console.log portion of the IDE itself. It only occurred when I had a device synced via the debugger. I have since tried syncing it and I never get the device to show in the drop down box, it usually says unknown device /www/html/…
Now, do know that I have put several console.log(‘test’); lines of code to try this out and still no success. I would think that the IDE’s console area would show the log operations from the emulator and not from the device debugger as it has its own log that is view-able on the device, but this apparently isn’t the case. Is this correct or am I just really missing something simple here?
So this isn’t that big of an issue, but I figured out the problem. Basically, I keep the Monaca IDE tab open in Chrome all the time (I work via my laptop remotely). When I come back after a long absence (several hours, I don’t know what the time out is), the bottom section in the console has the Chrome error showing, like that page timed out. The IDE is still there, just that section is grayed out.
So to fix this, I would just refresh the page. The section pops back and all is good EXCEPT I just figured out that it is at that moment when the device connection no longer works. I can still click Run on Device and it works - syncing with the device - but the console.log no longer shows up. In order to get that back and working, you have to close the tab and reopen it; then everything works.
I searched StackOverflow and it doesn't look like many people are having this problem, but for me, this happens very, very frequently. Maybe not every time, but perhaps every other time.
Once I try to build and run the app, Xcode crashes, and in a strange way: it just disappears with no error messages, no suggestion to report the problem, nothing at all. This happened with Xcode 6.0 as well. It doesn't matter whether I am running the app on a device or on an emulator.
To prevent the crash, I need to Product > Clean. If I do this clean each time before running the app, crashes do not happen, but once I forget to do that, Xcode can crash any moment.
I don't think I ever had this crash with an old project, but it keeps happening with the project that I started in Xcode 6.0.
Because of that, iOS development is becoming for me quite a painful exercise, similar to pre-Android-Studio Android development.
Is it just my problem, or maybe someone else is having it? Maybe someone has a solution?
I just started running into the same issue and found a workaround for it. Found it to be an issue with building when Xcode is full screen. Seems silly, but so far exiting full screen mode has worked for me. I've been able to re-introduce the issue after building full screen a few times, and then instantly fix it again by exiting full screen.
Yeah, it's not that the app is crashing, it's just that the click is triggering the red close window button behind the red button (yeah, seriously). You'll notice, Xcode is still open, it's just that the window has closed. You might also notice that sometimes when you click "stop" in full screen mode, it switches to non full screen. Again, the tap is passing through the run/stop buttons to the underlying window controls.
So dumb.
I solved it using 'cmd + R' instead of clicking the run button
Just today I started noticing an "X" symbol in the bottom right of my live tiles, see picture.
I'm a little concerned, as I'm currently in the certification queue, that this means I've missed something from the package - a default badge image, for example. Do you know what this means?
The answer appears to be that your developer licence has expired!
when I tried to build something I got a popup alerting me to the problem and asking me to log in to my account again. At which point I was given a new developer licence, was able to build again, and all the crosses magically disappeared! :o)
I imagine the only reason your apps were still working was because they were still in a suspended state so weren't going through a proper launch cycle. The X means it won't run anymore as you don't have a valid licence.
I have put NSLog points throughout the launch stuff of my app, including delegate methods. The last one I can find that gets hit, gets hit about 2 seconds before viewDidAppear. How can I find out where my app is slowing down?
You can use the Time Profiler tool on Instruments for determining how long each call takes.
In xcode you can use Instruments tools. It's really useful when looking for memoryleaks, performance issues etc.
Trigger the problem while using the tools.
See the Apple link for getting started with Apple Developer tools.
Apple Developer Tools
Best,
In your question, you note that you're using NSLog statements, which can be useful, but at the same time setting breakpoints can be even easier and provide more insight to your problems. Try adding a breakpoint in the tray on the left side of your code. You can also set conditional breakpoints to analyze the code that is being stopped on.
Combining the use of breakpoints with Instruments can greatly help you understand your apps performance and possible problems. You can find the Instruments application in Xcode 4 under the Xcode menu. Click Xcode -> Developer Tools -> Instruments. You can also Profile your app with instruments by clicking and holding on the Run button and then selecting Profile:
You should then see a screen like this:
Select Time Profiler to determine how long each call takes. Then click Profile
Is there any benefit of using COINIT_MULTITHREADED in a DirectShow application? For now it has given me some troubles, but I am not sure if using CoInitializeEx(NULL, COINIT_APARTMENTTHREADED) is the right fix for the problems.
The full story:
I have a pretty straightforward web camera capture application with ability to choose the capture source and call the device manufacturer settings through OleCreatePropertyFrame.
My app runs pretty stable, no memory leaks, I can switch between devices without any problems (I completely rebuild DirectShow graph each time when user chooses device).
But there is only one problem after showing the property page of the capture filter. If I just show it and close without changing anything, all continues normally. If I change any setting in the property pages and then close the property frame, also everything continues seemingly normal .. until the next time I change the device and rebuild the graph. The previous graph gets destroyed normally, no errors, filters are being removed and released correctly. And right when I create a new graph and call graphBuilder->SetFiltergraph( pfg ), my app crashes with some weird access violation errors insde of Kernel32. But if I change COINIT_MULTITHREADED to COINIT_APARTMENTTHREADED, this error disappears.
So is that COINIT_MULTITHREADED a real problem of my application or maybe there is some other monster hiding somwhere? Has someone experince with it?
Any thread that creates a window must be STA. Both user32 and gdi are fundamentally thread-unsafe.