I have a game built on xcode using objective c. this game needs to be integrated with another game developed in unity3d as a part of it. how can i do this? what plugins are available to achieve this??
The thing is that.. i have a unity3d game and i have few other games inside the main game(games inside one game). these small games are already built on xcode.. now i have to use these games inside the main unity game.. something like if i chose to play one of the games it has to load that particular xcode game.. how can i achieve this?? also if this is achieved.. can i build it on unity-android and expect it to work? or do i have to do it differently for android? Please guide..
Have a look at the following resources about mixing Unity3D code with Objective-C native code:
Mixing Unity generated code with Objective-C in iOS?
iPhone & Unity3D: Integrating 3rd Party Static Libraries in Unity3D Generated XCode Projects
Unity Native Plugins: OS X
If both application modules need interact on a high frequency, I recommend a polling approach instead of SendMessage, because of a perfomance lack in the latter case.
Related
Is Xamarin.Forms considered a simple sum of Xamarin.Android and Xamarin.IoS with a shared code library wrapper? or is there more under the hood than meets the eye?
I am not talking about the shared code library because I realize it is specific to Xamarin.Forms but rather (for example) if I am to compare a Xamarin.Droid project to an android codebase of a Xamarin.Forms solution, will I find any considerable differences? Will I find any differences. Same goes for IoS & Windows...
Just to provide context; I am interested in utilizing some tools which were originally designed for Xamarin.android however my projects are Xamarin.forms solutions and it would be cool to know in advance if I am running into a rathole.
Thanks in advance you fine people.
Xamarin Forms, in the end, is a wrapper over the native API's so if you have something in Xamarin Forms you can of course port it to Xamarin Android, iOS or Windows.
Is Xamarin.Forms considered a simple sum of Xamarin.Android and Xamarin.IoS with a shared code library wrapper? or is there more under the hood than meets the eye?
At its simplest, Xamarin.Forms is a mobile application framework for building user interfaces. The definition from Xamarin's website is:
Xamarin.Forms is a cross-platform UI toolkit that allows developers to easily create native user interface layouts that can be shared across Android, iOS, and Windows Phone.
But don't simply focus on the term "UI" in that definition and think only on-screen controls. Instead, focus on the word "toolkit" as Xamarin. Forms offer so much more in addition to user interface controls that work across platforms.
Xamarin.Forms will emit a 100% native iOS, Android or UWP app – in fact the starting point of any Xamarin.Forms app is within one of those platform projects. However, that's as far as the platform-specific code needs to go. The rest of the code can all be written in one of the layers that are shared amongst all the applications.
if I am to compare a Xamarin.Droid project to an android codebase of a Xamarin.Forms solution, will I find any considerable differences? Will I find any differences. Same goes for IoS & Windows...
Just Basic API differences, which are different between forms and native
You shoud see Xamarin.Forms as the abstraction of the UI over the actual platform. Xamarin.Forms (XF) renders the UI in native platforms controls, but they are created using XF XAML.
Coding against XF is like coding for a different platform with a different set of tools, at the UI level!
You can, if needed go deep in platform specific details if needs be via interface implementation and injection.
We are planning to go with Xamarin for our next big project.
Seems like Xamarin.Forms is mature enough to use with production projects.
But I still want to take input from you experts - should we go with Xamarin.Forms or Xamarin with MvvmCross architecture?
The project is big and critical for our customer.
We experimented with Xamarin.Forms about 18 months ago, so this experience may be dated, but we found Xamarin.Forms to be unsuitable for production projects. Granted, it is very quick to get basic data capture apps running on multiple platforms, but we found that inevitably the UI capabilities were so limited that we ended up having to write custom renderers all over the place, which complicated the code no end.
In my opinion, Xamarin.Forms tries to solve the multiple platforms problem in the wrong way - by trying to provide common wrappers around the UI elements in each platform. This means you'll always be able to do less with Xamarin.Forms than you would be able to do with Xamarin out of the box, and you will always be fighting with lowest-common-denominator implementations of the most common elements, while having to write your own code for more advanced UI.
By contrast, the MvvmCross approach aims to consolidate as much as possible of your business logic into a single library while leaving you free to do whatever you want in the UI of each platform. You can get as much as 80-90% of your code into a shared library while having complete freedom to implement the UI you want for each platform. It's a cleaner way to solve the multi-platform problem, IMO.
Xamarin.Forms is a bit of a different technology than MvvmCross. Everything depends on the size of project, how complicated the UI is. I recommend reading this article - it should give you some ideas.
since I am new in the world of developing apps for watches, and the fact that it exists for smartphones the following frameworks:
Xamarin
PhoneGap
appcelerator
kony
Cordova
...
I wonder if there exists for watches apps similar frameworks? So that you code once but run overall.
Thanks
Edit 1:
At this day (12.05.2015) regarding to the answer of a nativescript maintainer here. I will go with nativescript to start writing app for wearables.
Cordova/PhoneGap apps don't work directly on the wearable devices/watches. Cordova/PhoneGap is basically a javascript API which can run on WebKit/WebView on all the mobile OS's. But the Android Watch and Apple Watch doesn't support WebKit and so the apps developed with Cordova don't work directly on Watch devices. But if want to extend some of the features from the existing Cordova app to the wearable app, you need to create the extension app in native language and the extension should be able to communicate with the paired app on the mobile device. The extension on the Watch will have only UI and the bussiness logic etc runs on the Cordova app on the mobile. It is possible to establish communication between these apps which will drive the display on the watch devices.
I am not sure about the other frameworks you listed above on how much they support wearable devices.
As #kiran and #NRimer have mentioned, these cross platform frameworks are relying on the WebKit/WebView which is the almost universal layer supported on every mobile device. They dont run directly on the device, but device runs WebKit platform that runs these cross platform apps. So comparing the capabilities of the native app with cross platform app, native app is bigger, because it can have a hands on device hardware related features. The thing particular to the smart watches is that they mostly rely on other smart phone device, and it uses it's communication protocols, that are hardware specific, and WebKit doesnt have its hands on it.
It depends on what you're looking to do with the framework. Watch apps build off data provided by their containing app. For example if you want to provide custom notifications on the watch, the app (or server for remote notifications) constructs them. When your watch app needs information, it makes a request to the containing app. Lets say you have a group of apps that you want to provide the same notifications or functions on each of their watch apps, you could make a framework that handles these functions for the containing app. As for the watch portion, think of it as more of a display of information provided. Unfortunately i dont think there's a way to generate frameworks for watch apps yet. If you're looking to have a lot of code within the watch app this might be more difficult but for simple display of information you should be alright.
I'm quite new to developing in Flex. I've found out that it's possible to create mobile applications with Flex 4.5. So far so good, I've made an app and it's working well on my mobile phone. But there is one thing that I'm not very happy with. When I'm installing the app I also have to install Adobe Air (stand alone application). So is not realy cool and not the way to go in my opinion because this will look strange to the users of the app. And especially the users which aren't realy 'geek minded'.
Any solutions to this? Is it possible to include or embed Air in the app? It will make the filesize of the app bigger but that's a much smaller problem then having to install a complete different app next to the real app.
All the best from NL.
This feature is called Captive Runtime and was introduced in AIR 3.
To use it today, you'll have to overlay the AIR 3 SDK onto the Flex Framework of your choice (I suggest 4.5.1). Then you'll have to use command line tools to compile your app using captive runtime.
This will most likely be a lot easier when Flash Builder 4.6 rolls around.
More information
I'm very familiar with the Adobe Air runtime, and quite handy with the workings of a Flex application, but I'm unsure which technology I should use if I would like to have a multi-platform application able to be deployed to the Web foremost, Android Phone secondly, and Desktop third.
I understand that AIR is probably the route I should go, but I'm very conflicted on how integrated it is with Android? Is it easy to do now, or still a headache (I haven't read about it in ages)? I've seen the new Flex 4 deploying to Android very smoothly, but I've heard it's difficult to write an AIR program with Flex.
Any thoughts are appreciated!
You have me scratching my head here.
AIR is a runtime, not an application development framework.
Flex is an application development framework, not a runtime.
You can author your application in Flex and deploy it via Flash to the phone and web and deploy it to the desktop with AIR.
Now, if you were implying that you would develop your web app using HTML/JS/etc..., deploy that to the desktop with AIR, and then try to rewrite the whole thing in Flex, I agree... that's not a reasonable approach.
My advice is that you stick to one stack.
So, if you're going to do Flex, do Flex all the way. If you're going to do standard web stack, do that all the way (there are a lot of mobile web dev frameworks out there - jQuery Mobile is probably one of the better ones, but Ext.JS/Sencha is out there too).
Make sense?
I have not tried it, but Adobe acts as if it's fairly simple to adapt from straight Flex to Flex within AIR.
What's more important is what language the app is already in. If it's in JavaScript and HTML, then it would stand to reason that adapting that to AIR's HTML5/Javascript engine would be quicker and less frustrating than porting it to Flex and adapting it to AIR.
Additionally, it gives you a codebase you can more easily adapt to iPhone if you want, using PhoneGap or Titanium, which are HTML5/Javascript based as well.
I've had a couple of projects end up withering on the vine because I went back and forth between technologies (and in parallel allowed feature creep to make them more and more monolithic and daunting undertakings). So, IMO, the development paradigm to use is the one that will allow you to spend more time coding and less time second guessing yourself.
I want to clear up some confusion:
I understand that AIR is probably the
route I should go, but I'm very
conflicted on how integrated it is
with Android? Is it easy to do now, or
still a headache (I haven't read about
it in ages)?
AIR is very integrated with Android through the runtime, officially known as "AIR For Android". Adobe released it recently and people already have applications in the Android store. The tooling introduced in Flash Builder Burrito makes it very easy to build Flex applications for Android. I expect Burritio to become a formal release early next year.
I've seen the new Flex 4
deploying to Android very smoothly,
but I've heard it's difficult to write
an AIR program with Flex.
It is borderline trivial to convert a Flex application to an AIR application. However, switching a "standard" Flex or AIR application to AIR for Android will most likely require code optimization due to device resources. I would anticipate sharing 60-80 percent of the code base, but the UI will most likely require rework because of the smaller screen size and component management will have to be done differently because of memory / processor requirements on a mobile device.