I need a common property in my project so that I can use or share it thought out the application.
I have tried many solutions but didn't work.
I think it would make many things simple and reusable.
You can use Extension
as documented in
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Expressions.html#//apple_ref/doc/uid/TP40014097-CH32-ID383
you can change previously defined classes properties
example
extension UIColor {
class var customGreen: UIColor {
let darkGreen = 0x008110
return UIColor.rgb(fromHex: darkGreen)
}
}
Make use of the iOS Design pattern "Singleton".
Its uses only one reference for a class and the same property will get reflected where ever you are using it throughout the app.
Reference : https://thatthinginswift.com/singletons/
You can create a lightweight "namespace" by declaring a public struct or enum. Then, simply add your static vars and you can safely share it.
As an added benefit, you get thread-safety for free. (Static stored property initializers are thread-safe.)
public enum SharedConstants {
public static var id = "MyID"
public static var hashCode = 12345678
}
By the way, extensions are great if you want to enhance an existing type. Type extensions let you add new functionality to a type without modifying its original code.
Yet, if all you need is a common shared property, extensions may not be the best choice.
Related
In Swift, I have historically used extensions to extend closed types and provide handy, logic-less functionality, like animations, math extensions etc. However, since extensions are hard dependencies sprinkled all over your code-base, I always think three times before implementing something as an extension.
Lately, though, I have seen that Apple suggests using extensions to an even greater extent, e.g. implementing protocols as separate extensions.
That is, if you have a class A that implement protocol B, you end up with this design:
class A {
// Initializers, stored properties etc.
}
extension A: B {
// Protocol implementation
}
As you enter that rabbit-hole, I started seeing more extension-based code, like:
fileprivate extension A {
// Private, calculated properties
}
fileprivate extension A {
// Private functions
}
One part of me likes the building-blocks you get when you implement protocols in separate extensions. It makes the separate parts of the class really distinct. However, as soon as you inherit this class, you will have to change this design, since extension functions cannot be overridden.
I think the second approach is...interesting. Once great thing with it is that you do not have to annotate each private property and function as private, since you can specify that for the extension.
However, this design also splits up stored and non-stored properties, public and private functions, making the "logic" of the class harder to follow (write smaller classes, I know). That, together with the subclassing issues, makes me halt a bit on the porch of extension wonderland.
Would love to hear how the Swift community of the world looks at extensions. What do you think? Is there a silverbullet?
This is only my opinion, of course, so take what I'll write easy.
I'm currently using the extension-approach in my projects for few reasons:
The code is much more clean: my classes are never over 150 lines and the separation through extensions makes my code more readable and separated by responsibilities
This is usually what a class looks like:
final class A {
// Here the public and private stored properties
}
extension A {
// Here the public methods and public non-stored properties
}
fileprivate extension A {
// here my private methods
}
The extensions can be more than one, of course, it depends on what your class does. This is simply useful to organize your code and read it from the Xcode top bar
It reminds me that Swift is a protocol-oriented-programming language, not an OOP language. There is nothing you can't do with protocol and protocol extensions. And I prefer to use protocols for adding a security layer to my classes / struct. For example I usually write my models in this way:
protocol User {
var uid: String { get }
var name: String { get }
}
final class UserModel: User {
var uid: String
var name: String
init(uid: String, name: String) {
self.uid = uid
self.name = name
}
}
In this way you can still edit your uid and name values inside the UserModel class, but you can't outside since you'll only handle the User protocol type.
I use a similar approach, which can be described in one sentence:
Sort a type's responsibilities into extensions
These are examples for aspects I'm putting into individual extensions:
A type's main interface, as seen from a client.
Protocol conformances (i.e. a delegate protocol, often private).
Serialization (for example everything NSCoding related).
Parts of a types that live on a background thread, like network callbacks.
Sometimes, when the complexity of a single aspect rises, I even split a type's implementation over more than one file.
Here are some details that describe how I sort implementation related code:
The focus is on functional membership.
Keep public and private implementations close, but separated.
Don't split between var and func.
Keep all aspects of a functionality's implementation together: nested types, initializers, protocol conformances, etc.
Advantage
The main reason to separate aspects of a type is to make it easier to read and understand.
When reading foreign (or my own old) code, understanding the big picture is often the most difficult part of diving in. Giving a developer an idea of a context of some method helps a lot.
There's another benefit: Access control makes it easier not to call something inadvertently. A method that is only supposed to be called from a background thread can be declared private in the "background" extension. Now it simply can't be called from elsewhere.
Current Restrictions
Swift 3 imposes certain restrictions on this style. There are a couple of things that can only live in the main type's implementation:
stored properties
overriding func/var
overidable func/var
required (designated) initializers
These restrictions (at least the first three) come from the necessity to know the object's data layout (and witness table for pure Swift) in advance. Extensions can potentially be loaded late during runtime (via frameworks, plugins, dlopen, ...) and changing the type's layout after instances have been created would brake their ABI.
A modest proposal for the Swift team :)
All code from one module is guaranteed to be available at the same time. The restrictions that prevent fully separating functional aspects could be circumvented if the Swift compiler would allow to "compose" types within a single module. With composing types I mean that the compiler would collect all declarations that define a type's layout from all files within a module. Like with other aspects of the language it would find intra file dependencies automatically.
This would allow to really write "aspect oriented" extensions. Not having to declare stored properties or overrides in the main declaration would enable better access control and separation of concerns.
I hate it. It adds extra complexity and muddies the use of extensions, making it unclear on what to expect that people are using the extensions for.
If you're using an extension for protocol conformance, OK, I can see that, but why not just comment your code? How is this better? I don't see that.
I'm building an iOS app where i want to make a protocol (Which by my understanding is the equivalent of java interfaces) for my model, to use for Unit Testing purposes.
In Java you typically want to encapsulate your values in a model and make them accessible through getters and setters only.
How can i ensure this encapsulation in Swift with protocols, where i can't use the private keyword for properties.
My model is setup something like this:
class model {
private var property: Int = 5
func getProperty() -> Int {
return property
}
func setProperty(newValue: Int) {
self.property = newValue
}
}
And i want my protocol to look something like this:
protocol modelProtocol {
private var property: Int { get set }
}
My problem is that i can't declare my properties private, is this just a thing in Swifts access control (I've read they have private, internal and public) that you don't use private properties that much or is there an equivalent to Java's way of handling interfaces and private variables?
(Note: I'm using Xcode 7 and swift 2.0 if that matters)
I don't think that you can have private properties and public Getters and Setters with Swift code, as the getters and setters cannot have a higher access control than the property. For unit testing purposes you can access any internal entity using the #testable attribute as shown in the documentation below.
Access Levels for Unit Test Targets
When you write an app with a unit test target, the code in your app needs to be made available to that module in order to be tested. By default, only entities marked as public are accessible to other modules. However, a unit test target can access any internal entity, if you mark the import declaration for a product module with the #testable attribute and compile that product module with testing enabled.
I do not think you would be able to declare private properties within a protocol, you may need to use a base class instead with internal properties and extend that class. I am still fairly new to protocols myself, but I believe they are mainly used to ensure code conforms to that protocol as in... it provides that functionality or those methods.
References Used:
Swift Access Control
Swift Properties
Swift unit testing access
The problem: A model object is defined in a framework, a protocol is defined in the app target. The app target has knowledge of the framework, but not vice-versa, so the protocol conformance can't be in the model object's declaration.
However, the model object already has the majority of the fields that are needed to fulfill the protocol (mostly var {get} declarations), and -- this is the rub, apparently -- those fields have the same names. There are about 20 properties in the real model.
Unsurprisingly, the following pattern produces an infinite loop:
//Framework Target:
public struct Book {
public let numberOfPages : Int
}
.
//App target:
public protocol BookViewDataSource {
var numberOfPages : Int { get }
}
extension Book : BookViewDataSource {
public var numberOfPages : Int { return self.numberOfPages }
}
But what's the alternative? Rejected/failed ideas:
View takes model directly. A common approach, always bad because it tightly couples the view and the model. Using a protocol-based interface allows easy swapping with mock objects at design time and at runtime.
Different Names. Giving the protocol properties and struct properties different names would work, but clutters up the naming and is silly, because the whole point is the model object has almost exactly the data the view needs. We are keeping it in a framework (following WWDC 14 "Building Modern Frameworks" recommendation) to allow better reuse in a share extension.
Model knows about Protocol. Now we are taking protocols written for views to define the data they need, and moving them into the framework. Ridiculous, but does altogether eliminate need for extension.
Protocol extensions. If we can define a default implementation of the protocol that references self, then objects that fulfill the protocol will just access their getters? But while there's no inline error, the compiler (linker specifically) won't allow it, citing "protocol witness", insisting the Book still doesn't fulfill the protocol (we keep the extension to compute the properties it doesn't have).
This whole thing seems like a common scenario, just to state that a type fulfills the protocol already. Are we missing any easy way to do this, or is there a reason why/how we should choose an above approach? Thx.
This works for me, leaving out the implementation declaration the compiler is still able to figure out Book's conformance:
public struct Book {
public let numberOfPages : Int
}
public protocol BookViewDataSource {
var numberOfPages : Int { get }
}
extension Book : BookViewDataSource {
}
let x = Book(numberOfPages: 3)
print(x)
The above works on SwiftStub, I can't get to a Mac at the moment!
The compiler should figure it out for you if you leave out the implementation in the extension. So this should be considered as a bug (linker error).
Did you update to Xcode 7 beta 5? Since this version resolves some of them.
class XYActivity: UIActivity,YouTubeHelperDelegate
{
var youTubeHelper:YouTubeHelper
var uploadURL: String!
override init() {
self.youTubeHelper = YouTubeHelper()
}
override func activityType() -> String? {
return nil
}
//
}
I want to make uploadURL public, That is, to be assigned in other class.
When I add public infront of var uploadURL:String! it suggest me to make it as internal. I wanna make it public. Please help
In order to make it public, the class must be declared as public.
By default the modifier is internal, which makes classes, methods and properties not explicitly declared as private available anywhere in the current module.
If your project consists of an app only, then you probably don't need public - internal has the same effect. If you are developing a framework instead, and need that property accessible from code in other modules, then you need to declare the entire class and the exposed methods/properties as public.
Suggested reading: Access Control
Excerpt describing default access levels:
All entities in your code (with a few specific exceptions, as described later in this chapter) have a default access level of internal if you do not specify an explicit access level yourself. As a result, in many cases you do not need to specify an explicit access level in your code.
and access levels for single-target apps:
When you write a simple single-target app, the code in your app is typically self-contained within the app and does not need to be made available outside of the app’s module. The default access level of internal already matches this requirement. Therefore, you do not need to specify a custom access level. You may, however, want to mark some parts of your code as private in order to hide their implementation details from other code within the app’s module.
You can make it public if the class that contains it is also public, so change that according to it.
JuST ADD a keyword "public" at start this will make it public in the app.
Very neatly explained on docs.swift.org
I use prism/mvvm/mef for my app, and loading all Views marked with ViewExport(Region) does work nicely (I'm using the StockTraderRI AutoPopulateExportedViewsBehaviour).
Now I'd like to use this runtime lookup capability to initialise some other background classes.
Say I got an interface
public interface ITable
{
}
And I got a lot of classes deriving from this interface.
Is there a way to mark those derived classes somehow and get MEF to create them on runtime and add them into some kind of list or container?
Like into a region which is not shown anywhere, I'd expect? How would I achieve this in MEF?
Sure there is!
Mark the classes inheriting your interface with Export attribute and in another class create yourself a property say of generic type ObservableCollection with attribute [ImportMany]. The should do the trick.
If you are using MEF instead Unity you can also use Container call within your bootstrapper :
var tables = Container.GetExportedValues<ITable>();
Container is the public property of your MEFBootstrapper.