I am actually working in a Kotlin Multiplatform Project where we developed common code for Android / IOS / Web
However due to JS, some classes in common/ need to be annotated with #JSName / #JsExport.
Do you think is a good practice to have these annotations in common/. Would not be better to use actual / expect feature to avoid having #JSName / #JsExport in common/ classes
Related
Setting up a full "KMP" / "KMM" project seems like overkill, as only the commonMain/commonTest directories would be filled.
All the other templates seem to be platform-specific.
Is there something like a "pure" Kotlin library template?
It would just be a module with only commonMain and commonTest. You would need at least:
A Gradle module
Kotlin config with multiple targets in that module
Common code folders
Whether you put the app code in the same repo or have the shared code in a separate repo is up to you. I'm not sure how much simpler you can make the config, though.
One issue I think you'll run into is the need for platform-specific code on iOS because there are different interfaces for concurrency than you might want for a Kotlin-friendly (I.E. Android) environment. Same for things like default params.
My-KMP-Library
│ build.gradle.kts
└───src
└───commonMain
└───kotlin
└───mynamespace
What makes it multiplatform are the targets you specify in build.gradle.kts.
I support a suite of related iOS apps, some of which make use of extensions (WatchKit and Today Widget). All of these apps and extensions make use of a shared private framework I've built up over time for handling certain workflows around authentication and common business logic. This framework is maintained as a private pod.
Recently, I've run into a problem where I'd like to add a method to the framework that's only really useful for the iOS apps (extensions don't need it) that uses certain APIs that are unavailable to extensions (such as [UIApplication sharedApplicaion]). I'd like to get the usual benefit of shared code, where this is implemented in only one place (the shared framework) for all my various apps to leverage. However, I can't find a way to conditionally include that method for just the apps and not the extensions without getting a compile-time error.
Normal recommendations around this problem usually suggest the use of a preprocessor macro to opt-out around the problematic code if desired, but that doesn't really work for a shared framework situation. Macros are applied at compile-time, so the shared framework is either going to include that method, or not, and there doesn't seem to be a runtime solution to optionally exclude it. If it's included, the extensions can't compile. If it's not included, my apps can't make use of the feature.
I also started investigating if there was some way that Cocoapods could automatically make two versions of the framework, one to be used by the apps, and one by the extensions, but this would seem to introduce problems around duplicate symbols, and generally doesn't seem supported.
Are there any other suggestions for how to handle this, apart from just extracting out the problematic functionality into a different framework? (I really would prefer to just share one)
Building Modern Frameworks says every app has its own copy of a custom framework. Now that Xcode supports iOS frameworks, is it still true that frameworks are static libraries but just more convenient? If that's true, then why choose the static library template? Otherwise, should I convert all my required custom frameworks to static libraries once Swift supports static libraries?
Frameworks serve the same purpose as static and dynamic shared
libraries, that is, they provide a library of routines that can be
called by an application to perform a specific task. For example, the
Application Kit and Foundation frameworks provide the programmatic
interfaces for the Cocoa classes and methods. Frameworks offer the
following advantages over static-linked libraries and other types of
dynamic shared libraries:
Frameworks group related, but separate, resources together. This grouping makes it easier to install, uninstall, and locate those
resources.
Frameworks can include a wider variety of resource types than libraries. For example, a framework can include any relevant header
files and documentation.
Multiple versions of a framework can be included in the same bundle. This makes it possible to be backward compatible with older
programs.
Only one copy of a framework’s read-only resources reside physically in-memory at any given time, regardless of how many
processes are using those resources. This sharing of resources reduces
the memory footprint of the system and helps improve performance.
This excerpt taken from here.
Excerpt taken from here.
How are Frameworks and Library Different from each other?
Inversion of Control is a key part which makes a framework different from a library. When we call a method from a library we are in control, but with the framework the control is inverted, the framework calls our code. (E.g a GUI framework calls our code through the event handlers)
A library is essentially a set of functions (well defined operations) that we can call (organized into classes). Each does some work and then returns the control to the client
A framework embodies some abstract design with more behavior built in. In order to use it, we need to insert our behavior into various places in the framework either by subclassing or by plugging in our code. The framework code then calls our code at these points.
A framework can also be considered as a skeleton where the application defines the meat of the operation by filling out the skeleton. The skeleton still has code to link up the parts
The use of dynamic frameworks is exclusively for swift from iOS 8 and later, i.e (you can't submit a build with iOS 7 and a dynamic framework)
If you want support for iOS 7 and before you can use a static library and objc
A dynamic framework and a static library are different things, a framework is a bundle where you have a directory and can include resources, views, classes, and also libraries
A static library is only executable code
Also you use the code in a static library inside your own code, in the case of a framework he use the code and handle the way it runs and what do
This link could help you
http://www.knowstack.com/framework-vs-library-cocoa-ios/
I am a (very) novice iOS/Swift programmer with a basic question about moving reusable software objects to their own ... something.
I am developing three iPhone apps that present information from three distinct data sets. Those data sets contain unique information but are structurally similar. As such, the apps share some Swift classes that are identical, specifically the classes that model the data. As I continually refactor the code, I find that when I tweak a class in one app's project, I have to remember to go to the other two projects and make the same tweaks to the same classes for those apps. It's getting to be a big headache.
What I would like to do is have one class definition in its own ... something that I can share, link, import, or attach to/from each app's project. From my online research, I suspect that the ... something is a library? or maybe it's a framework? or a module? I have found all three terms are used, but I am not sure how they relate to each other.
Given that all of the software I am writing is in Swift, does Xcode support what I am trying to do? Thank you!
It seems you have the issue of needing the same Swift class in multiple projects. You could build a Framework (aka Module) for this class then copy it in to each project. This is probably the formally correct approach but it is a bit of overkill for just a single class.
Instead, you could just make the file in the Navigator panel a reference in each project to the one actual file.
You could also make a Workspace and then put each project into the workspace and just have the file at the top level (but this may introduce some build complexity).
I am fairly new to iOS and XCode and come from .Net background. So in Visual Studio I would usually separate the layers of my application (say WebApp layer, business logic layer, data access layer etc.) into separate project so I can have control over what each project depends on etc.
So my question is if there is something similar in XCode? I tried using the static library template for a target and it seems to be working but I am wondering if there are any drawbacks for this approach? All the examples I find on the Internet just show a folder structure in the app target for the layers is this the preferred way of doing it and why?
I am also using Swift if that makes any difference but I still do have dependencies on 3rd party libraries developed in Objective-C
New in Xcode 6 / iOS 8, you can make a framework, thus dividing your code into multiple targets. This is a nice easy way to separate reusable functionality. It also has the advantage of privacy; in Swift, each framework is a module, and one module that imports another module can see only those members of the imported module that are declared public.
In general, however, I would suggest that you not worry about this; just keep your classes organized conceptually using the MVC architecture that Cocoa encourages, and physically organize them within your project using "groups" (the fake folders that appear in Xcode's project navigator). The reason is that very little of your code is going to prove to be reusable anyway, so it's really just a matter of making editing / developing / maintaining this project as easy as possible.