I’m designing a mobile music program that needs to communicate with MIDI devices, bidirectionally. It needs to run on iOS and Android. If possible, also on Windows, macOS and GNU/Linux, but those three are of less priority. Now I am considering my options for frameworks.
I’ve looked in to React Native with Expo. It seems very straight forward for implementing the user interface. The only thing I am worried about is the lack of support for MIDI. At least I cannot find any information about this.
Is there any way to add support for MIDI devices to React Native with Expo, or do I need to look elsewhere?
Related
Recently I have worked using WebRTC and I'm wondering if it would make more sense to implement a Real Time Communication open standard at a native level.
Let's say that instead of a web browser API we have a native API that any native app, including the browser can leverage.
Part of the promise of WebRTC is to have RTC on the browser without plugins but why stop there, why not have RTC on any device with media capabilities without plugins. There are many devices with media capabilities that will not run a web browser, e.g., wearables. It seems to me that the browser itself has become the plugin and I think we need to get rid of it as far as RTC is concerned.
It sounds like OpenWebRTC is going in a similar direction but so far they are only working inside the browser.
Are there open standards for native RTC? So far it looks like RTCWeb is only concerned about the browser.
Are there any projects/initiatives for native implementations of an open standard for RTC?
webrtc definition. webrtc is stuck into two parts, complementary but separated. the W3C consortium is standardizing a JS API for browsers named webRTC. The IETF is standardizing the underlying protocols and what happen on the wire for interoperability, it is named rtcweb.
the IETF's rtcweb group defines everything you need to interoperate with a browser, without being a browser yourself, i.e. for gateways, devices, .... It has been made explicit at the latest meeting in hawaii last november, and there is for example a corresponding draft.
On the client side, the implementation of webRTC JS API is done on top of c/C++ implementations. Those "native" (as in non-browser, C/C++) APIs can be use directly for servers, embeddable devices, gateway, ect, or can also be wrapped in different languages (obj-c, java) to provide "native" (as in mobile native) APIs.
Note that BOTH openWebrtc.io and webrtc.org have a full implementation of webRTC in C/C++ that you can use. openWebrtc provides iOS wrappers, and webkit wrappers (for safari), but do not provide data channel support, ORTC API support, nor compile under windows. webrtc.org supports all desktop OSes, and provide wrappers for both iOS and Android. The build tools are specific to google's chrome though, unlike openWebRTC which uses standard auto tools, github, ...
HTH
Currently there is no effort in this direction. The guys in the webrtc standardization committee have their hands full standardizing just the javascript API. As you know the current spec is not final and is currently still worked on. And now ORTC will generate even more work.
There are many reasons why no one is currently trying to standardize any form of native RTC. Here are some that come to my mind:
What exactly is native? Javascript is native for the browsers. The chrome version of webrtc is in C++ but the OpnWebRTC one is in C. Android developers use mostedly Java, iOS developers use ObjectiveC. Should there be standards for all these languages? That's going to take forever.
As I said standardization committee already have their hands full.
There is still quite a lot of experimentation that goes on with WebRTC. Standardization may prevent this.
The API of the native libraries tend to be very similar to the JS API.
Can anyone tell me how apple handle submissions for bluetooth BLE enabled app. Actually, i have created a bluetooth iphone app which connects to third party device. And, I am not sure how apple is testing apps which connects to third party devices.
Object Lab has recently launched their first iOS app using iBeacon. It took them 3 attempts to get it approved. I would recommend you to create a video which demonstrates how your app works and send it to them.
Generally they ask for hardware as well but mostly it's not feasible for us to provide them with one. Object Lab had to send them instructions to setup hardware at their end and to test the app. THEY WILL NOT APPROVE UNLESS THEY KNOW ITS WORKING. So I would recommend to send a video and step by step instruction of how to setup hardware at their end to test it out.
My experience has been that a video demonstrating the use of the app while connected to your third party device is enough. Sending the device to them is not necessary (at least for all cases). I know there is another thread on stackoverflow.com concerning this very thing, but it's been months since I had found it and I can't find it now. Anyways, it has worked for me as well as acquaintances of mine who have an app on the store.
Just curious if anybody tried creating mobile apps using IBM Worklight to connect to Pebble Smart watch? Please share your experience and approach.
I have no experience with Pebble Smart watches, however from what I understand from their website (https://developer.getpebble.com/) it looks like they provide SDKs for Android and iOS.
Worklight uses Cordova, which means you could write a Cordova plugin to run native code in your app, and this native code could use the Pebble SDK.
It looks like others already started looking into it: https://github.com/konsumer/phonegap-pebble
at first i thought with Titanium, i can develop for Mobile and Desktop over AIR on Desktop only, but a quick look at the AIR Site, i guess i am wrong.
Benefit from a consistent, flexible,
and visual development environment for
applications on multiple platforms and
devices such as smartphones,
smartbooks, tablets, netbooks, and
PCs.
so my question is are there any major differences of titanium over air that i shld be aware of?
if no, i guess now air maybe better documented and has the backing of a more recognized company? after working with titanium desktop for a while i felt abit helpless and the docs are not really helping much
There are a lot of subtle differences, of course, and there are advantages and disadvantages to working in either, but the largest difference is that Titanium can produce apps for the iPhone/iPad, and AIR can't (well, at least not conveniently).
AIR can produce iPhone apps that you can deploy using the ad-hoc provisioning, but you can't distribute via the app store.
I've got desktop apps on both and am making a mobile app right now. Titanium desktop will cut your dev time to 1/3 of the time you'll take jumping through AIRs various sandboxes and security measures. Best yet, the code I wrote for my Ti desktop app is all javascript with about 3 Ti API calls and can be taken anywhere. The AIR app is all mangled by the wild structure you have to use with AIR apps and 1 million api calls.
The downside to Ti desktop is the API isn't as fully featured, and the Ti team pushes 4 times as many updates for the mobile API as the desktop API. Also, you won't be able to port your app from desktop to mobile easily as they are two different structures and APIs.
That said, developing for iPhone and Android on Ti is the same exact process and that won't happen on AIR.
Lots to weigh, but for my money it's Ti over AIR.
Hope this helps.
I am looking to use Adobe Air to visualize information coming from the Serial port. Is there a way to do this naively in Air? I'm assuming not.
If this is the case, would my best route be to create a native application that makes the serial port available via a TCP/IP connection then connect to it locally? or would a different socket type be available?
With this solution, is there a way to bundle a native app with an Air app so that the user would have a 1-step solution?
You can't access the serial port from AIR, but this thread links to a library that claims it will shuttle the data across a socket: http://www.extjs.com/forum/showthread.php?t=36825
You won't be able to bundle the native app with the AIR installer, you would have to bundle the AIR app with the native app. In other words -- write a native app, with a native installer that also installs the AIR app.
Once you've got a native app and an installer, you have to ask yourself what the benefit of using AIR is anymore. Especially now that you have to write a client and server to shuttle data back and forth between the two.
Unless there is some feature in AIR that you absolutely must have, you're probably better off with a cross-platform tool set like Mono or Qt that can handle accessing the serial port. (And if you don't need cross-platform, you've got even more options.)