The new Google Analytics SDK introduces a new subclass to UIViewController from which you have to inherit: GAITrackedViewController.
More info here: https://developers.google.com/analytics/devguides/collection/ios/v2/screens
This obviously clashes with MvxBindingTouchViewController, as you can only inherit from one class in C#.
What's the recommended way in getting this working?
MvvmCross's MvxTouchViewController's is special...
MvvmCross's MvxBindingTouchViewController is even more special...
But these are only special in that they inherit from standard UIViewControllers (UIVIewController, UITableViewController, UITabBarController, etc) and then they add functionality for:
ViewModel construction and the ViewModel property at the Cirrious.MvvmCross layer
construction and storage of Bindings at the Cirrious.MvvmCross.Binding layer
Take a look at some examples:
https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Touch/Views/MvxTouchViewController.cs and https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Binding.Touch/Views/MvxBindingTouchViewController.cs
https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Touch/Views/MvxTouchTableViewController.cs and https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Binding.Touch/Views/MvxBindingTouchTableViewController.cs
https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Touch/Views/MvxTouchCollectionViewController.cs and https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Binding.Touch/Views/MvxBindingTouchCollectionViewController.cs
In these you can hopefully see this involves a fair amount of cut and paste of code - although we do try to minimise it using extension methods. (If C# had multiple inheritance or mixins, we wouldn't need to do that - I'd love to have Mixins... but don't want multiple inhertitance ever!)
So.... if you want to add your own MvxXXXXXBindingViewController, then:
take your base XXXXX class,
inherit from it and add 'the stuff' to make an MvxXXXXViewController,
then take your MvxXXXXXViewController and inherit from it again to make your MvxBindingXXXXXViewController
publish to your blog and to a new GitHub repo so everyone else can piggyback off your hard work
job done
Advanced notes:
If you want to see the same thing in Droid, see Insert a Monogame view inside MvvmCross monodroid Activity
The TabBarController is also interesting - it's got some additional methods
At some point 'soon' (first half of this year) we will create VeeThree and this will switch the MvxViewController's to a non generic format - this is because MonoTouch now recommends against using Generics on iOS base classes - Rolf says it's safe most of the time, but when it causes bugs they are 'heisenbugs'.
There is also some dead old-iOS code in the current classes (ViewDidUnload) - this code will be culled in VeeThree too.
Related
Many CocoaPod and native iOS libraries use protocols that they name either CustomClassDelegate or CustomClassDataSource as a means to do some setup or customization. I was wondering when I should use this programming model, because it seems like I could accomplish much of this with properties.
Example
If I define a custom class called SmurfViewController that has a SmurfLabel, is it better practice to store the smurfLabel as a private property and have a public computed property called smurf that looks like this:
private var smurfLabel = UILabel()
public var smurf: String {
get {
return smurfLabel.text
}
set(text) {
smurfLabel.text = text
}
}
or should I define a SmurfDataSource that has a public function that looks like this:
func textForSmurfLabel() -> String {
return "smurfText"
}
When should I use what here?
You should just use a property for that. Delegates and Datasources are for different controllers/Objects to speak to one another when the alternative is to instantiate the controller/object from the navigationStack/view hierarchy. A Delegate forms a specific communication between the two that allows for clear knowledge in what their relationship is while keeping them decoupled (assuming you try to keep it that way). I disagree with the article that says callbacks are "better". They are amazing and I advise using them often, but just understand that most options that swift provides you with have a place where they work best.
I might be slightly bias, but Swift is an amazing language with OOP being a backbone and everything it has was well put together in order to provide the correct tools for each situation you find yourself in.
I often find myself using both of those tools and one other more customizable option in my more advanced setups where I have an overseeing viewController that manages many child controllers. It has direct access to all of them that are active but if any of its children communicate with it, it is through delegates. Its main job is just to handle their place on the screen though, so I keep everything manageable.
Delegates and data sources are more appropriate for offloading behaviors to other entities, not simple values. In other words, if your type just needs a value for something, you are correct that it makes more sense to expose that as a property that can be set from the client code.
But what should happen (for example) when a user taps a specific table view cell is a behavior that shouldn't be hard coded into UITableView. Instead, for flexibility, any implementation of that behavior can be created in a delegate and called by the UITableView when appropriate.
In general, think of delegation as a way to make subclassing unnecessary, because the methods you would normally override in a subclass are instead moved into a protocol that can be implemented by ANY type, not just a subclass of the base type. And instead of calling internally implemented methods to get certain behaviors, your type is simply calling those behaviors on an external collaborating class (the delegate).
So perhaps the best guideline for when to use a data source or delegate is the question: "Would I need to subclass this class in order to change this value or behavior in the future". If the answer is no, because you can just set a property from client code, then don't use delegation. If the answer is yes, then offload that behavior to a delegate or data source instead of forcing future programmers to subclass your class to make it work for their use case.
Delegate is an interface for the undefined activities.
so when you make a SDK or framework, you must provide an interface so that users can write a proper code for the interfaces' expecting activity.
i.e, Table View needs a datasource to show it's contents, but the apple's library developers doesn't know the content whatever contents their library users will use. so they provided an interface like datasource, delegate.
and in the library, they just call this methods. that's the way the library should be made.
But in your code, the label is defined very explicitly as well as it's in the current view, and you don't need to make an interface for an undefined activity.
if you want know more about this kind of coding style, you need to do some researches on Software Design Pattern.
https://en.wikipedia.org/wiki/Observer_pattern
https://en.wikipedia.org/wiki/Delegation_pattern
https://en.wikipedia.org/wiki/Software_design_pattern
I love apple's sdk very much, because they used all the needed design patterns very properly.
First of all i know MVC well and have been using it in project but when it comes to organizing classes and there role i am bit not sure of there proper implementation. Lets take a scenario to proceed with:
A sample which will display All Employee and Department. Data will be fetched from Web Services(Json) and will be stored as offline(Core Data).
So MVC pattern would be:
View will be my storyboard with Employee and Department UIViewController.
Controller will be EmployeeViewController.swift and DepartmentViewController.swift
Model will be Employee.swift and Department.swift
class Employee: NSObject {
var name: String?
}
class Department: NSObject {
var departmentName: String?
}
ServiceManager which will make calls to the web service.
ParseData which will parse the web service response and convert it into Employee and Department objects
CoreDataManager is singleton class to manage CRUD operation on offline DB.
Here are series of question on the above scenario which i have:
Is my understanding correct? Is the structure which i am trying to build follows proper MVC?
How the controller will interact with these components (Service Manager, ParseData, CoreDataManager). Should there be another class which will facilitate the communication between controller and data management(if controller does this then it will a tightly-coupled structure and massive as well).
Should Model be having any code other then property and initialization method as most of the model which i have seen only have property declaration?
Should there be separate UIView classes instead of storyboard to create a proper MVC structure?
Is my understanding correct? Is the structure which i am trying to
build follows proper MVC?
First I will say that "proper" MVC will depend on who you're asking. Its origin is commonly attributed to Trygve Reenskaug when he introduced this into Smalltalk in the 70's. However, his type of MVC was widely different from the bloated versions most commonly used today. The modern way of thinking about MVC is
Model = mostly a dumb class which primarily encapsulates data
View = whatever we present on the screen
Controller = the big lump of code that does almost everything,
sometimes offloaded by a manager class or two of some sort
Reenskaug, however, would have a model and a view and a controller for a button. For a label. For a field. I'm not saying that is what we should strive for, but there should be better ways to structure a project than using the Massive ViewController pattern (as it is jokingly referred to in the iOS community).
Luckily, there are.
Uncle Bob is preaching Clean Architecture. There are several implementations of this, and various people have made their own implementations of this for iOS, like VIPER and Clean Swift.
How the controller will interact with these components (Service
Manager, ParseData, CoreDataManager). Should there be another class
which will facilitate the communication between controller and data
management(if controller does this then it will a tightly-coupled
structure and massive as well).
Following the principles of Clean Architecture, you should encapsulate these functionalities into layers, in a way that enables you not just to split the code into multiple components, but also enables you to replace them with other components when that is needed. (But yes, at the very least avoid putting all of this in your controller!)
Should Model be having any code other then property and initialization
method as most of the model which i have seen only have property
declaration?
Again, there is not a single answer here. Some proponents of "real" OOP will say that each object should be self-served (i.e. a model object should know how to persist itself), while others extract the knowledge of such operations into "managers". Putting code to persist an object into the object could mean littering persistence functionality into many objects, or require you to rely on subclassing or other solutions to avoid this coupling.
Should there be separate UIView classes instead of storyboard to
create a proper MVC structure?
Storyboard or not does not determine whether you're using "proper" MVC. Also, what kind of class you're choosing (UIView or UIViewController) to represent the View is also not important. Your ViewController can be dumbed down to such a degree that it contains no logic (forwarding the logic that it DOES have to another class, i.e. the Presenter in VIPER).
I would recommend reading about the Clean Architecture and maybe watch a video of Uncle Bob explaining it, read other people's reports on implementing it, and then consider whether MVC is the correct pattern for your iOS project.
I am trying to implement component for possibility to apply different skins to views and controllers at runtime without reinitialising these controls. I want to use such logic:
Declare protocol with methods for applying skins.
All necessary classes implements this protocol.
When user selects skin all instances of classes that conform to protocol receive message to apply skin.
So I know how to get all necessary classes that conform to my specific protocol by using objc_getClassList and class_conformsToProtocol functions.
But how to get all allocated instances of these classes for sending message to them?
I know that it could be implemented by internal logic of every class by storing all instances in static storage and returning array by class method. But it isn't elegant solution. I'm finding more universal solution where I can add new skinnable controls in easy way.
It sounds very much like you're reinventing <UIAppearance>. You should at least start there. It's what it's for. Also see Peter Steinberger's writeup for discussion of adding custom properties.
To your basic question, there is not a runtime call to enumerate all allocated objects of a class. It would add a lot of overhead to provide that (objects come and go all the time and very quickly). Even if you could do it, you probably shouldn't. But since you're talking about visible views, then you can always do this by enumerating the view hierarchy under NSWindow. Any views not currently in the view hierarchy should be expected to correctly redraw in an new style the next time they come on the screen.
But I'd start with <UIAppearance>.
I wish to replace the implementation of System.Web.Mvc.ActionMethodSelector as used by the FindAction method of ReflectedControllerDescriptor, but would like to take advantage of the existing implementation, ideally by deriving from ActionMethodSelector. However, because the class is marked as internal the only way I can see to do this 'properly' is to derive from ReflectedControllerDescriptor and implement FindAction by copying the code from ActionMethodSelector. I wish to avoid this however due to the quantity of code, and potential issues trying to keep it up to date with the framework.
I'm considering the following approaches:
Biting the bullet and copying the code
Using reflection so as to take advantage of the existing implementation
Are there any other approaches that I'm missing, better or otherwise?
I know it is a bit late to answer still I am giving it a try.... :)
I believe that you somehow want to tweak action method selection process in ASP.NET MVC. If my understanding is correct you can make use of custom ActionMethodSelectorAttribute by deriving from System.Web.Mvc.ActionMethodSelectorAttribute. Write your own custom logic in the custom selector and apply it on the top of the action methods. I believe in this way the action method selection process can be tweaked without disturbing the natural process.
If you wish you can visit these links: http://programersnotebook.blogspot.in/2014/02/aspnet-mvc-actionnameselector-and.html, http://programersnotebook.blogspot.in/2014/02/aspnet-mvc-actionnameselector-and_2.html
I've inherited a long term maintenance code base that has two radically different iPhone and iPad views. This has created one large UIViewController class that has ballooned to over 1k lines of code, is a mashup of ISIPAD statements, private vars, properties, iBOutlets/Actions and, for example, uses a UITableView for one implementation and something completely different for another.
To make matters worse the current software pattern relies on subclassing.
Currently we look like this:
ParentVC (both iphone/ipad God class also has xib(xib~ipad) + iboutlets/actions)
| | |
ChildA ChildB ChildC
My initial thought was to take the ParentVC and split it into iPhone/iPad specific classes
ParentVCBase
| |
ParentVC_iPad(xib~ipad) ParentVC_iPhone(xib)
| |
ChildA/B/C_iPad ChildA/B/C_iPhone
and spit out the correct Child subclass via a factory call.
The issue I've encountered is that each Child overrides a few ParentVC method calls and implements it's own feature specific methods that are not device specific (keep in mind the main goal of the original subclassing was to share view layout). This design pattern would only work if I were to duplicate code for ChildA_iPhone and ChildB_iPad. I'd rather avoid that as I've traded one anti-pattern for another.
I'm a at a bit of a loss here. I've almost considered creating the Child classes at runtime (objc/runtime.h), swizzeling the required Child methods from a reference Child class but that doesn't seem any less of a mess than we currently have. To simply clean up I've also considered keeping the ParentVC header (with it's large list of IBOUTlets, properties, etc) and putting device specific methods into categories to at least separate the functionality until the day a real refactor is needed.
Curious if there are any iOS architects that have had to deal with this at one point in time or how they might deal with it.
This isn't an iOS specific question as much as it is a object-oriented design question.
You definitely want to avoid code duplication. Duplication is the source of much evil.
In general, what you want do is avoid being restricted by the limitations of inheritance in designing your classes. What you want to move towards is class composition.
So you could move to a design that looks like this using the bridge pattern:
ParentVC ---> ImplementationA
| | | |
ChildA ChildB Implementation_iPhone Implementation_iPad
Here, ParentVC has the same class hierarchy as above, but it uses a separate class hierarchy, ImplementationA, for implementation. That class hierarchy breaks down into iPhone and iPad versions. Class ImplementationA holds the guts of the implementation that was in ParentVC.
Inheritance is a design pattern, but it is just one of many. If you stick to just using that one pattern you'll get stuck into making bad designs. You need to combine patterns to properly model the system.
Of course, be sure to use unit tests, as much as possible, to ensure you don't break anything when you're making these changes.