In my application I use a TabBar with several items on it. After some time of using the application randomly happens that the items disappear. I use scrollView that is hosted in a main fraim and this view opens several modal dialogs - one of them is fullscreen. I cannot see the reason why the TabBar items disappear. Any ideas?
Storing them in a "local" field won't help. You need to store them in a member variable of your class. There needs to be a reference to your tab bar items somewhere that exists the lifetime of your application to prevent the GC from collecting them.
The reason you wouldn't have to worry about this in WinForms, is you would call Controls.Add() (or WPF Children.Add()) which adds controls to a C# list internally. MonoTouch directly calls Objective-C for most things, which isn't GC aware.
Related
I have a control in one of my storyboard that I copy in a lot of screen and even projects. It's just native controls with stack view, scroll views, labels, etc placed with auto-layout already wired together.
Is there a way to add this into the Object Library in Xcode so I can just drag it from there onto my storyboard and still see all the native controls? I want to be able to drag and drop other controls into the stack view and even modify it from there within IB.
I do not want to do this programatically because I want to continue using Interface Builder for my custom control.
s there a way to add this into the Object Library in Xcode so I can just drag it from there onto my storyboard and still see all the native controls?
No. The usual strategy is to keep it in a xib file (so you are using Interface Builder to construct the view complex) and load the nib programatically to get at the view and put it in the interface at runtime. To some extent you can automate that programmatic process by means of a view subclass that loads its own content from the nib.
Or, if this view has different manifestations in different contexts, you might just have to use copy and paste of some template version (presumably you’re already doing that).
If I am NOT using NIB/XIB files for my UI then where is it best to place/launch the code that initialises my GUI?
The logical place seems to be the App Delegate's applicationDidFinishLaunching: method...or perhaps there is a window controller or delegate that should be used? Or perhaps in the main.swift file?
It all depends on what your program does and the preffered order of operations.
If you want to call a view controller right away then you can put it in the applicationDidFinishLaunching: method like you mentioned but you could also put it in methods of other classes if you want something some operations to run in the background first.
The main thing to remember is that you want the user to feel like your application isn't frozen. So add a progress indicator or such if it will be a longer loading time than average. Apple requires a loading screen for all published iOS apps so that is a perfect place to put a loading image.
I have a problem with accessory views on NSSavePanel and NSOpenPanel.
Sometimes, (very often) when I open one of these panels the accessory view does not work (the view is shown but controls seem disabled).
I'm using this code to show the panel:
[openPanel beginSheetModalForWindow:appWindow completionHandler:openPanelHandler];
This only happens when app-sandbox is enabled.
After much testing I found out that what was happening was that the view was being misplaced (not attached to the panel).
When I open Mission Control and move the mouse pointer over the app windows I noticed that an "invisible" window hilighted and when select it I can take control over the accessory view (all controls work) but it appears detached from the open or save panel as shown on the screenshot.
I tried to create a new app just to test this behavior but was not able to reproduce it, so I suppose that has something to do with my app.
Any hint of what I may be doing wrong?
I don't want to code everything from scratch just to solve this issue.
Edit
Just a side note, when I close the window, just before the window close the accessory view flashes with the correct values for the controls. It appears that the application does not add the view in time for showing the panel.
Update 1
I subclassed the view that is used as accessory view and noticed that the
- (void)viewWillMoveToSuperview:(NSView *)newSuperview
is called, but
- (void)viewDidMoveToSuperview
never gets called even when the view is shown correctly, is this the normal behavior?
Update 2
I confirmed that - (void)viewDidMoveToSuperview should be called, on the test app both methods are called.
I also noticed a slight difference between my app and the test app. On my app the panel just slides down but on the test app the panel appears to "flip down" (don't know exactly how describe). The way the panel appears is irrelevant to me, I just noticed that it is not shown the same way.
After trying many things I concluded that the problem had to do with ARC (Automatic Reference Count) settings for the project.
In my case I had enabled ARC on target but not on project, after enabling ARC on project (and dealing with resulting errors and warnings) everything works perfectly now.
I've done a fair amount of iOS development in the past couple of years, so I'm pretty familiar with iOS architecture and app design (everything's a ViewController that you either push, pop, or stick into tab bars). I've recently started exploring proper Mac app development and feel a little lost. I'd like to really just have a sanity check and maybe some advice as to what the proper way to build an app like this is:
I'd like to build a library-style, single window app, that will spawn additional windows during its operation, but not as full-blown documents. The main window will be laid out much like OS X Lion's Mail.app, with a three-wide split view containing:
A source list, or high-level topic selection
A list view of items pertaining to the topic selected in the first pane
A detail view, which shows the details of the object selected in the middle pane
Like I said, really similar to Mail.app as far as looks go.
My question is really how to glue all this together from inside XCode. Here's where my confusion lies so far:
The default project generated a NIB with a main menu and window. I like to encapsulate functionality, so should I make a window controller for this window and somehow hook it up in Interface Builder, or does window-specific functionality belong somewhere else?
If possible, I'd like each of my three panes to be separate view controllers. I created three NSViewController subclasses (XCode automatically generated NIBs), and added (to the main menu/window NIB) view controller objects with each class specified, hooking up each one's view property to one of the three Custom View generic NSView objects I dropped into the NSSplitView. When I tried to set each view controller's NIB, only the main menu/window NIB appeared in the drop-down, and typing the desired one by hand seemed to have no effect (the view's contents didn't actually appear when running the app). This makes me think I'm doing something wrong.
I'm a little fuzzy on what types of views I should use for each of the first two panes. I'll obviously build a custom one for the final pane, but it seems like the first two should be present in the Cocoa framework already.
Anyway, if I'm doing completely the wrong thing, don't bother addressing my questions; just tell me what I should be doing instead. I think I just need a proper Mac developer to point me in the right direction.
With regard to your first question, you don't need to use the main window that Apple supplies in MainMenu.xib. If you want, you are free to delete that window from the nib and then instantiate an NSWindowController in your applicationDidFinishLaunching: delegate method which then loads and controls the main window.
You are definitely confused about NSViewController, which is not really all that surprising, since you might assume that it works like UIViewController.
In fact, NSViewController is completely different to UIViewController and does not have the same level of Interface Builder support. You can't place a view controller in a window in IB, for example, whereas this is standard practice on iOS. NSViewController is a relatively new class on the Mac and generally you use it to load views programmatically and manage the view content.
The class that most closely maps to UIViewController on the Mac is NSWindowController. This has been around a lot longer than NSViewController and in fact many Mac apps don't use NSViewController at all.
Generally, each window in your app should have a window controller managing it. You can use subclasses of NSWindowController to handle a lot of the functionality for each window.
If you want to use NSViewController, then you should use your window controller to manage those view controller objects. This is generally done programmatically due to the aforesaid lack of Interface Builder support. Each NSViewController instance loads its view from a specific nib file. You generally don't add view controllers in Interface Builder.
For your source list you would generally use an NSOutlineView if you have multiple sections or an NSTableView. These two objects are used whenever you need a list of items. NSOutlineView is hierarchical, whereas NSTableView is flat.
I hope this helps.
I'm writing a Windows Phone 7 app and want to programmtically access my Application bar buttons when the page loads. But these always appear to be null. I've tried accessing the button in the following events:
Page Contructor (after call to InitializeComponent)
Page's `Loaded' event handler
The Application Bars StateChanged event handler
There don't appear to be a Loaded event on the individual buttons either. Am I breaking the rules here? Why can't I access the application bar buttons with c#?
When I looked at this in one the CTPs, it was possible to access elements as I outlined in this thread.
Cannot change ApplicationBar items in code
Note that access to Application Bar elements is available through the type rather than the instance as you might initially expect.
Peter Torr clarified soon after that the Application Bar isn't quite a first class citizen in the framework. Explained here in more detail for your reference.
Why are the ApplicationBar objects not FrameworkElements? - Peter Torr's Blog
To localize the button text, in the page's Loaded event handler, I've been iterating over the page's ApplicationBar.Buttons list and replacing the value in the button's Text property with the resource translation. Seems to work, even if it's kludgy.