I'm new to KMM development and I noticed there are some references to iosX64 in one of the build.gradle.kts files. AIUI this is so that the app can be tested on a simulator on an Intel Mac. I've got an M1 Mac, the app is not open source and it's very unlikely I'll ever want to test the iOS version on Intel hardware. Is it safe to remove/comment out these references to avoid wasting build time etc on them? Or is KMM smart enough to skip them anyway when building on ARM64?
Related
Is Android Device defaultly support mono ? or
We need to install any thing on android device for supporting Mono(which the application developed by Xamarin).
Xamarin's mobile/Mac solutions use a different approach compared to Microsoft .NET. The rules are,
You don't need to install a .NET/Mono runtime on Mac or iOS or Android devices before installing an app.
When you build the deployment packages of your app (Mac/iOS/Android), Mono compiler tool chain automatically merges your binaries with Mono binaries so the final packages are self contained (they contain every bits needed without dependencies on external components). This is required by Mac App Store, iOS App Store, and various Android app stores.
Note that because that Mono bits are embedded in each packages built, those packages are slightly larger than the ones created using Objective C or Java.
I don't think it supports mono by default.
http://mono-project.com/Start
I am learning about Objective-C/Cocoa and have downloaded the source code to a popular TeX typesetter and loaded up the project in XCode to play around with it. Compiling fails, and all of the error messages I have seen (so far) have to do with something called NSSharingServicePicker not being recognized. I gather (from this SO question and this Apple documentation page) that this is a class not available in 10.7.x. It therefore makes sense why the code won't compile on my Lion machine.
My question is, I guess, why I am able to run the downloaded package of TeXShop on 10.7 at all? (According to the website, this version is for OSX 10.7 and up.) I am interested in making a few minor changes to this project; am I not able to check my changes/compile unless I'm using a Mountain Lion machine? Is there some kind of update I can download for coding/compiling purposes?
Assuming you are using Xcode 4.6.*, you should be able to set your project to use the 10.8 SDK and get past the compile errors. (That's the "Base SDK" build setting.)
I just downloaded the full 4.0.1_r1 Android Source Code repository according to the official instructions. Can someone help me understand the repository's basic naming scheme?
For example, in the root directory of the repository, what exactly is the "frameworks" directory? How does this differ from the "packages" directory?
I have spend quite a bit of time around the android source code the last few years, so let me take a shot at explaining the different folders in the root. These are roughly (depending a bit on the android version):
bionic
The standard c library used and developed for Android specifically.
bootable
Contains the bootloader (which the device manufacture normally provides) and the recovery application which is execute when the phone is booted into recovery mode.
build
Android has very unique modular build system, which itself is built on top of ordinary make-files. For example in build/target/products you will find all the generic build targets you see when you launch lunch.
cts
Compatibility Test Suite. When a device manufactures wants to get their device certified (and thus get Google Play and other proprietary apps) they need to pass the CTS. The source of CTS is contained in this directory.
dalvik
The dalvik virtual machine. Android uses java for the better part of the framework as well as for all the apps. Because each app runs as its own process under its own uid, in its own virtual machine, the virtual machine have to have a rather small memory footprint, so Android have chosen to use a custom virtual machine for Java called dalvik. The source of dalvik is placed here.
development
I haven't used this repository really, but it seems supporting stuff for developing android apps are placed here.
device
Each device vendor put all the stuff that defines their specific devices here. For example you can provide a devices/{yourname}/products/{yourdevice}.mk defining exactly which apps should be build for your device (as well as a few other things). This adds an entry to the lunch menu called {yourdevice} that you can build.
docs
As far as I understand this is actually the source of http://source.android.com.
external
Almost all of the third party projects that Android pull in and which makes up the base Android Linux OS are located here. They are maintained in their own git repositories, which makes it easy to pull new versions from upstream. You see things like bzip2, dbus, ping, tcpdump, and many other projects here.
frameworks
This is the source of the Android framework. All the stuff that you use when you build an app for Android. I think it is somewhere around 50% Java code and 50% C++ (and sometimes C), which is bound together using jni. When you for example play some audio in an app, you are probably accessing AudioManager. The source of AudioManager as well as all the internal Android source supporting AudioManager is placed under frameworks/base/media. You will find the bulk of the Android SDK implemented somewhere under frameworks/base/.
hardware
Android talks to a set of libraries which then controls the hardware (such as vibrator, lights, proximity sensor, gps, audio, etc.). These libraries are collectively called the HAL (Hardware Abstraction Layer). Some default implementations are contained in the hardware folder, however manufactures implement their own libraries and place them in hardware/{manufcaturename} (or in device/{manufacture}).
libcore
I don't know about this one.
ndk
The native development kit which allows app developers to code some (or all) of their apps as native code (in c and c++ usually). Basically it is a toolchain to crosscompile to the different cpu architectures Android runs on.
out
All Android build artifacts are placed here. So removing the out folder will clean the sources completely. out is divided into different folders, the main ones are host and target where stuff compiled for the host machine (e.g. adb) and for the target device (most of the android system) are separated. There are further subdivisions below, and in general the out folder is quite nicely sorted, so you should just explore it a bit yourself.
packages
These contains all the default apps, providers, inputmethods, and so on, that are built along with Android. The phone app, contacts, calender, calculator, default soft-keyboard, etc, are placed here. They are not 3rd party apps, they are internal apps where many of them are build against non-public android apis. So most of the apps here cannot build against the public Android SDK (e.g. in eclipse), but have to be build as part of the complete Android build process.
prebuilt
Stuff that is distributed along with Android as binaries. The primary thing located here are the crosscompiler(s) for building Android for ARM (and now also x86). They are prebuilt such that you do not have to actually build the crosscompilers yourself. (This could be very time-consuming if you besides Android also had to compile the crosscompilers.)
sdk
All the tools that are part of the Android SDK, such as ddms, the emulator, sdkmanager, etc.
system
The core system processes running on an android device. These are native (c or c++) programs. Mediaservice is an example of such a system service.
This is all from my experience with working with the Android source, I do not have any (other) references. I hope this helps you get an overview of the folder structure.
I recently did some research on making a cocos2d app for iPhone/iPad AND Mac. I have done the iPhone/iPad route but have never done it with a Mac target. It appears that some people have added it as a target but mentioned that it is finicky and others have suggested making a separate Cocos2d Mac project that uses the same files. Any wisdom to impart here?
I believe it is absolutely crucial to have both iOS and Mac targets in the same project. Otherwise you'll spend too much time keeping one platform in synch with the other, until eventually you either manage to create a good (but still time-consuming) workflow - or end up neglecting one of the two platforms.
Ideally the code base should make as little use as possible of compiler macros. You'll want to compile both iOS and Mac code even if it's not being used for one platform. So having some classes or methods that are #ifdef'ed to Mac, others to iOS, will more often than not lead to compile errors when you switch targets. That means wrapper classes, so that you can write the same code regardless of the platform, are essential.
Right now, Cocos2D doesn't offer you to create iOS & Mac targets in the same Xcode project. The way to get there isn't immediately obvious either, because each target requires its own build settings for: Base SDK, SDK Root, Deployment Target, Architectures and possibly Compiler version. It gets worse if you also want to use 3rd party libraries (Box2D, Chipmunk, etc) because in some cases you'll be forced to create iOS and Mac specific targets for those libraries as well - if only to ensure that the library is built with the same compiler as the project's target, otherwise you can run into the strangest build or runtime issues.
I've had issues getting these platform specific targets to work within a single Xcode project without Xcode complaining or otherwise misbehaving. I haven't tried it with Xcode 4.1 and 4.2. By that time I had created .xcconfig files to host the build settings. The .xcconfig files may or may not be necessary with the more recent Xcode versions but they definitely make managing multiple platform-specific targets easier.
Long story short, the best and easiest way to do cross-platform development with cocos2d-iphone is by using Kobold2D.
Most of the 15 template projects have an iOS and Mac target in each project, you just need to select the corresponding scheme, then hit build & run. The most commonly needed platform-specific code (processing user input) is wrapped in a platform-agnostic, simple to use wrapper class KKInput.
Disclaimer: I'm the developer of Kobold2D. There's a slim chance that I may be biased. You should try Kobold2D anyway. :)
Why can't Xcode be hacked to be able to run on Windows?
Does Xcode have another programming methods?
Also, I heard that iPhone apps are made with Objective-C, so why is this not available in Windows?
Thanks
Xcode is written in Objective-C and takes advantage of a number of OS X frameworks, so porting it to Windows would require porting all the frameworks on which Xcode relies. Furthermore, Xcode also uses a number of programming tools that would have to be ported to Windows as well (some of them already are, of course).
There are several reasons that Objective-C isn't readily available on Windows:
Most development of Objective-C frameworks takes place on OS X, and a lot of the frameworks aren't open-source and thus can't be ported to Windows (they'd have to be rewritten).
There are some open-source frameworks that could be used on Windows -- for example, OS X's AppKit and Foundation frameworks are (mostly) available as part of the GNUstep project -- but these frameworks aren't widely used or supported on Windows, and sometimes lack capabilities found in their OS X counterparts.
That said, GCC is available on Windows, and since GCC is an Objective-C compiler, you could compile Objective-C code on Windows if you had the right libraries available (or didn't use any third-party libraries). But Objective-C isn't terribly useful without supporting frameworks, and those are rare or nonexistent on Windows.
Same can be said why isn't there Visual Studio 2008 for OSX.
Xcode is a big application written to set of APIs not present on Windows. Porting it would be an enormous job, maintaining it would be a big job, and there are already popular IDEs on the Windows platform.
The same reason you can't install Mac OS X on your PC: Apple chooses to make it available only to people who own their own brand of computers.
I guess that porting XCode would be close to very hard (if not impossible) but even if you were able to have a running XCode version under Windows, I guess that it won’t do what you really want it to do. I assume you want a complete iPhone SDK environment which is reliant on XCode and Interface Builder in a very tight way. That’d require the port of Cocoa Frameworks (among other things) that would be, now for real, impossible to port.
Truth is, as much as you will surely need Windows for Windows Phone development, you need a Macintosh computer for iPhone development.
On the other hand, Xcode as an IDE, is not the best in the world, so even if you managed to get Xcode and make it use, .NET (for example), I’d much rather use visual studio for that.
Actually you can install Mac OS X on any Intel CPU based machine. It is legal as you own the orginal install DVD for the OS X system. After aquiring a copy of Virtualbox or VMWare (either is great, personally I prefer Virtualbox because the display settings are more customizable). Virtualbox allows setup on initial setup while VMWare requires an extra step to ensure compatibility. You can then find the steps online to setup a virtual copy of MacOS X.
After going through the steps to install the OS in the Virtual Machine, you can then go through the process to find XCode in the Apple App Store. From there, have at it. Start programming in XCode and have a good time. Since XCode has its own device emulator you have a built in platform for iOS testing. There may be times where it is a bit buggy but that is to be expected with ANY emulator for ANY system you run.
After you get everything installed and going, sit back and enjoy the programming ride. The only catch is if you want to post anything on the Apple App store and then you will have to deal with getting an Apple Dev License. Objective C can be a bit difficult at times but, at the same time, it can be very satisfying when you solve those programming problems (as with any programming language right ;-) )
Enjoy
PS... this VM install keeps up with all updates from the Apple App Store so keeping the system updated won't be a problem.
PSS... I will not condone anyone for where their source of software is but do keep in mind, setting up a VM with VMWare or Virtualbox and an install DVD is only legal IF you personally OWN the install DVD you created the install image from yourself!