Problem: I can't get one instance of iAds to be viewed in 5 viewcontrollers.
I used the iAdSuite example from dev.apple.com to integrate iAds into my app. All is fine until one uses the back button to go back a page within the NavControllerstack. The Ad doesnt reintegrate into the view.
One logical approach seemed to me to load up one instance of the adbannerview into my main window in my AppDelegate:
[self.window addSubview:MainView];
[self.MainView addSubview:NavController.view];
[self.window makeKeyAndVisible];
MainView takes the full window but is set to stretch up when the adbanner is loaded.
I seem to be doing something wrong because the navcontroller view seems to always take up the entire screen.
Question: How can I succesfully implement iAds in my rootview? (Or succesfully migrate iads around)
Could you keep a global reference to the iAd Banner and call [adBanner.view removeFromSuperView] followed by [theViewThatYouWantToDisplayAdOn addSubview:adBanner.view]
Related
I've created an AIR application and it seems to be working fine but when I drag the title bar to move the native window it shakes violently and have seizures while it's dragging about.
FYI It does eventually end up where I want it to be when I stop moving the mouse.
I'm using Flex 4.6 and AIR 3.6 on Mac OSX 10.10.5. It's a s:WindowedApplication I'm also using the DragManager on a list in part of the application if that matters but it is not enabled until the user clicks into the list and moves more than a certain number of pixels.
Here is my descriptor file minus name and version info:
<application xmlns="http://ns.adobe.com/air/application/3.6">
<initialWindow>
<autoOrients>false</autoOrients>
<fullScreen>false</fullScreen>
<visible>false</visible>
</initialWindow>
</application>
On initialize I run this:
protected function initializeHandler(event:FlexEvent):void {
width = Capabilities.screenResolutionX * .96;
height = Capabilities.screenResolutionY * .9;
nativeWindow.x = (Screen.mainScreen.bounds.width - width)/2;
nativeWindow.y = (Screen.mainScreen.bounds.height - height)/2;
}
UPDATE:
I removed the main view component so it is an empty application and it drags around smoothly.
UPDATE 2:
I added the main view back in and dragged around step by step along the way. It appears to start happening when I've loaded a second Application (called a sub application) into the main application. I'm not sure though.
This happens in numerous number of my applications. It is probably because I have a component inside my application file set to size to 100% of the application. But I have not verified this on all my apps.
The solution is to resize the AIR app. After I resize it it works fine. I can drag it around and it works as expected. I think this is an AIR bug.
I'm failrly new to LibGDX and I'm running into a problem.
I'm building a classically styled RPG/Adventure game in which I'm using a TiledMap(-Renderer) to create the map. I've followed different tutorials but can't get it to work. (last one was DPG's: Full working example link)
What I need, is a column of buttons on the right side of the screen (implemented that through ImageButtons). One of these buttons lead to a settings-kind of screen and another one should lead to the game map. Under a ClickListener of the button I've added DPK's code of
MapHelper map = new MapHelper();
map.setPackerDirectory("data/packer");
map.loadMap("data/world/level1/level.tmx");
map.prepareCamera((int)stage.getWidth(), (int)stage.getHeight());
map.getCamera().update();
map.render();
The MapHelper class is an exact copy of dpk's, only change above is the setting of the width and height of the camera. Any suggestion what I'm doing wrong here?
I don't think you want to invoke map.render() in the ClickListener callback. That would mean the map is only rendered when you click, and then not re-rendered (generally everything gets re-rendered on every screen re-fresh).
I think you need to track the map in your application class, and in the ClickListener callback you need to set a flag or somehow "enable" the map (perhaps setting it to something other than null). Then in the application's render() method you can check to see if the map should be rendered or not, and render it if so.
Specifically, move the calls to prepareCamera, getCamera and render out of the ClickListener.
I have a uiNavigationController and two viewControllers. The problem I am having is the views are being generated in portrait size even though I want them in landscape!
Here is what I am doing:
1) Creating an instance of view1 and adding it to the uiNavigationControllers stack. This is performed inside the applications delegate didFinishLoadingWithOptions(...) method.
2) view1 has a button that when clicked creates an instance of view2 and pushes it onto the uiNavigationControllers stack.
This appears to work fine apart from the fact the views are being created in portrait format. I was going to manually force landscape by using transform methods once I create their instance but this feels really hacky.
I did speculate that this has something to do with the "shouldAutorotateToInterfaceOrientation" method, but this is set for landscape in all viewControllers.
I am royally confused.
Question 1) How on earth do I solve this, is the 'hacky transform' approach the only way?
Question 2) Is this the correct way to be using a navigationController - I am new to iPhone programming. All I want are two landscape views that I can click between and this seems to do this aside from the landscape bit ^^.
I found the answer for this problem.
The navigation controller DOES inherit the shouldAuthororateToInterfaceOrierntation method for each of the views inside its stack, I however made a mistake :)
After adding the navController to the main window I had not deleted the part where by default it adds the a rootController view to the main window. There was some kind of conflict which stopped my navigation controller working as expecting - removing that line fixed everything.
I've noticed that if I create a UIViewController-derived class programatically (without using a nib) to be displayed with a call to presentModalViewController, as the view slides in, it's actually transparent by default until the view covers the entire screen, after which point the 'opaqueness' seems to kick in and the view beneath the modalview is no longer visible.
If I create the view using a nib, it slides in as you'd expect, fully covering any views beneath with no transparency issues.
I noticed that the Apple examples tend to use a nib-based view for ModalViews, but wondered why. Perhaps I'm missing something.....
It was down to a foolish coding error on my part.
I realised I'd copied/pasted some code from elsewhere into my ViewDidLoad
self.view.backgroundColor = [UIColor colorWithRed:0.6 green:0.4 blue:0.2 alpha:0.3];
I'd set a value of 0.3 for alpha.
Set it to 1.0 and transparency issue goes away...
Problem solved
Just looking for ideas on something (tried to make this description shorter but didn't succeed):
I want to be able to update an swf instantaneously - by that I mean don't refresh it until the entire new version of it is completely ready and then immediately replace the existing contents in the browser window (as opposed to the existing page being removed, followed by a gray screen, followed by incremental reconstitution of the page).
Actually i have a method to accomplish this now: Everything on the swf is on a canvas, so I create a new canvas behind the scenes, repopulate it with all the new controls, and then when everything's ready, display this new canvas and destroy the old one.
But the strange thing is, it actually takes twice as long to build the new page this way than if I had just put the new version of it in a seperate swf on its own web page and displayed the new web page. (So 2 seconds vs. 1 second). But if the new version is on its own web page, then you get the existing page disappearing, being replaced by a gray screen, followed by an incremental build of the new page(an incremental build only taking a second - but still not the effect I'm going for.)
Basically what I'm looking for is to create a new SWFLoader containing the new version and then say, "when a certain signal is sent by the application in the new SWFLoader, replace the entire existing swf application in the browser window with the content of this new SWFLoader."
Or, if there were even a way that I don't know of currently to do all this with just html (i.e. replace an entire html page in the browser window instantaneously only when the new page is completely ready) then that would be great also.
You seem to be suggesting the use of a shell/preloader, e.g. a minimal SWF handling loading /unloading/transitioning of external SWFs. I think you pretty much explained it your self actually :)
Things to keep in mind (from the top of my mind):
Make sure you have full control over starting/stopping processes and free up memory before unloading the old SWF. A good practice in this case is to share a common interface for your document classes to be accessed consistently by the shell. (e.g. enable / disable / scale)
Be careful using the same, or identically named classes since the ones loaded first won't get overridden.
I came up with a scheme where my app clones itself in a new SWFLoader in the same app. This was noticably faster (i.e. just recreating the entire reconfigured app in a new SWFLoader rather than reconfiguring the already loaded app.) Probably has to do with the fact that FP optimizes the load process for new apps.
Basically the very first time my app runs, it just creates one child SWFLoader that will hold the actual app. Then if that app needs to be reconfigured, a new child SWFLoader is created and added as a child at the top level with 'this.addChildAt(0)'. (So its temporarily obscured by the old SWFLoader.) When the new SWFLoader is finished loading, it removes the previous SWFLoader by caling 'this.parent.parent.parent.parent.removeChildAt(1)'. Removing the old SWFLoader makes the new one visible immediately. I have to string those parents together to acess the top level parent of both SWFLoaders from the actual application runnning in the new SWFLoader. (The application in an SWFLoader is four parents removed from the parent of the SWFLoader). I guess no one understands what I'm talking about but at least I solved my problem.