I'm a bit confused with Corona scenes.
I'd like to have my main menu (which I dont want released or purged) push to a level when a button is tapped.
So far I can achieve that with storyboard.gotoScene("level1")
However, once level1 is done, I'd like to go back to the mainMenu scene as it were (I use a scrollview whose position I keep). I don't want to recreate mainMenu.
How exactly should I be doing this? Does gotoScene automatically release my existing mainMenu? Thanks
You would simply go to the menu scene using gotoScene("")
Keeping in mind that Corona will auto purge your scenes if it feels that is is needed.
By default, storyboard will automatically purge (e.g. remove the
scene's display group, while leaving the actual module in memory) the
least recently used scene whenever the OS receives a low memory
warning.
If you would like to manage the purging of scenes manually and disable
this auto-purging functionality, you can set
storyboard.disableAutoPurge to true. The default value is false.
To turn off autoPurge:
-- turns "off" auto-purge on low memory functionality
storyboard.disableAutoPurge = true
This will prevent Corona from removing your scenes automatically, which means you are left in charge of this task.
Related
According to Apple for the apps that support the background mode the views will continue to update even if the screen is in always on mode.
I can confirm this to be correct, but the update schedule is underwhelming. I would prefer the view to be updated every second, so I have created the TimelineView that declares to be updated every second. Clearly this is just a declaration and the watchOS may not update the screen that fast, actually I can tell that in reality it happens much slower.
After trying I am not sure if there are any benefits in this approach comparing to no TimelineView at all. Does someone have any data/insight into this?
It seems like there should be a simple answer to this, but my searching doesn't turn up an answer.
I have a few controls in a UIViewController that resides in a Container View within another UIViewController. When a user taps one of the UITextFields, all the controls in the container view controller move up to accomodate the keyboard being present. I DO NOT WANT THIS ACTION. I simply want them to stay put. I've tried a lot of the obvious solutions, but none are satisfactory.
I have tried some solutions to counteract this behavior, including catching the Notifications for keyboard events and trying to counteract the animations. I do not want a quirky anti-animation. I simply want the controls to stay put when the keyboard is dispatched.
It seems like nowadays (with iOS 6.1) there should be a way to do this just with IB, but I do not see one.
Edit: For example this post: disables the animations, but the controls are still relocated. I do not want them to move at all. Moving them back to their original location is not ideal, rather disable them from moving at all.
It seems like back in iOS 4 or so, you had to move the keyboard yourself, manually. Now it's done automatically, but not always desired. I just want to disable it.
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!
I have this game where balloons are coming from bottom and player has to pop them by tapping before:
Time runs out
OR
10 balloons leave screen unpopped e.g. game over.
Every level is same , only thing changes is number of balloons.
For this i have the following view controllers:
MainLevelVC: The first one, to which the BaloonPopViewController connects when user selects to play game.
LevelIntroVC: This shows an intro screen for 2 seconds for each level, basically an image is loaded based on level count e.f. 1.png, 2.png etc
LevelOutroVC: similar as before but shows an outro screen. 1_outro.png etc
LevelPlayVC: This is where game logic is actually implemented. a link to Main menu (Play, high scores, etc) exists here.
I have done it for one level, there are global variables (basically implemented via a singleton) in MainLevelVC that define max number of balloons allowed to leave screen unpopped (leftBalloons) and number of balloons in the next level (balloonCount). At the end of every level i have to increment the LevelCount global variable as well to facilitate the Level*troVC to do their task easily.
What i am confused about is how to proceed at the end of every level? after i show the LevelOutro for that level increment/decrement any values that i must, how can i reconnect back to LevelIntroVC to start next level?
How are you displaying the view controllers in the first place? If you're using a navigation controller, you can just popToViewController:animated: to get back to your intro VC.
Otherwise, you can probably just keep stacking intro VCs on top of outro VCs in the same way you're currently transitioning from intro VC to play VC to outro VC. Just be careful of your memory usage - release any "old" view controllers you're no longer accessing as soon as you can.