Are there any alternatives for webkit.framework?
Is there for example a "ChromeKit.framework"? (Doesn't appear so from what I searched).
Is it not allowed by Apple to have competing browser frameworks available, or does no one simply care to make one?
Reason I ask is the appalling svg/canvas performance in webkit framework.
Edit: Found this: http://en.wikipedia.org/wiki/Chromium_Embedded_Framework
But there's no .framework available to just link in xcode 5. It also seems outdated (instructions). Anyone used this with xcode 5?
Edit: Well, I downloaded the 64-bit Mac CEF archive again today and this time it did not compile with the instructions I gave earlier. It was necessary to make some more modifications both to build settings and to source code (replacing some deprecated methods).
Updated answer:
Latest builds of the Chromium Embedded Framework 3 can be found here, the latest being from 10 days ago (2013/12/10). The Mac OS X 64-bit build includes a sample Xcode project for OS X 10.7 Lion which needed some modifications to compile successfuly on 10.9 Mavericks / Xcode 5 (see below). The build product cefclient.app is a simple bare-bones web browser.
The following instructions are for building the Chromium Embedded Framework and test apps on 64-bit Mac OS X 10.9 / Xcode 5 from the CEF release archive: cef_binary_3.1720.1548_macosx64.7z, currently downloadable from the CEF builds page. It may be necessary to Build after each source code change to show more issues.
Extract the 7z archive.
Open cefclient.xcodeproj/project.pbxproj in TextEdit and replace all occurrences of "10.7" with "10.9" (no quotes), and "10.6" with "10.9" (no quotes).
Open cefclient.xcodeproj in Xcode 5 and attempt to Build it (cmd-B).
In the "Issues" pane find "cefclient project" issues and click
"Validate Project Settings / Update to recommended settings" ->
Perform Changes. Xcode will update the project file.
Under "libcef_dll_wrapper" issues, select the issue involving
UINT_MAX, and replace "UINT_MAX" with "UINT32_MAX" in the code.
Under "cefclient_helper_app" issues, select the
"resource_util_mac.mm" subitem to jump to the source code, and
replace the deprecated AmIBundled() method with the
following implementation:
bool AmIBundled() { return ([NSBundle mainBundle] != nil); }
Under "cefsimple" issues, select the "cefsimple_mac.mm" subitem to
jump to the source code, and replace the deprecated
...loadNibNamed... line with:
[[NSBundle mainBundle] loadNibNamed:#"MainMenu" owner:NSApp topLevelObjects:nil];
Repeat step 6 for the "cefclient issues" -> "cefclient_mac.mm"
subitem.
It should build successfully at this point. Ignore the linker warnings; I couldn't seem to fix them and everything seems to work OK regardless.
To build the smaller (~80MB) release version of the cefclient:
Click the "All" target in the top-left corner of project window ->
select "Edit Scheme..."
Select the "Run" item in the left view, and choose Build Configuration -> Release.
The cefclient and cefsimple build products will be in the #{PROJECT_DIR}/xcodebuild/Release folder, while the CEF framework will be in #{PROJECT_DIR}/Release folder.
Not exactly plug and play, eh? Let me know if this works for you.
Related
I followed the instruction of
https://dev.twitter.com/twitterkit/ios/installation
Install Twitter Kit Manually (Objective C)
Did all the steps:
Downloaded and unzip Twitter Kit.
Draged contents to the root of your project in Xcode, and made sure ‘Copy items if needed’ is checked
Initialized the kit inside AppDelegate (with valid key and secret as described)
Modified Info.Plist entries as described
=> Trying to compile it gives me an 'TwitterKit/TwitterKit.h' file not found error:
(I tried it several times...)
Some step(s) seam(s) to be missing?
Thanks for inputs on that.
If you have followed all the instructions, try to do each of the following before trying to build again, as it worked for me once.
Clean the Project, Cmd + Shift + K
Restart Xcode
Restart Computer
If nothing works, then install Twitter Kit through Cocoapods, as it does a clean installation for your frameworks.
Since I couldn't edit the original question I add my latest state.
after following instructions of neuhaus and Sau93 I ran into new issues.
Steps 1-5:
<= Here is where I stack know ?
I recently turned on stricter warnings for a project, and Xcode started throwing warnings on some of Apple's classes. I'm not sure if this is an Apple bug, or if I'm doing something wrong. I'm using Xcode 6.1.1 on Yosemite.
TL;DR: adding some strict warning flags to your project starts throwing warnings in various XC*Test*.h headers. The issue is intermittent, but the steps below have reproduced the issue on multiple computers.
Steps to reproduce:
Create a new Xcode project via File → New → Project.
Choose iOS → Application → Single View Application.
For Product Name, type MyApp. Choose Objective-C and Universal. Save the project.
Build the project with CommandB. Run the tests with CommandU. Observe that they both finish with no errors or warnings.
Click on the Project to go to the Project Settings.
Click on the blue MyApp Project (as opposed to MyApp or MyAppTests targets).
Click on the Build Settings tab.
Search for Other Warning Flags.
Enter the following string for the Other Warning Flags for the app:
-Weverything -Wno-objc-missing-property-synthesis -Wno-objc-property-synthesis -Wno-direct-ivar-access -Wno-assign-enum -Wno-float-equal -Wno-sign-compare -Wno-switch-enum -Wno-gnu -Wnewline-eof
Build the app again. You should see three or four warnings about treating #import as #import, which is expected given the warnings you just enabled.
Clean the project with CommandShiftK
Build again. You may see extra warnings. If not, then you need to…
Delete the DerivedData folder, at least for this project. It is located at /Library/Developer/Xcode/DerivedData/MyApp-*, where * is some random identifier string. You may also need to delete /Library/Developer/Xcode/DerivedData/ModuleCache.
Clean and build again. And again. It may take a few times. Eventually...
You will see code and documentation warnings on XCAbstractTest.h, XCTestCase.h, and XCTestSuite.h. Screenshot:
As you can see, these warnings would be quite valid on my own code, but this is Apple’s framework code. Is there any way to stop these weirdly intermittent warnings from appearing? Or is it an Apple bug that the file gets warnings at all? I’m leaning Apple bug, because plenty of other Apple headers use #import instead of #import, and none of them is throwing warnings.
Update: I filed a radar: http://www.openradar.me/20038246
Update 2: I was able to glean some more information that may be helpful:
The issue appears to be at least partly related to where Derived Data is stored. See this screen recording, courtesy of Sam Marshall for details: http://cl.samdmarshall.com/a4Hy
Note that, when I reproduce the same steps as in Sam's video on my computer, I am not able to get rid of the extra warnings. They always come back. Possible differences between my and Sam's setups:
Sam is on Xcode 6.1, while I am on 6.1.1.
Sam is on Mavericks, while I am on Yosemite (10.10.2).
When I build in Xcode 6.3b2, I get an additional warning about "building module 'UIKit'". See screenshot: http://cl.ly/a3sK
Update 4: Radar was closed as a duplicate of an issue.
Update 5: I have a workaround, which is to disable the problem warnings on the Tests target only. Here’s a partial diff. Xcode won’t add the $(inherited) automatically, so you’ll have to add it yourself.
+ WARNING_CFLAGS = (
+ "$(inherited)",
+ "-Wno-documentation-unknown-command",
+ "-Wno-auto-import",
+ "-Wno-incomplete-module",
+ );
I have used Phonegap several times but since the upgrade to Mavericks / Xcode5 everything has changed.
If I try to create a helloworld project, everything looks good: it compiles and launches the simulator or installs the app on my phone. The problem is if I try to add any Phonegap functionality, the it just won't work.
UPDATE: this is how I'm creating the project:
cordova create helloworld
cordova platform add ios
I have tried directly opening helloworld.xcodeproj in Xcode, using the "cordova run ios", "cordova prepare", "cordova build" commands but none of them seems to make any difference (some of these create and copy a lot of files, but there is no difference regarding the access to "device" variable)
The only way of debugging I have managed to use is to show alerts and try/catch blocks like this:
try {
alert(device);
// var text = '';
// var i = 0;
// for (var attribute in window) {
// text = text + '\n' + attribute;
// i++;
// }
// alert("total " + i + " keys: " + text);
} catch (err) {
alert(err);
}
Trying to read from "device" variable results in the following:
The text on this error suggests that one should use the following command
phonegap plugin add thePlugin
That indeed works: it adds the desired feature on the config.xml file, but the problem persits, so it does not look like an issue related to permissions. The same thing occurs when installing and trying to use other plugins, such as accelerometer or notifications.
I really liked Phonegap because it made things easier, but now it seems the opposite. One optoin is to use an older version of Phonegap and/or Xcode, but that's not what I'm looking for.
So, what is my configuration?
Mavericks 10.9.1
Xcode 5.0.2 (5A3005)
Phonegap / cordova 3.3.0
iOS 7.0.4 (iPhone 5) --> or the emulator
Any clues?
Thanks
I finally managed to solve this issue.
The solution is simple, yet it was difficult to detect.
Every time you add a plugin using the following command: cordova plugin add thePlugin you then need to run the cordova prepare command again. This is tricky, because if you take a look at the code after adding the plugin there is some setup/changes made. But these changes aren't enough, so cordova prepare might first seem redundant, but solves the issue.
So:
create the project
add as many plugins as you might use
start developing either:
(a) directly on the generated YOURAPP.xcodeproj file, and NEVER run
the cordova prepare commmand again, otherwise you will delete all your
changes
(b) work on the "general" www folder of your project and then run cordova prepare everytime you need to create a new version. Note:
you'll need to close the xcodeproj file in order to see any changes
I tend to think that alternative "(a)" should be the optimal, just make sure you don't overwrite your files or keep your files properly versioned
When I run my tests in XCode 5, the main window of my OS X app appears on the screen for a couple of seconds while running the tests. Why? Even if I uncomment all my tests it still opens my main window.
You are running application test, not logic test. This means an instance of your app will be started and then run the unit tests. This allow you to perform some integration test that require your app is running.
Here is the guide to setup application test and logic test.
If you want to change it to logic test (so it run faster and don't need to start your app first):
go to build settings for your unit test target
search Bundle
remove Bundle Loader and Test Host
Thats right, you have to delete the "Bundle Loader" and "Test Host" from your build settings.
But you have to add the necessary implementation files to your unit test target. The necessary files are what you want to use in your unit test cases. You need to do this because in logic tests XCode wont compile the whole application. So some of your files will be missing.
This is en error message if you have left out a file:
Undefined symbols for architecture i386:
"_OBJC_CLASS_$_Module", referenced from:
objc-class-ref in Lobic Network.o
objc-class-ref in Logic_Unit.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
You can add the missing files by selecting the implementation file and bringing up the file inspector. There will be a section named "Target Membership" and there you can set the files target membership to your unit test also.
With XCTest, application files DO NOT need to be included within XCTest targets. The XCTest bundle is linked against the application which makes those files available during runtime.
To make this work, ensure the compiler option "Symbols hidden by default" is set to NO Within the Application target.
Here is a blog post with screenshots for clarity:
http://zmcartor.github.io/code/2014/02/24/slim-xctest-targets
The advantage of this approach is test target builds much much faster.
In XCode 7, removing Host Application does not work for me. Indeed I use the following to avoid app runs.
Setup Test Scheme Arguments
in main.m
static bool isRunningTests()
{
NSDictionary* environment = [[NSProcessInfo processInfo] environment];
NSString* testEnabled = environment[#"TEST_ENABLED"];
return [testEnabled isEqualToString:#"YES"];
}
modify main()
int main(int argc, char * argv[]) {
#autoreleasepool {
if (isRunningTests()) {
return UIApplicationMain(argc, argv, nil, nil);
} else {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
}
If the tests are for code that can run on desktop and mobile, you can run them without a simulator or hosting them within your app.
The trouble is that you cannot use the scheme chooser for your normal target (desktop or iOS) to run the test.
The following worked for me in Xcode6.
File > New Target...
Select Cocoa Testing Bundle from the OS X category.
Take care to select None from the target drop-down.
Click Finish. Add the relevant files to the new target as described above.
Now create a scheme to run the test.
Click the schemes chooser top-right and choose New Scheme..., click the drop-down and navigate down the list to the new target. Now you can choose the scheme from the schemes chooser, and use ⌘U to run the tests.
I just wasted a morning on this.
Project was created in XCode 4 and used SenTesting.
Tried migrating tests on XCode 5/XCTTest
Had same issue - app ran in simulator and test never started
after trying everything (change from app to logic tests, change to XCTest, remove SenTesting)
gave up created a clean XCode 5 project.
Added all my files in and tests ran ok.
May still have issues with Storyboard as these were built with XCode 4.
Drastic but it works so keep it as last resort.
On XCode5, the app does start. This answer shows how to change its delegate when running unit tests so that it exits right away: https://stackoverflow.com/a/20588035/239408
I have a C++ Builder application I'm porting from C++ Builder 6 to XE on Windows XP.
A number of 3rd party controls are in use as well.
I'm compiling with Dynamic RTL = False
If I compile without run time packages I get the subject error message:
[ILINK32 Error] Error: Unresolved external 'SHCreateItemFromParsingName' referenced from C:\PROGRAM FILES\EMBARCADERO\RAD STUDIO\8.0\LIB\WIN32\RELEASE\VCL.LIB|Dialogs
If I compile with run time packages the error goes away.
Googling around reveals the SHCreateItemFromParsingName has to do with common control dialogs one can invoke with WinAPI calls.
All 3rd party controls I use work in a new/separate project; thus this problem does appear to be a simple #define or something.... (not sure)
I can not find anything in my project source that would cause this. I do have an TOpenDialog and a TSaveDialog in my project that replaced an older TMC components of the same names (TntOpenDialog, TntSaveDialog) that were used in CBuilder6 to give Unicode support for the same. Converted to the ones that ship with the VCL has not resolved this problem.
There is an Embarcadero thread on this but that person appear to solve by creating #define's to build their app for WinXP and new compatibility. Under XE, I set the C++ Compiler option to target Windows XP and newer and that did not work either.
Tried adding:
"#define WINVER 0x0502"
"#define _WIN32_WINNT 0x0502"
per MSDN link here:
http://msdn.microsoft.com/en-us/library/aa383745%28v=vs.85%29.aspx
to no avail.
Other than the Open/SaveDialog components, anyone have any advise or seen this before?
OK, spent two days on this and as soon as I post it here, I found the solution.
Under the Build Configuration (right click | edit )
Under Application there is a check box "Enable runtime themes" that was unchecked.
Checked it and problem now gone.