I am trying to make an application on mac.i am trying to develop a user authentication module that uses the OS authorization dialog and use its functionality in my application. i have two questions regarding the mac development;
1) Is there a possibility to port the carbon applications to cocoa? (i don't have any concern
with 64 bit, i want to develop in cocoa for simplicity and also because it doesn't go to
low level programming.)
2) secondly, please tell me that i am using an intel based mini mac with OS 10.5, so, if
there is no possibility of porting the carbon application to cocoa then can i develop on
this intel based mini mac for Carbon?
Regards
Yes, but there's no automatic way to do it. If you write your Carbon application in C++, then you can use Objective-C++ to integrate Cocoa without having to change your existing classes too much, but you still have to do all of the heavy lifting.
You can develop Carbon applications on OS X 10.5.
Note that Apple's "Getting started with Carbon" guide is now part of the legacy documentation library, and an increasing number of new features are only accessible through Cocoa APIs. I would strongly suggest using Cocoa for your new application, instead of starting with Carbon then porting.
Related
Is Universal Windows Platform the replacement of WinRT of Windows 8 and Windows Phone apps?
I mean, there was a WinRT platform to develop metro apps exclusively for Windows 8. Now, that is replaced by UWP, isn't it?
That is correct, UWP is the new platform for ALL Windows devices going forward (Win 10+). However WinRT is not replaced by UWP but is instead an extension on top of it, making UWP a much broader set of APIs that can be used across even more devices. As Microsoft themselves state:
With this evolution, apps that target the UWP can call not only the WinRT APIs that are common to all devices, but also APIs (including Win32 and .NET APIs) that are specific to the device family the app is running on.
The UWP platform supports the "Universal Device Family" class of APIs which is then supported on ALL windows platforms (Xbox, Phone, Desktop etc). There are some extension families that you can use that will limit the apps reach, such as a "Mobile Device Family".
These specific device family APIs can however be checked for and used at runtime gracefully. For example you could show your own position using GPS on a phone, but not enable that functionality on a Xbox.
I hope this answer helps you, if you have any more questions about this I recommend reading this article about the UWP platform:
Source: https://msdn.microsoft.com/library/windows/apps/dn894631.aspx
Have a wonderful day!
This is a bit confusing because in Windows 8.x, "Windows Runtime" was actually used to refer to a few different things:
A new pattern (and supporting code/OS components) for defining and consuming Windows APIs, meant to largely supersede "Win32" (i.e., flat C-style) and classic COM for new APIs in most scenarios. This was/is really about language interop: allowing the Windows team (and potentially others) to create components in C++ that expose APIs that don't depend on GC or a runtime like the CLR, but still feel relatively natural to use from C# or JavaScript without needing manually written wrappers.
The set of Windows APIs that follow the above pattern.
A new platform/environment for building and running a new type of Windows app, which are meant to have some of the characteristics of mobile and web apps in terms of causing fewer potential problems with system security, reliability, performance, battery life, etc. This is what evolved into UWP with Windows 10.
In the Windows 8 days, these apps were called "Metro style apps" during most of 8.0's public preview period, and officially dubbed "Windows Store apps" just before RTM. The platform/environment for these apps ... officially didn't really have a name (other than "platform for Metro style apps"). Unofficially, people (including at Microsoft) sometimes referred to it as "Metro" (a whole can of worms in itself) or ... "WinRT".
So what's the relationship between WinRT "proper" (definitions 1 and 2), and unofficial WinRT definition (3) aka UWP aka the formerly-nameless "platform for Metro style apps"? Well, since WinRT and the new app platform were both introduced in Windows 8, most of the WinRT APIs at that time were specific to the new platform. The app platform (and Store policy) at the time was also much more restrictive about which legacy Win32 APIs were allowed for use in apps - for the most part this was less about any technical limitation and more about the team hoping to use the new apps as an excuse to clean up the bloated Win32 API surface. But technically, WinRT is meant to be the common pattern for new Windows APIs in general, whether used in UWAs or not, and "UWA vs. classic app" and "WinRT vs. Win32" are mostly independent; over time, they've gradually enabled more WinRT APIs for use outside UWAs and also relaxed their policies on using a lot of legacy Win32 APIs in apps (and also continued to introduce new flat C-style APIs for certain use cases).
So to summarize, it's not technically accurate to say that "UWP replaced WinRT", though understandable since this stuff is pretty confusing. UWP replaced the nameless app platform (3); essentially it's just an updated version that's been ported to other device types and integrated with the classic desktop UI. WinRT, in its proper definition (1), continues to be the basis for new Windows APIs for use in UWAs and even outside them.
Windows Universal Platform is the development platform going forward for devices running Windows. Previously, development was separate for Desktops and Tablets vs Phones. With UWP you are now able to target any device running Windows 10, could be phone, desktop, tablet, xbox. The beauty is that you can now use one Binary for all of these platforms and has brought us much closer to a truly to a universal Windows app.
So, to answer your question, yes, UWP is the platform going forward for any device which runs Windows 10
I am writing an application for Mac OSX in Xcode/Objective-C that uses the IOBluetoothHandsFree class in the IOBluetooth module. The application allows a user to use their computer as a speakerphone for their phone over bluetooth. I'm running into an issue where the volume of all other applications on the computer get much lower when a call is initialized and the computer is used as the speakerphone (called "audio ducking"). How can I go about disabling this functionality in my application?
After talking with the Apple Bluetooth team, it turns out that this feature is not supported in the latest version of the IOBluetoothHandsFree class.
I have gone through a deep research on developing google glass apps using objective c ,but I have found that we should only use Java/Python/PHP to develop google glass apps. Since I am an objective c developer I am looking for some static library or framework for xcode, which is built to develop apps for google glass. Please give me any idea, is there any such frameworks/Library? Any of your suggestions would be much appreciated.
Yes, Google provides an Objective C API library at https://code.google.com/p/google-api-objectivec-client/ that includes generated routines for the Mirror API. You should probably also consult the documentation at https://developers.google.com/glass/develop/mirror/index for a broad understanding of how the Mirror API works.
Note that this will allow you to develop web services that work with Glass. It will not allow you to develop applications that run on Glass itself. It also will not allow you to write iOS applications that communicate directly with Glass - it will need a network connection to the Mirror server at Google and there may be some restrictions about how a callback will work.
Android SDK is what you use to create .APK files to run on an android or google glass device. It is based on the java platform.
Just like Prisoner says you can mess with the mirror API by sending cards to your device in almost any language via those starter kits.
If you are actually trying to make glassware you will need the Android SDK. Unless you are a very experienced programmer I wouldn't try to program in C to create apps going on glass.
On a side note: if you are a new programmer and are only experienced in C, try to learn python. Python is great for programming in C with a variation called CPython.
I realize it's been asked countless times whether iPhone apps can be built in Windows and that the simple answer is no, with workarounds such as using VM or even something like Dragon SDK which requires the app to be written in C/C++, but I would like to build an app using Objective C.
My question is can the code for an iPhone app not be developed on a Windows computer, uploaded to a remote Mac computer, compiled on the Mac, and then downloaded back to Windows to install via iTunes? I don't want to buy a Mac mini to get my feet wet with iPhone development, but I don't want to be limited to writing an HTML 5 app using Phone Gap or similar.
If nothing else, wouldn't it be possible to develop the app directly on a remote / virtual Mac using a remote desktop connection?
If either of these are possible, does anyone know of a company offering such a service? If not, what would be a likely reason that it hasn't been created? It seems like there would be enormous demand.
Perhaps http://www.macincloud.com/ is what you are looking for.
I believe what you're trying to do is not possible but how about MonoTouch ?
http://xamarin.com/monotouch
Using .NET on Windows technologies to develop iPhone and other apps ?
I'm currently developing a browser plugin for MacOSX 10.6, and am planning to use the netscape API for portability across browsers and architectures. According to Apple's documentation, as of 10.6 such plugins run out-of-process to improve the integrity of the browser session. What I'm concerned about is the following directive they give in the documentation:
Use platform APIs sparingly. Wherever possible, you should use new
plug-in APIs to do what you need. If no such APIs exist, file bugs requesting them.
I'm not sure what the nature of this directive is. Is this advice to improve portability of the plugin, a reminder that accessing the operating system's other APIs can open up the possibility of crashing the client or corrupting a user's data, or an indication that access to the platform APIs is in some way "broken?"
Its portability advice. The NPAPI is, although not officially standardized, fairly stable and already wraps some platform specific APIs for you.
If you try to use NPAPI whenever possible, you avoid quite some porting as e.g. it happened relatively recently with Apple effectively deprecating Carbon when transitioning to 64 bit.