I'm trying to make my Canvas scalable regardless of screen size. I made it to be scalable across the screen but when it is hidden and called it is not scaled for some reason. I actually call it in code and it shows up when needed but it is not scalable but when I display it right away it is scalable.
Expected position (is displayed normally when I do not hide the display):
Actual position (when my display is hidden and is displayed at the button pressing):
How to make it scalable? I've searched for all possible solutions but I could not find an answer.
These are the settings and hierarchy:
These are parent settings (main canvas):
I am not sure why CanvasScaller is not enough for you. I've never faced a case where I had to implement my own scalling, you should probably check CanvasScaller and use that, but anyway if your layout is not getting recalculated instantly you can force that by using
LayoutRebuilder.ForceRebuildLayoutImmediate(rectTransform);
Related
This is my first time working in and with xCode. I am coding a drum pad but am struggling with the User Interface.
Right now i have two views each containing a 4x4 button grid. The first one is for "triggering" the audio samples once a button is pressed. The second one contains a set of toggle buttons used to control a step sequencer.
The app itself is working fine. But im not sure how to build the interface in 'good fashion' So far I have used Interface Builder to create the grid.. set up the constrains manually so that the pads adapt to the device width, and stretch evenly across the screen.
The thing that makes me insecure is how laggy the interface builder runs since i have created these constrains.. might this also affect App performance and launch time?
So i looked up ways to create the grid programmaticaly and came across UICollectionViewwith its reusable cells it seems to fit my use case.. but it also seems a bit like overdoing it.
Its for school, due date is coming closer and somehow i am stuck since days at this point. So could someone please point me in the right direction... how would a modern ios developer set up this grid.
thank you very much
You can use Stack View for the solving of this issue.It could be filled by buttons programmatically or just from storyboard.
This is example form the storyboard.
And this how it is looks at the emulator.
I have two pages, first page I have a ScrollView control and the other page I used RepeatBox control.
My problem is the ScrollView page scroll is smooth, But the RepeatBox page scrolling is not smooth (i.e. flickering while scrolling).
Could any one help on this? Thanks in advance.
Performance of repeatbox can change according to the objects you used in it. Because it is drawn with rowRender event, it can take more time with different objects. Also, in some old devices, especially for Android, you can see these kind of performance differences in applications.
Maybe you can test with other devices, or you can test with more simple project in order to see if it is always flickering or not.
The problem comes with all images on the visible screen are opening again from the local storage by rowRender method. In the native RepeatBox after image comes on visible area are stored and not again opening from local storage and creates performance problem.
Currently I'm trying to edit a login screen for a web based application. As of now, I have the login prompt (user & password) at a particular place on page so that it corresponds with the background image. Right now this image is set to 1024x768.
What I was wondering, is there a way to have the background automatically scale depending on users own resolution while have the login appear at the correct location? I'm not sure if this is possible but thought someone might have some advice.
I've made a jsFiddle solution that can come in handy:
Click here to see background-resizing at work
It works with jQuery, and I've commented most code so you can understand how it works. You compare the aspect ratio of the image and the browserwindow, look at the difference and then resize the width or height, based on how the aspect ratio's are comparing. The css is also worth a look.
I tested it in Firefox and IE(7/8), but jsFiddle resizing is a bit buggy in IE.
Good luck!
Update:
I've made an updated jsFiddle here.
In this scenario, the message box (in your case the loginbox) is positioned absolute with percentual offset to the top and right. I also gave it percentual width/height, although that might not be neccesary/wanted. But you can tweak this to see how the box behaves with different window sizes.
I'm trying to workaround a long-running bug in Apple's SDK here, but I can't see how to achieve it without huge amounts of code.
Here's the bug:
Create a view.
Put another view inside it, with an origin ANYTHING except (0,0).
Configure the subview to resize to fill
...then, at runtime:
4. Set the superview size to zero
5. Set the superview back to ANY non-zero size
BANG! Apple's SDK goes haywire, resets the origin of the subviews, loses all ability to tell up from down, etc. (seems like the programmer "Forgot" to include a variable to record what the spring/strut-size was before it went to 0).
I've heard this bug has existed in OS X for 5 years or so, and Apple still hasn't fixed it. What I would like is some way (any way!) of working around it, without re-writing Apple's entire springs/struts system and implementing it properly, without the bug. Unfortunately, I can't even find the original references to the OS X bug that someone showed me previously.
EDIT:
...I have a resizing "drawer" at the bottom of the screen that has to shrink to small height. The problem is subviews "collapsing" all down to origin 0 (amongst other things) at the drop of a hat (technically: they're reducing their origin.height, but not re-increasing it).
The best solution I have found is to limit your minimum window size so that none of your views can ever hit zero size.
EDIT: an hour later, the collapsing behaviour has returned, without me touching the source files. I'll use source-control to double-check, but I believe all that happened is I added other files to a different part of the view-hierarchy and re-built. Argh!
(what follows SEEMED to work, but is now failing again, in the same way)
Hmm. So, I had two UIVC's on one screen. Refactoring so that I only had one made the resizing bug vanish. It seems to be a bug in the UIVC layout code.
NB: I had the idea this might be a problem because I know Apple currently advises you to only have one UIVC on screen at once with iPhone, even though this means you have to ignore their MVC architecture for complex apps. So, technically, they warn you away from this. But, at the same time, I'm now unable to use the MVC stuff for this code.
The following worked (for my current example - may not be universal!).
HOW:
If you're adding any UITableViewController instances ... give up. You'll have to re-implement that class yourself
Find my subviews that were in UIVC instances, and change the extended class in the UIVC header from "UIViewController" to "NSObject"
Move all code from viewDidLoad to init (remembering that "init" has special rules about first few lines etc)
Replace the instantiation of that UIVC from "[[vc alloc] initWithNibName:nil bundle:nil]" with a plain "[[vc alloc] init]"
Another potential workaround (that works in my current situation):
The only View I have right now that MUST have a non-zero origin and MUST resize-to-fit is a UITableView.
Apple has a special feature of letting you put any view as a "table-header".
So ... I've taken all my other components, stuck them in a large view, and made that the table-header view.
The downside is that they now scroll off the top when you scroll the table, but it allows me to give the table a zero-origin, working around the SDK bug.
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!