Creating Xamarin ios storyboard interfaces using classes that are not directly or do not inheret directly from InterfaceController - xamarin.ios

When creating a WatchKit (WatchOS) Interface controller in the storyboard designer/editor, I cannot set it's class to something that is not itself type WKInterfaceController nor an immediate derived child of WKInterfaceController.
Basically in the hope of abstraction and better code reuse, better design overall, I would like to be able to use classes that are how to say, a more distant relative of their base WKInterfaceController
Basically right now it seems that your stuck using the storyboard designer to make a new WatchOS project. And using the storyboard designer you only have the option to select the WKInterfaceController class:
public partial class WKInterfaceController
or one that directly inherits from it:
public partial class ChildInterfaceController : WKInterfaceController
but nothing else such as:
public partial class GrandChildInterfaceController: ChildInterfaceController
So is there any way to do this that doesn't risk the chance of getting corrupted when you reenter the storyboard designer at some point?
Note: I've already asked if it is possible to avoid using a storyboard all together, but that has gone unanswered so I'm assuming no.
For clarity I'm talking about this dialog for "class":

Related

Xamarin iOS : How to detect the tableview scroll

I want to detect the scroll of tableview in my class. I used decelerationEnded method of UITableViewDelegate but it got crashed.
Ideally you should be using a UITableViewSource assigned to your UITableView.Source property. You no longer require a delegate class, you can override all of the necessary methods within the source, which is the currently preferred method of achieving the result your after. You are most likely looking to override the method called 'Scrolled' within the UITableViewSource. However I would suggest making use of 'DecelerationEnded' as well if you're trying to do something depending on if your scroll view is at the 'bottom' or 'top' of the UITableViews content (That's just a little tip based off of some experience with this in a recent project.)

Developing Xamarin.iOS application using MVVMCross and Storyboards

I am trying to understand how storyboards work in iOS development and how MVVMCross fits in. I thought the best solution would be to build an iOS version of the MVVMCRoss TipCalc Tutorial
I am using Storyboards as you cannot edit XIBs in Visual Studio. My current thinking is one Storyboard per screen.
I have it working but it feels like i did it with more luck than judgement. Therefore I want to check my understanding.
In TipCalc.UI.Touch I have
TipViewController.cs
TipViewController.storyboard
I have added a custom Mvx View Container as suggested in this SO answer. In the CreateViewOfType method of that container I am calling Storyboard.InstantiateViewController and casting that to an IMvxTouchView.
How can a controller be a View as well?
I am planning on having a "View" per storyboard.
If you have multiple views in a storyboard, would you have a controller per view?
When I bring up the Properties window for a "View" in the storyboard designer it has a Name and a class in the Identity section. What is the purpose of the Class property? Does that create a code-behind file?
I am creating the View-to-ViewModel bindings in the ViewDidLoad method of the Controller
public override void ViewDidLoad()
{
base.ViewDidLoad();
this.CreateBinding(this.tipValueText).To<TipViewModel>(vm => vm.Tip).Apply();
this.CreateBinding(this.subTotalTextBox).To<TipViewModel>(vm => vm.SubTotal).Apply();
this.CreateBinding(this.generositySlider).To<TipViewModel>(vm => vm.Generosity).Apply();
}
These bindings work but again I just wanted to check that it is how others do it too.
The iOS ViewController is actually the View in an MVVMCross application. You can think of the view controller as the code behind for the view (so just like a Windows Phone/Windows Store app will have a XAML and related .cs file, or an Android app will have an axml and a java view class)
Yes, when using multiple views in a single storyboard each one will actually be a viewcontroller (since that's what a screen in a storyboard is)
The class property defines which viewcontroller class the layout in the storyboard uses (so which code behind class to use, and if it doesn't exist it will be created)
I prefer a single storyboard as most of my apps don't have too many screens so these are the steps I follow when creating a View in an existing storyboard
Add a ViewController
Type in the view name in the Class field (this name would correspond to the ViewModel name, so HomeView for HomeViewModel, etc.). As soon as you hit enter the ViewController class should be created.
Type in the same view name as the Storyboard Id (this is used to fetch that view)
Add controls and set their names. Setting a control's name will updated the .designer file that was created for the ViewController
Create the ViewDidLoad override in the ViewController class and set up my bindings
If you use a storyboard per view, creating that storyboard with the correct name (HomeView for example) should create the ViewController and designer files for you and give you a storyboard with that one viewcontroller ready to go
edit:
in your bindings, you can use one set.Apply(); at the end

extend class in Java FX?

In many occasions JavaFX needs to be customized with classes that extend existing ones. I tried this approach, for example to add a method to the NumberAxis class that would enable the label of the axis to be rotated.
But I got a "NumberAxis is declared final, can't be extended" compiler error. I wonder how people who extend classes do? Do they have access to the source code of javafx, modify it to make some classes not final, and recompile it? (sounds tricky! )
Making lots of classes final in the JavaFX framework was an intentional decision by the framework developers. To get a flavor of why it's done, see the Making Color Final proposal. That's just an example, there are other reasons. I think experience with subclassing in the Swing framework was that it caused errors and maintenance issues that the JavaFX designers wanted to avoid, so many things are made final.
There are other way to extend functionality than to directly subclass. Some alternatives for your rotation example:
aggregation: include the NumberAxis as a member of new class (e.g. NumberAxisWithRotatableText) which adds an accessor to get the underlying NumberAxis node and a method to perform the rotation (e.g. via a lookup as explained below).
composition: for example extend Pane, add a NumberAxis, disable the standard text drawing on the axis and add rotated labels yourself as needed.
css stylesheet: for example use a selector to lookup the text in the NumberAxis and the -fx-rotate attribute to rotate it.
node lookup: Use a node.lookup to get at the underlying text node, and apply the rotation via an API.
skin: All controls have a skin class attached them, replace the default skin class with a custom one.
subclass an alternate class: Subclass the abstract ValueAxis class rather than the final NumberAxis class.
Source code for JavaFX is available with build instructions. However, I don't recommend hacking a personal copy of the source code to remove final constructs unless you also submit it as an accepted patch to the JavaFX system so that you can be sure that your app won't break on a standard JavaFX install.
If you really think it is a good idea for a given class to be subclassable, then log a change request. Sometimes the JavaFX developers are overzealous and make stuff final which would be better not being final. NumberAxis perhaps falls into that category.

Insert a Monogame view inside MvvmCross monodroid Activity

I'm trying to build a Monogame view inside a RelativeLayout from my MvvmCross monodroid Activity view.
An android Activity inherits from Microsoft.Xna.Framework.AndroidGameActivity to be able to run a Monogame inside a RelativeLayout (working).
My MvvmCross Activity inherits from MvxBindingActivityView(working).
So, I need a way to run the game and bind some datas within the same activity.
Thanks in advance for your help.
Loosely speaking, you can translate any Activity to an MvxActivity by inheriting some interfaces and by then cutting and pasting a small amount of code which does the basic loading and assignation of the ViewModel.
e.g. see the #Region and IMvxAndroidView<TViewModel> added to make MvxActivityView.cs from a normal Activity.
e.g. it's the same region and interface used for adapting a specialised Activity like Google's MapActivity into MvxMapActivityView.cs
At this level, the Activity/View has a ViewModel which can be used in C# code, but has no clever xml inflation - it has no clever Binding support.
Code can be written at this level - I've shipped apps without binding - but many users prefer to add DataBinding too...
To add this DataBinding support, you need to add a bit more code which provides BindingInflate, storage of bindings, disposal of bindings, etc.
e.g. a raw MvxActivityView is extended using the IMvxBindingActivity interface and a #region like: MvxBindingActivityView.cs
e.g. MvxMapActivityView is extended using the same region and interface: MvxBindingMapActivityView.cs
So to extend your the custom AndroidGameActivity:
Inherit from AndroidGameActivity to get ViewModelOwningGameActivity<T> and cut and paste the IMvxAndroidView<TViewModel> interface and #region from MvxActivityView<T> to provide the ViewModel methods, fields and properties.
Then assuming you want binding:
Inherit from ViewModelOwningGameActivity<T> to get BindingGameActivity<T> and cut and paste the IMvxBindingActivity and #region from MvxBindingActivityView<T> to get the binding methods
For specialist Activities you may want to add more - e.g. you may could add some custom helper methods for the MapActivity to plot points and lines, or for GameActivity to do whatever games do... but this is up to individual implementations.
Sorry about the cut and paste of code required in adapting Activities - I have tried to keep this to a minimum. However, writing Mvx is the one time so far that I've really wanted Multiple Inheritance or Mixins in C#

MVC basics: Should I add a UIViewController, a Delegate or a Source to my custom view?

my question is about view controllers, delegates and all that in general. I feel perfectly comfortable with UIView, UIViewController, Delegates and Sources, like UITableView does for instance. It all makes sense.
Now I have implemented my first real custom view. No XIBs involved. It is an autocomplete address picker very much like in the Mail application. It creates those blue buttons whenever a recipient is added and has all the keyboard support like the original.
It subclasses UIView. There is no controller, no delegate, no source. I wonder if I should have either one of those? Or all, to make it a clean implementation.
I just cannot put my finger on the sense a view controller would make in my case. My custom view acts much like a control and a UIButton doesn't have a controller either.
What would it control in my view's case?
Some of my thoughts:
For the source: currently the view has a property "PossibleAutocompleteRecipients" which contains the addresses it autocompletes. I guess this would be a candidate for a "source" implementation. But is that really worth it? I would rather pass the controller to the view and put the property into the controller.
The selected recipients can be retrieved using a "SelectedRecipients" property. But views should not store values, I learned. Where would that go? Into the controller?
What about all the properties like "AllowSelectionFromAddressBook"? Again, if I compare with UIButton, these properties are similar to the button's "Secure" property. So they are allowed to be in the view.
The delegate could have methods like "WillAddRecipient", "WillRemoveRecipient" and so on and the user could return TRUE/FALSE to prevent the action from happening. Correct?
Should I maybe inherit from UIControl in the first place and not from UIView?
And last but not least: my custom view rotates perfectly if the device is rotated. Why don't all views? Why do some need a controller which implements ShouldAutoRotateToDeviceOrientation()?
Does it make sense what I wrote above? In the end I will provide the source on my website because it took me some time to implement it and I would like to share it as I have not found a similar implementaion of the Mail-App-like autocomplete control in MonoTouch.
I just want to learn and understand as much as possible and include it in the source.
René
I can answer part of your question.
I just cannot put my finger on the
sense a view controller would make in
my case
The ViewController is responsible for handling the View's state transitions (load, appear, rotate, etc) These transitions are used mainly when you use a navigation component (UINavigationViewController, UITabBarController). These components needs to received a ViewController that will handles the view's transitions.
For exemple, when you push a ViewController on a UINavigationViewController, it will cause the ViewDidLoad, ViewWillAppear, ViewDidAppear. It will also cause the ViewWillDisappear, ViewDidDisappear of the current ViewController.
So, if your application has only one portrait view, you don't need a ViewController. You can add your custom view as a subview of the main window.

Resources