I have the following case. In my not-compiled project I have included ( in html file) :
extjs-all.js
my api.js ( that generates the remote calls)
app.js
When i compile my app i get one single file that contains extjs library and also my app files. I can't get it to work because i have no place to include my api.js. I can't included before all-classes.js because Ext.ns will not work. If i include after my all-classes.js than my stores will do not have instantieted the direct functions.
Have any idea? Do i have to keep separated the extjs library minified and the app files compilation?
I do something similar;
first comes the ExtJS libs
second the API
third my custom classes/extension (none of them uses the API)
fourth comes the Models, Stores
fifth the rest of your application
If this don't work you should do necessary refactorings to make it work cause you may end up with problems otherwise.
Related
I created a Swift 5.1 app with Xcode 11.0 which contains c-files and h-files.
A bridging header was automatically generated by Xcode.
I entered the necessary #imports.
The project compiles and runs as expected.
Now I wanted to create a Swift-package which contains the c-files and header-files, the bridging-header file and a Swift file which is a wrapper of the c-functions.
I did it in the following way.
I opened file->new->Swift Package
I filled out the name field of the package and the add to: and group: fields
Now the Package.swift appeared in the project.
I moved the Swift files, from the project folder into the Package.swift/Sources/packageName folder.
Just for test reasons I changed to the target/General window and pressed the + Button of Frameworks, Library and embedded Content.
In the appearing List of frameworks I could find the name of my package, as expected.
I canceled the window and went back to move a single c-file into the package folder.
Then I went back to the target/General window and pressed the + Button again and now surprisingly the list doesn't contain my package name
It seems to me, that including c-files into a Swift-package requires some additional steps.
I searched in the documentation, but I couldn't find a hint.
Basically you cannot at this time have mixed C and Swift sources in the same package.
You can, however, have one target that includes all of your C-files, then have a different target that includes your Swift files but depends on your C-file target.
From your question it seems like you are missing a lot of intermediate steps. If I were you I would try to get a simple example working with just the C-files and then move on to adding the Swift target that depends on that.
I need to use an iOS .framework dynamic library with Codename One, but I didn't find proper instructions.
In the developers guide (section: https://www.codenameone.com/manual/advanced-topics.html#_bundling_native_ios_sdk) there are the following tips, but there are not seem to work:
Find the "binary" file within the framework, and copy it into your native/ios directory - but rename it libXXX.a (where XXX is the name of the binary).
Copy all .h files from the framework into your native/ios directory.
Update all #import statements in the headers from #import format to simply #import "FileName.h"
This doesn't work when the *.framework doesn't contain a static library but a dynamic one (as suggested in the answers to How to create static library from an existing framework in iOS?).
Before iOS 8, all .framework files contained only static libraries, but starting from iOS 8 Apple is permitting developers to create dynamic frameworks (as reported in https://stackoverflow.com/a/15331319/1277576).
Updated Answer:
Starting with the next update (Next friday), you'll be able to include iOS frameworks by simply zipping up the framework, and adding it to your project's native/ios directory. Eg. native/ios/MyFramework.framework.
You can still, alternatively, create a custom podspec as a part of your project. The steps are:
Add native/ios/podspecs/MyFramework.podspec with contents:
Pod::Spec.new do |s|
s.name = "MyFramework"
s.version = "1.0.0"
s.summary = "MyFramework framework"
s.description = "This spec specifies a vendored framework."
s.platform = :ios
s.homepage = "https://www.codenameone.com"
s.source = {:path => "."}
s.author = "Codename One"
s.vendored_frameworks = "MyFramework.framework"
end
Copy the MyFramework.framework into native/ios/podspecs
Build hints:
ios.pods=MyFramework
This workaround isn't perfect because the project probably isn't portable to Windows ( but it should work on Linux and Mac). The new method (zipping the framework and adding to native/ios) is 100% portable.
Original Answer:
For frameworks, you can place them inside a custom podspec. Here is a sample Codename One project that defines a custom podspec.
https://github.com/shannah/TestCustomPodspec
Notice, all you need to do is create a native/ios/podspecs directory in your project, and then you can place your custom podspecs in there. You can reference your podspec using the ios.pods build hint.
For information on packaging your .framework in a Podspec, this article looks pretty informative, starting at "Consume Framework Using Local CocoaPods"
I'm afraid we never worked with iOS dynamic library frameworks as cocoapods became universal and took over the need for working with frameworks evaporated. Frameworks are problematic as they can't be shared with PC developers since they have symbolic links within them etc. So sending them as part of the build process would be problematic.
Most cases that needed creative solutions created a custom pod.
The app starts with a blank screen for a while before the app really loads
I'm using electron-forge's react-typescript template.
I can make a dmg or deb file successfully, but I noticed when I run the packaged app, there will be a blank screen for a while before the app actually load especially the first time
I checked the distributable file and found the whole source code inside it, so I guess it's because it has to compile typescript every time?
Then how to "precompile" my source code and use that to make a distributable app?
update:
Since the project was developed by other colleague, I just found out this project is using electron-compile to compile it on the fly, maybe the solution has something to do with this?
I checked the distributable file and found the whole source code inside it, so I guess it's because it has to compile typescript every time?
This is not true. Current stable uses electron-prebuilt-compile (https://github.com/electron-userland/electron-forge/blob/1709af0bc53bd962466dd2025672b95f2e9399cc/packages/api/core/src/util/electron-version.ts#L6) which creates precompiled cache for typescript files for packaging time. Typescript source is only needed for module resolution in actual filesystem.
there will be a blank screen for a while before the app actually load especially the first time
This requires profiling application itself to find out what is happening in meanwhile. It is possible module resolution takes long or either any js execution time's blocking, but can't tell without profiling it.
I am attempting to write a reusable package in Go. I'm using a structure similar to that described here but slightly different:
/src/bitbucket.org/EXTERNAL_PROJECT_NAME/EXTERNAL_PACKAGE_NAME/...
/src/INTERNAL_PROJECT_NAME/INTERNAL_PACKAGE_NAME/...
Or should the second line be:
/src/bitbucket.org/INTERNAL_PROJECT_NAME/INTERNAL_PACKAGE_NAME/...
Everything works until I need to access a non-go file that exists in the external package. For example, I have some built in templates that I would like to be available without having to include them in my internal projects templates directory.
To that end, I have a "templates" directory in the external project where I want to house some built-in templates and a "templates" directory in my internal project where custom templates will go. But when I attempt to parse templates from the external project template directory, it can't find them.
So how would I go about indicating that I want to get the templates from the external package directory instead of the internal one? I could adjust the path to something like the following:
../../bitbucket.org/EXTERNAL_PROJECT_NAME/EXTERNAL_PACKAGE_NAME/templates/file.html
but this is obviously very clumsy and depends on individual setup, so that's not going to work. In general, if I want to reference a file in an external package instead of my internal project directory, how would I do this gracefully?
Thanks!
Turns out there is a pretty simple solution. Looks something like the following:
package main
import (
"bitbucket.org/EXTERNAL_PROJECT/EXTERNAL_PACKAGE"
"go/build"
)
func main() {
SrcRoot := "/src"
PackageDir := "/bitbucket.org/EXTERNAL_PROJECT/EXTERNAL_PACKAGE"
InternalTemplateDir := build.Default.GOPATH + SrcRoot + PackageDir + "/templates/"
}
GOROOT here provides us with the path to the directory containing all our go code. From there, I want to reference the templates directory in the package source. With InternalTemplateDir, I now have the base path from which to reference templates within the external package.
For ease of use, I will probably build a template loader that checks for a file on an internal file path first and then checks for the same file in the external package, so that any given template can be overridden by including it internally, but essential templates will all have built in versions as well.
If it's not a Go package (aka bitbucket.org/EXTERNAL_PROJECT_NAME/EXTERNAL_PACKAGE_NAME/file.go) it's not gonna work, your best bet us something like https://github.com/jteeuwen/go-bindata.
But I really think you should rethink your problem and use a different approach to it.
I'm using Prism 4 with Unity. I have a main project, and a module. The module is created as Silverlight Applications, so it builds a separate xap file.
I load the modules in the Bootstrapper's ConfigureModuleCatalog, just like the documentation states.
var moduleType = typeof (MyModule);
this.ModuleCatalog.AddModule(
new ModuleInfo
{
ModuleName = moduleType.Name,
ModuleType = moduleType.AssemblyQualifiedName,
InitializationMode = InitializationMode.WhenAvailable,
});
Everything works fine, but I notice that my main xap file also contains the dlls associated with my module. So, I set Copy Local = False on the module reference, and it builds correctly with the module dlls only in their own xap file.
But now my app won't run because I can't get the type information for MyModule. I get a FileNotFoundException.
I found that I can drop the reference entirely if I manually enter the ModuleName and ModuleType, and also set Ref = "MyModule.xap" on the ModuleInfo. This works fine, but here's the problem: I build frequently and use dynamic verion numbers. So the AssemblyQualifiedName changes too easily. Without the reference, there's no way to get it dynamically. If I drop the version number from the AssemblyQualifiedName, it doesn't work.
Surely there's some other way to get the module to load from its own xap file without it ending up also in the main xap?
Nevermind...
After researching further, it seems my mistake is in using wildcard versioning in the assembly version. It is suggested on many sites to use the wildcard in the assembly FILE version only, and use fixed version numbers on the assembly version. Then I can just drop the reference and refer to the module by its strong name with fixed version number.
I was so locked in to prism on this one. I didn't figure it out until I thought about assembly location in general. The post that solved it for me actual was about resolving sharepoint parts. Just goes to show sometimes you have to think outside the box.
Update
Looks like you can't use the wildcard in the file version... grr... I found an add-in that will work though http://autobuildversion.codeplex.com/
Anyone got a better idea?