I used to use a custom Blend behavior to bind an enum on the ViewModel to VisualState's that were named the same as the enum enumerations.
However after including references and then including the usings, it seems the Bahaviors SDK is not currently supported.
What is the current best way to change VisualState in a MVVM way in a Windows 10 Universal App?
"Behavior SDK" can be included by right-clicking on References -> Add Reference -> Universal Windows -> Extensions -> Behavior SDK.
Some of the APIs have been changed, so Behavior<T> is not there to inherit from (use DependencyObject, IBehavior instead and implement the IBehavior interface). Also VisualStateUtilities.TryFindNearestStatefulControl is now VisualStateUtilities.FindNearestStatefulControl. When I imported my old behaviors and couldn't resolve the references even with the Behavior SDK referenced, it made me think that the imports had not worked (especially since there is a warning about importing the Behavior SDK which claims it might not work - the link to find out more information is dead which hardly inspired confidence!).
Related
I have a requirement to create a framework for a shared set of common utilities that we plan to use in multiple iOS projects in our organization. The utility classes are written in swift and the framework needs to support projects in iOS 7 and above. I'm using Xcode 6.1.1.
I tried creating both a 'Cocoa Touch Framework' and a 'Cocoa Touch Static Library' and can't seem to get it working for iOS 7 builds.
With 'Cocoa Touch Framework', I get a warning that 'Embedded dylibs/frameworks only run on iOS 8 or later' and though I can get it to run, it fails during the iTunesconnect step with an error that the project's deployment target must not be less than 8.0 (mine is 7.0).
I tried with 'Cocoa Touch Static Library' as well using the steps given in http://www.raywenderlich.com/65964/create-a-framework-for-ios, but it just does not build with swift files. When I remove all swift files and add Obj-C files, it works properly.
Any help is greatly appreciated. How do I create a framework for a swift project with iOS 7+ support?
Thanks
Unfortunately, you cannot. It's one of the more disappointing factors about Swift.
As shown in the documentation, you cannot make a static framework/library with swift and dynamic libraries are only supported in iOS 8+.
The only option I recommend is that you develop an Objective-C static framework for iOS 7 and then begin to use swift when you wish to drop iOS 7 support. It's not the most ideal situation, but because you are able to have mixed languages in a dynamic framework, it means you won't have to waste time rewriting code (unless, of course, you want to).
Apple not supporting pure Swift frameworks before iOS 8 is somewhat hurting Swift adoption rate.
I'm not advocating the following solution as best practice. Honestly, it's a very flawed hack. We have a large pure Swift framework that does most of the heavy lifting for things here at work. And, we needed that framework in a product that ran on iOS 7.1+.
Here is the hack - Directory hierarchy is important. In an ideal situation, the project and the framework are siblings in the directory tree. Create a group in the project. In Finder, shift/command select all of the source files from the framework, and drop them into the newly created group. Make sure not to copy the files. Your telling Xcode to simply add the files to the project file, creating relative path links to them.
The framework should now compile directly into your project. I can't emphasize enough how fragile this solution is. As files are added to your framework, they also have to be added/linked into any project that you've "link embedded" the framework.
This "solution" should only be used as a last resort. Having to repeat framework parity across multiple projects is dumb. If time goes by with the project staying static, and the framework evolves, dump the framework in the project, and re-add it. It takes less than a minute to dump/re-add the framework, and reduces the chance of error.
Apple, please help us, so we can maintain best practices. I'm embarrassed to share this solution, as it's just a horrible way to get around something Apple is not supporting.
I have tried to use EiffelStudio for a small Eiffel project and I have realized that its autocompletion feature (press the . and then a feature list will appear) does not work for local entities the type of which come from the Eiffel library.
For example:
a local set : ARRAYED_SET[STRING] wont be autocompleted when writing "set.".
when using the construct if attached item(some_key) as localitems, "localitems." won't be autocompleted
I use Eiffel Studio 14.05 (x86/64) on Linux Mint. I downloaded ES from the official site. How can I tweak the software to autocomplete local entities, too?
I've just tried auto-completion with EiffelStudio 14.05 and it works for both local entities and object test locals (I used a precompiled library in a project created from scratch). It definitely does not work if a project or a particular class was not compiled. If this is not the case, it makes sense either to provide some more details about the situation that causes the issue or to submit a bug report at their support site with the description.
EDIT: The issue seems to be present in EiffelStudio 14.05 when editing generic classes.
I'm exploring Swift with Xcode-6 and so far so good although I think the new collections need a little bit of work as I've managed to break the compiler a few times.
Problem is I'm now stuck trying to create the framework package to then use in another project. The project builds without issue and all tests pass successfully. When I go to create Archive (which I assume is what is required) I receive the error:
:0: error: underlying Objective-C module 'Sample' not found
Now I assume this has something to do with the contents of my Sample.h which tells me
// In this header, you should import all the public headers of your framework using statements like #import <Sample/PublicHeader.h>
which is fine except I have only used swift enums, structs and classes for this framework so therefore no .h files exist.
Can anyone shed some light on this one as I can't find any documentation available yet?
EDIT (7/27/2018)
The information in the answer below may no longer be accurate. Your mileage may vary.
I sat down with an engineer and asked this exact question. This was their response:
Xcode 6 does not support building distributable Swift frameworks at this time and that Apple likely won't build this functionality into Xcode until its advantageous for them to do so. Right now, Frameworks are meant to be embedded in your app's project, rather than distributed. If you watch any of the session videos or see the sample projects, this is always the arrangement. Another reason is that Swift is very new and likely to change. Thus your Swift-based framework is not guaranteed to work on the platform you originally built it on.
Slight Update
The engineer mentioned that it's not impossible to make a framework for distribution, just that it's not supported.
I was able to get past the error by going to the target for the framework and on the Build Phases tab under Headers, remove the MyFramework.h file
However I was getting the "Underlying Objective-C module not found" error when I was using a framework to share code between a containing app and an app extension, both of which were pure Swift.
Assuming you are creating a truly pure Swift module, you must disable the Objective-C Compatibility Header and any generated interface headers so the compiler doesn't go off assuming it can find an Objective-C module for the framework.
Do Not remove your public framework header. You'll get a module-map warning at link time if you do.
You might find this useful: Creation of pure swift module
In short: it's possible to make static framework, but there is one issue: it doesn't work in end user' project if "ProjectName-Swift.h" header included.
But, it works fine if you use only swift.
I think it's a bug in XCode 6, or that Apple does not allow archiving the Framework from XCode while in beta.
If you compile to profile XCode generates the framework correctly. (See the Release folder created in DerivedData)
I'm currently working on a project which source code should be as portable as possible; that is, the project (in C#, but it is not very relevant) represent an application that should be executed on Android (with Mono-Android), on iPhone (with MonoTouch) and WinMobile (with official Compact Framework). Without going into details, the corresponding MSBuild solution consists of an independent-platform library (from a source code point of view, at least) which declare various interfaces and classes that represent an abstraction of each feature that is not common to the various platform (i.e. the UI). In addition, there are a corresponding library that specialize (for each platform) the "base library"; the effective application executable is a program that uses the abstraction and the common standard libraries.
Developing on WinMobile and Android is not really a problem: Mono-Android add-in can be installed on VS 2010, so both platforms can be handled with MS VS.
Initially the solution was created in VS, so the initial configuration and the related projects (Android and WinMobile) are automatically generated.
After that I've imported the solution in MonoDevelop under Mac (the only platform that is officially supported by MonoTouch), and I've created the project for the iPhone library; switching the configuration to generate the assemblies (iPhoneSimulator) the "base library" was not possible to compile due to a missing project type configuration; specifically, the GUID used by MonoTouch for <ProjectTypeGuids> is {E613F3A2-FE9C-494F-B74E-F63BCB86FEA6}; adding this GUID I can now compile "base library" in MonoDevelop.
The problem arises when I try to re-import the solution in VS: since there's no Windows version of MonoTouch, VS cannot find the add-in for the specified project type, and the project doesn't load.
Looking to the specifications of MSBuild project file, it seems that there are tons of options that cannot be set or modified within the project/solution editor in VS; however the format is quite complicated and now I'm asking your help!
Is there a way to specify in the project file that a project type is present only if a particular configuration is selected independently to which is the environment I'm using?
The general approach is something like this; a condition that progressivly builds your property, referencing any value the property already may have:
<ProjectTypeGuids
Condition="'$(BuildingInsideVisualStudio)' != 'true'"
>;{E613F3A2-FE9C-494F-B74E-F63BCB86FEA6}"</ProjectTypeGuids>
<ProjectTypeGuids>{OTHER-GUIDS-HERE}$(ProjectTypeGuids)</ProjectTypeGuids>
This will detect the VS condition (when building) and omit the unkonwn guid. I'm not sure however if it will work when the project is opened, this property might only apply to building. There may be a similar "sentinal" property for building on Mono, and you can reverse the condition.
I solved an unrelated, but very similar issue of cross-platform development by excluding the files that presented themselves as cranky when going between Linux and Windows. I have my project under source control and utilized that to keep things working cooperatively.
http://www.aydabtudev.com/2011/05/what-goes-into-source-control-android.html
It's not a 1-to-1 for your issue, but it might give you clues/ideas on how to solve your problem.
I've build a static library working nice in a Cocoa Touch environment. Now I'd like to compile it also for Cocoa.. Can I have a single XCode project with different sdk targets? Is there some resource out there able to give hints about best the practices in this (and other) sense?
This last two months I have been working on exactly this task ( cross compiling static library for iPhone/Android/Mac OS/Linux/Windows...
It is certainly possible, a nice way, is adding an external xcode project as a target to your first xcode project. So you create a new "Active Configuration" for Mac OS X, iPhone and other platforms that you want to support.
Here, you can find a good tutorial about how to use a secondary Xcode project as a target of your main project to build a static library. It's a cool way because if you debug for example you still have all the symbols of the library, etc.
It can be done but it requires some manual tweaking of the build.
Start with the Xcode Build System Guide.
As an informal way of accomplishing this, you can create two separate projects and add references for exact same set of library source files to each project. Set one project to compile for Cocoa-Touch and the other for Cocoa. If both projects reference the same files, changes made in one project will be automatically reflected in the other. (If you have both projects open, Xcode will complain that the file has been changed by another app but otherwise it won't notice.)
I have a utility class that I continually dump new methods in. I add it to every project and just park methods as I need it. The new methods show up in old projects because the source files are shared across all the projects.