There are a ton of ways that I found to get the current userInterfaceStyle, but I can't tell what is the most appropriate method of getting it.
There are four ways that I found:
UITraitCollection.current.userInterfaceStyle
UIScreen.main.traitCollection.userInterfaceStyle
UIApplication.shared.keyWindow?.traitCollection.userInterfaceStyle
traitCollection.userInterfaceStyle
I generally used number 4 whenever I had to make a global function, and just had the trait collection as a parameter. Doing that seems unnecessary, though. There should be a universal variable. Which of these should we be using?
UITraitCollection.current is a special call that is used in order to get the interface style when you're in a graphics drawing situation. So it isn't really related to the other three.
As for those three, there can be different trait collections / user interface styles at different levels of the hierarchy, and there are different ways to refer to the various objects that comprise the hierarchy. So I can think of a dozen more ways to get the trait collection! But when you want to know the trait collection, you should just ask for the one at the level of the hierarchy you are interested in. Usually this will be the one closest to where your code is. For example, if this is view controller code or view code, you will usually ask for self.traitCollection.
Related
I'd like to define an enum (or something) to give names to possible values of seletedIndex and define the order of destinations in, say, a Flutter NavigationBar in such a way that I only have to go to one place to change the order of the destinations.
The examples I've seen so far always require reordering be done in two places: one in the list of destinations given to the NavigationBar that have an implicit, invisible, unnamed index, and the other is a switch or a subscripting based on selectedIndex to establish the selected page. This seems like a bug magnet. Is there any way to set it up so I only define the order of the destinations in one place and have the list of destinations bound to the correct pages?
It seems to me that NavigationDestination should have a property to handle this binding or a "displayOrder" property, but I don't see this. If there isn't a better way, I guess I could write a function to construct the destination list based on an object (like an enum) that binds the numeric indicies to the corresponding page view, but this seems like a lot of machinery to create for a routine navbar task, especially in this modern OO context -- weird that selecting navbar pages would need a switch in the switchless programming world. Yet the example implementations have switches and two separate areas of the code need to be maintained to do one thing. But, what do I know; obligatory newbie disclaimer follows...
I think my question above was poorly phrased, based on ignorance and seeing some naive examples that suggested page navigation was generally done with an integer like selectedIndex. Once I learned about the Navigator class, and other navigation and List related builders, I saw the OO techniques Flutter provides for putting together hierarchical menus and such without the use of switch statements and integer indicies. So my answer to somebody like me who asks "do I really need to re-invent the navigation wheel" is to learn about Navigation Basics first.
I started writing some code for a 2D game, created a class "objets" trying to keep it as generic as possible. I have a few methods and attributes that are common to every kind of element (buldings, ppl, interface buttons, etc) like (w, h, x, y ...you know) but most of them only make sense when applied to and specific type of item.
So I would have to inherit a new class for every type of actor in the game?
Just wondering if this is a common practice, or maybe i should manage it in a different way.
Thanks in advance.
If you're introducing behaviour then subclass, however if the difference is attribute based then don't e.g.
Animal (has .colour and .makeSound) -> Dog (has .eatOwnPoop) -> RedDog (no, too specific, covered by colour)
Notice how I had ".makeSound" in Animal. I could have put .bark in dog, but then I'd have to put .meow in cat etc. The subclass can simply override and provide a concrete sound.
However, you can use interfaces to better cross-cut your code, but that's quite a lengthy topic and probably overkill for your needs (although it could help any unit testing you do).
It sounds like you are over-using inheritance. It is certainly a red flag when you simultaneously say "common attributes like ..." and "...only make sense when applied to a specific type." Also, it is a red flag that domain objects such as building share a common base class with an interface object like button. Finally, it is quite unusual to define your own objet (object?) class from which every class in your system derives. It's not inconceivable, but in combination with your other comments, it sounds like you've started down an unproductive path.
You might want to refer to a good tutorial on object-oriented design and analysis such as "Head First OOA&D"
You do not HAVE to do anything. Generally, it is useful to use derived classes if they exhibit some kind of commonality but become more specialised in nature requiring specific functionality at each level of inheritance. It is also good to use if you want to have polymorphic behaviour. You have asked a very open ended question but basically do not feel that you HAVE to use inheritance as not every problem requires it and indeed some people overuse inheritance, introducing it in places where it really is not needed. All in all, I would really recommend that if you haven't already that you read a good book on object oriented design as this will then get you to think about your code from a different perspective and greatly improve the way you view software and design it. It may sound like a cop out but this kind of question is very hard to answer without knowing all details of what you are doing.
I'm developing an app based on a TabBarController.
I have 2 views that do some similar actions.
My question is, should I make 2 different classes or should I use only one class with some "if" statements asking if is a class is one or the other. I need maximum performance on this.
The 2 views load a MKMapView, so I need to know if it is better to load just one object that does the entire thing, or two objects that do similar things.
Thanks!
In Object Orientation it's important to bear in mind the difference between a class and instances of that class.
If you ever find yourself thinking of writing some code in a class that says "What class am I? If I'm class X, do thing A; otherwise do thing B" -- don't! It's a classic problem begging for a nice object oriented solution. There are two common solutions in this kind of situation:
1) Write a single class that at instantiation time gets passed in some vital information that it then uses later. Then another part of your code is making instances of this class configured in the correct way -- e.g. in your problem, two instances of this class get made, each with a different bit of info (map location perhaps?) passed into the init method
2) Write a superclass that has two subclasses that specialise the general bahaviour of the superclass. So most of your logic and code goes in the superclass - suppose it's called MapDisplayViewController - but then you extend this class with two subclasses called (for example) MapDisplayViewControllerA and MapDisplayViewControllerB that override one or more methods in important, different ways to differentiate them.
For your problem it sounds like approach 1) would be good.
Having code which says "What class am I?" is often a good example of a 'code smell' -- in other words, a sign that something could be designed much better.
I would say load two objects. iOS will automatically unload your currently not displayed views if it needs more resources anyway. (Assuming you implemented viewDidLoad and viewDidUnload properly, of course).
In addition, if in case your view needs to initialize/load a lot of data when tab is switched, and the common flow involves the user switching from one tab to another frequently, the app may appear to lag during frequent loading, if you use only 1 object. No one likes long and frequent loading times.
Just my opinion though, based on the information your original post provides. A lot of additional factors can still come into play.
This is a follow up to a previous question. if I have multiple plugins/traits with around modifiers, is it possible to ensure a certain execution order (seeing as how I can't be sure which will actually get loaded)? or can I really only control that in code I write and with documentation?
Example: I have 3 Roles each with an around and each can be loaded optionally as a Trait but if more than 1 is loaded they have to be loaded in a certain order to work right together. e.g. loading Trait A B C in that order with work fine but loading it like Trait B A C will result in wonky behavior.
Is there a way I can prevent the user (programmer) from loading them in the wrong order.
Short answer is "No". While method modifiers are ordered, Roles are naturally composed un-ordered. This conflict of composition is one of the reasons method modifiers in Roles are fraught with peril and you rarely see it used for anything complex in the wild.
Users, also, are particularly known for being unordered. Moose provides few tools to enforce the ordered composition of Roles (by design). There is certainly nothing in user space that will constrain them.
That said, you can use Ether's suggestion in a different reply, creating a meta-Trait that consists of the traits composed in the proper order. Alternatively you can jump off the deep end and re-write the Role Composition pieces of Moose to guarantee ordered composition. I honestly can't recommend either of these approaches, both seem to be plastering over what to me would be a clear indication of poor design.
Without knowing more about your particular problem I can't suggest a better solution though. I would generically look for something like registering a callback and triggering that somehow rather than relying upon method modifiers.
To quote Moose::Manual::MethodModifiers (right before WHY USE THEM?).
When there are multiple modifiers of
the same type, the before and around
modifiers run from the last added to
the first, and after modifiers run
from first added to last:
before 2
before 1
around 2
around 1
primary
around 1
around 2
after 1
after 2
The idea is that you are modifying the method as it exists right at that moment.
Is there a way I can prevent the user (programmer) from loading them in the wrong order.
This is a very subjective answer and depends on the architecture of your system, which you have not described. But one way is that you could apply the roles "yourself" in another role, which is then solely applied to the class:
package OmniRole;
use Moose::Role;
with 'RoleA',' RoleB', 'RoleC'; # these roles contain the 'around' method modifier
package User::Class;
use Moose;
with 'OmniRole'; # wraps method 'foo' several times to do magic.
We seems to be abstracting a lot of logic way from web pages and creating "helper" classes. Sadly, these classes are all sounding the same, e.g
ADHelper, (Active Directory)
AuthenicationHelper,
SharePointHelper
Do other people have a large number of classes with this naming convention?
I would say that it qualifies as a code smell, but remember that a code smell doesn't necessarily spell trouble. It is something you should look into and then decide if it is okay.
Having said that I personally find that a name like that adds very little value and because it is so generic the type may easily become a bucket of non-related utility methods. I.e. a helper class may turn into a Large Class, which is one of the common code smells.
If possible I suggest finding a type name that more closely describes what the methods do. Of course this may prompt additional helper classes, but as long as their names are helpful I don't mind the numbers.
Some time ago I came across a class called XmlHelper during a code review. It had a number of methods that obviously all had to do with Xml. However, it wasn't clear from the type name what the methods had in common (aside from being Xml-related). It turned out that some of the methods were formatting Xml and others were parsing Xml. So IMO the class should have been split in two or more parts with more specific names.
As always, it depends on the context.
When you work with your own API I would definitely consider it a code smell, because FooHelper indicates that it operates on Foo, but the behavior would most likely belong directly on the Foo class.
However, when you work with existing APIs (such as types in the BCL), you can't change the implementation, so extension methods become one of the ways to address shortcomings in the original API. You could choose to names such classes FooHelper just as well as FooExtension. It's equally smelly (or not).
Depends on the actual content of the classes.
If a huge amount of actual business logic/business rules are in the helper classes, then I would say yes.
If the classes are really just helpers that can be used in other enterprise applications (re-use in the absolute sense of the word -- not copy then customize), then I would say the helpers aren't a code smell.
It is an interesting point, if a word becomes 'boilerplate' in names then its probably a bit whiffy - if not quite a real smell. Perhaps using a 'Helper' folder and then allowing it to appear in the namespace keeps its use without overusing the word?
Application.Helper.SharePoint
Application.Helper.Authentication
and so on
In many cases, I use classes ending with Helper for static classes containing extension methods. Doesn't seem smelly to me. You can't put them into a non-static class, and the class itself does not matter, so Helper is fine, I think. Users of such a class won't see the class name anyway.
The .NET Framework does this as well (for example in the LogicalTreeHelper class from WPF, which just has a few static (non-extension) methods).
Ask yourself if the code would be better if the code in your helper class would be refactored to "real" classes, i.e. objects that fit into your class hierarchy. Code has to be somewhere, and if you can't make out a class/object where it really belongs to, like simple helper functions (hence "Helper"), you should be fine.
I wouldn't say that it is a code smell. In ASP.NET MVC it is quite common.