Are there any drawbacks of splitting up a Swift project into several frameworks? In my current application I don't need to do this but it would logically separate the different parts of my code so I intended to put the code into multiple frameworks (embedded binaries). However, I don't know if Swift's apparently awesome feature 'Whole Module Optimization' is affected by creating several modules.
Furthermore, are there any other drawbacks of using frameworks or performance upsides?
Thanks for your clarifications ;)
One thing I know is that with framework, you can reduce compiling time. Because you can compile your stable framework and reuse it. Then xcode only compile your main project.
The drawback (in my opinion) is that you have to import framework whenever you use it.
Related
When creating a new app in Xamarin Forms I see these two options:
Configure your Forms App
Shared Code:
Use .NET Standard
Use Shared Library
Can someone explain the difference? I looked at the help and I am still confused. I'd appreciate if someone can give me any advice on this. Not sure if it helps but this app is self contained and no code in the app will need to be shared with any other application.
In terms of what you can achieve with both, it is the same. So, in the end, it's mostly a matter of taste.
The biggest difference is that a shared project is compiled into the app itself. It is nothing more than it says on the tin: it's a shared folder that you can use in all platform projects. Using platform-specific code is done through compiler directives.
With a .NET Standard project, you will get a physical binary. It is a project of its own. You can reuse it in other .NET Standard projects, although you already mentioned you won't be using it for that. Executing platform-specific code requires a bit different approach, using the DependencyService.
Seeing that they made a choice to replace the PCL with .NET Standard but keep the shared project points out that the shared project is here to stay for a while. I tend to like the .NET Standard library more. It feels cleaner and forces you to write cleaner code. Also, .NET Standard isn't going anywhere soon and if you decide that code should be reused down the road, you have the ability to.
A good overview, together with pros and cons can be found in the Microsoft Docs: https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/code-sharing
I'm writing an iOS application in Swift, and I'm trying to figure out how to organize the project into separate modules. I'm using an MVVM architecture, and I want to make the Model, ViewModel, and View components separate Swift modules that make only subsets of themselves accessible to the modules that import them. The files in the View would import the ViewModel, and files in the ViewModel would import the Model. How can I accomplish this? Note that I'm not trying to create libraries that multiple applications can share. I'm just trying to enforce separation of components using modules.
EDIT: Maybe the question is, "What mechanism should I use to create modules aside from the one that comes with the initial iOS application project?"
One of the answers in "How do you use Namespaces in Swift?" https://stackoverflow.com/a/24032860/215400 says, "classes (etc) are implicitly scoped by the module (Xcode target) they are in." From that, one might conclude that targets correspond to modules and that the answer is to create separate targets within an Xcode project, but I tried that earlier, and tskulbru is saying that I need multiple Xcode projects.
Regarding multiple Xcode projects, the File > New > Project > iOS Framework & Library > Cocoa Touch Framework option didn't look right because it's supposed to be for things that use UIKit, and two of the modules I want to create shouldn't depend on UIKit. The other "Framework & Library" option, Cocoa Touch static library, isn't an option with Swift.
Another StackOverflow post mentioned using private Pods. After spending an hour working on that, I concluded that it wasn't the right solution because I shouldn't have to edit these modules in different workspaces.
This isn't possible without creating separate projects for the modules you want to create. This is because the way Swift handles namespacing.
Eonil answered this better than me: https://stackoverflow.com/a/24032860/215400
(Copy below)
Answered by SevenTenEleven in the Apple dev forum:
Namespaces are not per-file; they're per-target (based on the
"Product Module Name" build setting). So you'd end up with something
like this:
import FrameworkA
import FrameworkB
FrameworkA.foo()
All Swift declarations are considered to be part of
some module, so even when you say "NSLog" (yes, it still exists)
you're getting what Swift thinks of as "Foundation.NSLog".
Also Chris Lattner tweeted about namespacing.
Namespacing is implicit in swift, all classes (etc) are implicitly
scoped by the module (Xcode target) they are in. no class prefixes
needed
From my perspective if you want to encapsulate your components, probably you have two solutions:
Framework
Internal cocoapods
Both solutions will give you fully encapsulated modules, where you can define API that will be available in project through public keyword.
All other things will be not visible in your core project.
Managing your project will cost you a lot more time, but if you write this using SOLID principles, probably you will get more reusable code and those frameworks could be imported to other project just using import definition.
Just wanted to understand there are couple of code sharing strategies exist to achieve code reusable capability in Xamarin.
Which one should i use ?
Shared Project way OR Portable Class Library way ?
if you can explain with scenarios , it would be very helpful for me.
Thanks much.
Here is the Xamarin explanation.
The question is possibly duplicated but you ask specifically for scenarios.
If you ever wrote c cross platform projects, shared projects resemble the old-school way allowing you to use #if __IOS__ statements to run device platform code in your shared/common code files. A separate assembly is created for each target (say iOS or Android). They give advantages and disadvantages of each.
PCL generates one single assembly for the common code. PCL has some limited number .net features as shown here in this table. However, most of the important .net goodies are there as you can see.
Xamarin says that shared code method is easier but PCL is easier to compile a module and share or sell that with others.
When I make projects, I check what external plugins/components/ etc I want to use and make a decision based from. For example, you may want to use sqlite and there are different options for using shared and PCL projects.
I understand for non-iOS targets, using shared libraries can lead to lower memory usage, and also that some companies distribute a library and headers (like Superpin) and a static library allows them to not distribute the source of their product. But outside of those, what are the reasons you'd want to use a static library? I use git for all of my projects, and I usually add external libraries (open source ones) as a submodule. This means they take up disk space locally, but they do not clutter up the repo. Also since iOS doesn't support shared libraries, the benefits of building libraries to promote code reuse seems diminished.
Basically, is there any reason outside of selling closed source libraries that it makes sense to build/use static libraries for iOS?
organization, reuse, and easy integration into other programs.
if you have a library which is used by multiple apps or targets multiple platforms, then you will have to maintain the build for each app. with a library, you let the library maintainer set up the build correctly, then you just link to the result (if it's developed internally, then you'll want to add it as a dependency too).
it's like DRY, but for projects.
libraries become more useful as projects become more complex. you should try to identify what programs (functions, class hierarchies, etc) are reusable outside of your app's context, and put it in a library for easy reuse - like pattern recognition.
once your codebase has hundreds or thousands of files, you will want to minimize what you use, and you will not want to maintain the dependencies manually for each project.
Also since iOS doesn't support shared
libraries, the benefits of building
libraries to promote code reuse seems
diminished.
There's no reason you can't build your own static library to use across multiple projects.
Other than for that purpose and the ones you mentioned I don't think there's much else.
Static libraries allow you to have truly standalone executables. Since all library code is actually, physically present in the executable, you don't have to worry about the exec failing to run because there's a too-old version of some library, or a too-new one, or it's completely missing, etc. And you don't have to worry about your app suddenly breaking because some library got replaced. It cuts down on dependencies and lets your app be more encapsulated.
I have a large exiting C++ project involving:
4 applications
50+ libraries
20+ third party libraries
It all builds fine on Windows using VS8, Linux using QMake (project uses Qt a lot). I also build it on OS X using QMake but I was wanting to setup an Xcode project to handle it in an IDE. I'm struggling to setup proper configuration to easily define dependencies, both to internal libraries and to the third party. I can do property sheets and .pri files in my (disturbed) sleep, but would appreciate some advice on building such large projects in Xcode.
I've been experiencing with Xcode configuration files and #including one from another but it does not seem to work as I would expect, especially when defining standard locations for header files etc.
Is there some good book describing the process of setting up Xcode (remember it's C++, I'm not wanting to learn ObjC at this time)?
Or maybe a good open source project I could learn from?
Thanks!
Step in to Xcode may be the book you're looking for. It's got a whole section devoted to using AppleScript to automate configuration includes. I've been going through the book myself on O'Reilly Safari as I've found myself in a situation similar to yourself!