How can the earlier created 32 bit titanium app be converted into 64 bit app,what are the requirements for the titanium app to have 64 bit support??
Titanium iOS apps need to be 64 bit for a first upload by now as standard or if it's pre existing in the App store this won't have to be done till June 1st.
First make sure you are compiling your apps for Titanium 3.5.0 or greater. Download this and then rebuild your app against this.
Next you'll need to make sure all included architectures are 64 bit.
You can check any pre existing included modules comply or if they need updating via this handy NPM cli tool - Usage and how to install are included on this page.
https://www.npmjs.com/package/ti-64
This will then list any modules that need updating. You have two options here, wait for the author to update them for the change or be pro active and compile the module to be 64 bit yourself.
If you open up the module in xCode you can specify a new architecture to build for and compile it again.
This article covers all update needs:
http://www.tidev.io/2015/01/09/how-to-update-your-app-and-modules-for-64-bit-support/
Related
Im developing an application that would detect the DirectX versions installed on my system. For example if DirectX 9 and DirectX 11 are installed on my system then my program must detect these installations and display the installed versions. But I've no idea on how to accomplish this
EDIT:
I dont want to use dxdiag UI to detect the versions, I want my program to detect the versions. And all installed versions must be detected not just the one that is pre-installed with the OS or the highest level supported by the OS
You'll most likely not be able to list all installed DirectX versions. I came across this interesting article in the support pages of the gaming platform called Steam:
Trying to manually check for the correct versions is extremely complicated because there are numerous files that must all be present and individual system configuration options like dll search paths complicate the situation. In addition, the dependencies and required checks may change in each new version of the D3DX runtime.
As mentioned by Hans Passant you can get the highest installed version by running dxdiag /x <output file> to generate an XML file containing various entries of your computer information, then parse or deserialize that file in your application.
While developing with IBM MobileFirst studio I've found that after building iOS/Android environment and generated native projects, even a blank app (e.g a quite simple Hello World Android app which do not use any native functionality), will take size more than 4Mb which is much larger than a real native exported Android apk file.
So are there any unused resources that can be deleted or other things we can do so that we can lose weight in the final exported apps?
Another detail, the classes.dex file inside the 'blank HelloWorld'apk file seems larger than a common apk file (4Mb size).
Starting MFP 7.0 you can now minify and concatenate mobile environments. This means that in addition to added security, by reducing the amount of files and contents of files, it can help - to some degree - with the filesize of the application.
Read more about application build settings
MFPF 7 supports by default many more hardware architectures. This support is required if you intend on using features such as JSONStore and others. The files adding this support are located at your-app\android\native\libs (arm64-v8a, armabi, armabi-v7a, mips, mips64, x86, x86-64). So if you know you're not using JSONStore for example, see if removing some or all of these files helps you. But also do a regression test in general to make sure that the app continues to work as required. I could be wrong about the scope of these files - which add 3.4MB on disk.
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'm prepping an application for submission to the Windows Store that utilises the Bing Maps API - as such, the app has to be compiled to target specific architectures. Whilst there is a guide to submission, it's not clear how to submit both Arm and x86 configurations of the same app. Is it even possible, or will there have to be in the store twice?
When you select the option to create your app package from the Visual Studio Store menu, you get a choice to select the package architecture. There are 4 options: Neutral, x86, x64, ARM.
If you select Neutral, then it builds a single package for "Any CPU" that you can upload to the Store. If you select x86, x64 and ARM, it will build a package for each of these configurations, and you will have to upload the corresponding packages for the architectures you wish to support.
Additionally, if you're building to submit to the Store, make sure to always select Release for each of the selected architectures.
There are cases where some references don't support building using a Neutral architecture. The Microsoft Visual C++ Runtime Package is an example.
Taken from here:
The process of engineering for ARM was different for each language (JavaScript, C++, and C#/VB), based on existing implementation details
of the various runtimes and compilers.
JavaScript uses a JIT compiler, so platform targeting is taken care of at runtime. Therefore Metro style apps using JavaScript are
platform neutral, and you can write once to run on x86/x64/ARM.
C# and Visual Basic are also abstracted from hardware differences. They compile to MSIL, which is platform neutral. Therefore, Metro
style apps using C# or Visual Basic can be compiled once to run on
x86/x64/ARM.
C++ is close to the metal, and compiled to the machine language for
the platform that you’re targeting. This offers developers full
control, but also requires that they specify the hardware where the
app will be supported.
The essence of it is that pure .net or pure html/js will run on any architecture without problems. If you want C++ then you will need to compile your app once for each supported architecture. My understanding is that you can create an app package which contains installers for multiple architectures in this case.
The post here has some good details on packaging your app for multiple architectures. Here are a few highlights:
7.In the Select the packages to create and the solution configuration mappings section, select the check box for each build configuration
for which you want to create a package.
The build configurations grid lists the possible platform
architectures of the package (that is, Neutral, ARM, x64, and x86). In
each row, a combo box displays the combination of the current Solution
Configuration and Architecture choices that are relevant for that
row’s architecture. The check box for the default platform is set to
the current, active project platform. The combo box for the Neutral
row show the Solution Configuration combinations that contain AnyCPU
as the project’s platform. If no Solution Configuration combination is
relevant, the entire row for that platform is unavailable for
selection. One package is produced for each configuration that you
specify.
8.For each build configuration that you specified, choose the Solution Configuration that you want to build.
When you package an app for the Store, you can specify Release or any
custom solution configuration that you’ve created.
A package will be created for each build configuration that you
specified.
From here we get this:
7.Click Packages to upload your app's packages.
And finally from the previous link:
Signing and publishing
After your app passes the certification testing, its packages are
digitally signed to protect them against tampering after they have
been released. When this phase begins, you cannot cancel your
submission.
Note It might take some time for your app's listing to appear in
search results. This is normal. Also, you can't change a release date
after you submit the app to the Windows Store, but you can cancel the
release, update the release date, and re-submit.
Overview: During the build process you specify all architectures you want your app to work for and it creates a package for each. During the submission process you select all the packages you built for that app. When submitting you app this way only one version will show up in the store.
If you build just a HTML5/javascript Windows Store app, it work on all version (ARM, x86 and x84)
If you create something web with bing api. No worry about what platform doesn't work.
Answer is here: http://developer.android.com/google/play/publishing/multiple-apks.html
TLDR:
Go to your Google Play app developer console
Choose your app
Select APK on the left
Turn on Advanced Mode
Upload your ARM apk
Upload your x86 apk
Google will figure out the rest
I have Cocotron set up, I have compiled the Foundation for Windows, and I have set up a project that uses that Foundation. I can't compile the project for Windows though, nor have I been able to find a guide to do so. Does anybody have any ideas to do this?
Start with a working Mac project. Duplicate the Mac target and change its name to Windows, and change the build settings as described here: http://www.cocotron.org/Tools/Build_Settings/?path=Tools/Build_Settings
It's actually shockingly easy. Note that if you use the script at Cocotron/1.0/bin/retargetBundle, you don't even need to figure out how to install the Foundation DLL.
Make sure you add Cocotron's Foundation.framework to your project: Cocoa.framework doesn't actually include Foundation and AppKit properly like it does on OS X.