I've discovered a new issue in WatchOS 2.2 large modular complication. I have a work-around, but was wondering if anyone knows of a fix for this?
Install your WatchOS app that includes a large modular complication with an image. Go to the Watch face configuration by hard pressing. Choose the modular layout (second one to the right). Customize to add your large modular complication to the center of the watch face. Hit the home button twice to return to the Watch face. Note that your image only shows as a shadow when holding down the complication.
Return to the Watch face configuration by hard pressing. Change the text color of your watch face. Hit the home button twice to return to the Watch face. Note that your image now shows correctly. You can now change the color back to the original color and the watch complication image will still show.
Anyone else seen this bug in WatchOS 2.2? Anyone have a programatic fix instead of a user work-around as I describe above?
Thanks!
Justin
Related
I built my unity game through Xcode into an iOS device for testing, and the colors look duller and more pastel-like than in the game view in the editor. The exact same thing has also happened on a modern android device. How can I make it so that the colors as seen in the built game better reflect the colors in the editor?
EDIT: I have sent a file to my phone and found out that the phone perceives colors differently than my monitor. I'm sorry if I'm asking for quite a bit here, but... is there any way to make the game look as I intend it to? The fact that I never see exactly how my game will turn out seems kinda... awkward. Thanks.
I'm not sure if you already tried this, but you might want to use Unity Remote for your iOS device, so you can check the color differences in real time instead of having to build it every time.
But other than what the comments said, it sounds like you should try to adjust your monitor's display settings for better color correlation between the built game and the one in the editor.
I am using a simple 2D sprite class based on this tutorial to render PNG bitmaps to the screen:
http://www.raywenderlich.com/9743/how-to-create-a-simple-2d-iphone-game-with-opengl-es-2-0-and-glkit-part-1
Everything worked fine on both my iPhone 4S running iOS 6.1 and my iPhone 5S running iOS 7. Since I updated to iOS 7.1, and on my MacBook Air updated to Mavericks and XCode 5.1, sprites no longer appear on the screen (I just get an empty white screen, which is the color I cleared the background to). When I build the app using XCode 5.1 and run on my iPhone 4S again, it still works.
Does anyone know what could be causing this? Has anyone run into this issue? I am having trouble getting to the source of the problem due to my lack of understanding of OpenGL ES among other things. :) My sprite class is exactly the same as the one in the tutorial.
Let me know if more details/code snippets are required.
I'm not even going to look at the sample code since it doesn't sound like it's the same as your current code. (You said 'based on'.) But I'll tell you how to find your problem.
First, clear to something other than white (like red) as a test.
If the screen turns red you at least know that your view and context and open gl in general is working. That knocks out a lot of possible culprits.
Second.. use the debug tools and chances are it will take you right to your problem. You have to run on a tethered device though and not the sim. Run your app...
Click on FPS in the debug navigator. Then click analyze and be patient. It will take a one frame snapshot of whats happening in open gl. It has to do a bunch of stuff to make that happen and it takes about 30 seconds. But then you'll have an interactive thing that shows you the frame and will let you step through processes and see what code is making that happen, and the frame as it draws each element. It's super cool actually. And probably it will show you an error message (in red).
My guess is that it's no longer loading your sprite images. Something probably changed between 6 and 7 or the versions of Xcode or of OSX. In that case the screen is blank because they're not loaded and therefore not being drawn.
EDIT:
I think the analysis will help find your problem. But to offer more possibilities, in my experience when nothing is drawing it's often one of these things:
An overall OpenGL issue - set your clear color to red or blue to test.
Shader didn't compile - always output shader compile errors so you know.
Bad Shader math or logic - use gl_FragColor = vec4(0.0,0.0,1.0,1.0) or some contrasting color to test. Can you see your structures?
Program isn't getting an attribute. Did you remember glEnableVertexAttribArray
Program isn't getting a uniform. Use the Analyze feature above to check the uniform values to make sure they made it to the shader.
(i'll add more if I think of them)
When stuff does
I need to implement different colors and background images for all UI elements in my app in day and night.How can i implement this other than giving two nibs for two modes.Please help me.
I've done this myself and it ends up being a lot more work than you think to do it properly.
In the end I had to subclass nearly every GUI item to hold state information (I had a night mode and also an intensity) so there was a different base colour used for all the drawing. You also need to have a basic (almost monochrome) theme to the app so that controls look the same in night mode and day mode. Gradients and textured backgrounds dont tend to work very well, for example.
Once you've created your dual mode controls you then need to decide how to let them know about changes of mode - whether to manually set or register for notifications.
This is not too bad for the controls you've listed in the comments, not sure about the map view though.
You can achieve a crappy night mode by using a semitransparent overlay.
I have written a powerful trig calculator, but I want to use the "linen" background. I have been able to implement this in interface builder, but I get a 'yellow triangle' warning in Xcode that says it is not compatible with something like iOS 3.2 and earlier. And I'm afraid Apple will reject it if says that. I want to know the code that I can use to change both the text color (from black to white) and the background texture (from blue and white vertical stripes to the darker linen). I already know a few ways to test and apply info about the users current firmware version, but I'm always open to suggestions. Any help will be GREATLY APPRECIATED!!! I have just read the first 3 answers and duh I feel kinda stupid, that makes sense. But I would also like to know how to do this and make it like a user configurable "setting" just to make it feel nicer :-) thanks
The linen background is a tiling UIColor. You can create a tile color programmatically and apply this tiled background anywhere you would set a backgroundColor. Even on UIWindow.
If you want to maintain compatibility to old iOS versions, replace the built in background "color" (such as linen) with an UIImageView showing an image of it.
Write a simple app, filling the entire screen with the background, make a screenshot, then place it behind all other UI elements.
When I've learned that I have to write some code to make the iphone keyboard go away. I was quite surprised. I was surprised even more when it become apperent that it is just the top of the iceberg.
What are the expected UI behaviors that aren't provided by system OOTB?
Is the list below complete?
The expected UI behaviors:
Focusing next text field when [done] is hit
Hiding the keyboard when background is hit
Using Touch Up Inside to fire a button action. (To give user opportunity to change his/her mind)
Supporting the screen rotation.
Some of that is silly, but some of it has uses as well.
Focusing next text field when [done] is hit
Which field is "next"? If you have a large form with fields both next to and above/below each other, next might not be so obvious. Even if they are in some linear layout, the iPhone would have to work to figure out which one is next. Do you want to wrap around at the end of the form, or dismiss the keyboard, or submit the form?
Hiding the keyboard when background is hit
I mostly agree with you here, though there are a few cases where this is useless. For example, adding a new phone number in the contact app.
Using Touch Up Inside to fire a button action
This one I really don't get. I can only guess that it's designed to allow you to use buttons instead of the touchesBegan/Moved/Ended methods. I guess it could be useful, but I've never used anything but Touch Up Inside.
Supporting the screen rotation
Many apps just don't work in any other orientation, such as games. If you want to use rotation, you only have to add two lines of code assuming you've done your layout well.
I hope this helps explain some of the strangeness. Aside from the keyboard dismissal, I've never really found anything too annoying. The one thing I wish they supported was using the highlight state of UIButtons for the set state. It would be a quick and easy toggle button, but I've taken to screenshotting a highlighted button and using that for the background image of a selected button.
Want a rounded rectangular button that isn't white? Since that one uses a background image, you can't just click something somewhere that makes it the color of your choice. You have to create your own image or you could even use CSS (WTF!?) to do it.
Unfortunately, the iPhone SDK lacks a lot of helpful things one would think would just be there. However, many people have taken the time to write wrappers for many of these kinds of things to help facilitate development - a quick google search into the functionality you are expecting may turn up a lot of useful answers!
For example, you could make the keyboard go away when you tap outside of it by creating a new view when it appears, and placing that view behind any user-interactable views on the screen. When that new view is tapped, it will become first responder and cause the keyboard to slide away (because the UITextField is no longer first responder).
Such a thing could be easily implemented as a drop-in fix for pretty much anything you'd need it for with very little code.
Still should have been included in the SDK in the first place, though!