I'm preparing to create a open source mobile app for learning to type in Braille. The app will need to:
Access up to 6 simultaneous touch points
Generate text-to-speech audio on the fly
Play MIDI sounds with 6 simultaneous channels, generated on the fly
Connect with a BlueTooth device
Ideally, I would like to create the app once in one development environment, and then deploy it to Android, iOS and other devices.
PhoneGap
Titanium
LiveCode
However, as far as I can tell from my research, none of these gives me access to all the native features that my project will need.
I would be interested to hear from developers who are working in these and similar development environments on how easy it is to handle the four requirements I have listed above.
With all those requirements i'd go for Xamarin, i know it can deal with text-tp-speech, bluetooth and multiple touch inputs but you have to check whether it supports your MIDI requirement.
And of course you can port to all platforms.
Bluetooth Chat Sample Application
TextToSpeech class
Related
I have a medium size project on React+Nodejs and I need to choose best suitable technology for the mobile part. I am considering React Native or Web Progressive Apps for that. I want to ask you guys what is your experience so far about performance of "native-like" React Native versus WPA based apps.
I need to put into consideration:
1. Making it as easy as possible to make a transfer from ReactJS code into mobile.
2. Hardware support on mobile devices. Such as Barcode reading and NFC.
3. Push notifications.
4. Function well on both Android and iOS.
Biggest question is whether WPA technology has already become mature enough to trust it or not.
I had to make the same decision couple of months back and we chose PWA (not the answer for everyone yet).
Here is why we chose PWA,
1) Performance - Web can now perform 60fps - The magic number needs for native like smooth transitions.
2) Cost - Its fast and easy to build a product for both as a mobile app and web using PWA with no learning curve for existing web developers.
3) Proven - Starting from Twitter lite to Flipkart, there are so many success stories on PWA. No doubt its reliable. With iOS support coming couple of months back, now all major browsers support it.
PWA limitations and workarrounds,
1) Hardware - PWAs are limited to what web can do today. So there are hardwares like bar-code scanner we don't have any scope of support anytime soon and there are some hardware which very limited support and some hardware like Bluetooth with average support(in terms of % of browser versions supporting today) We had to build a small Android Native application to interact with these hardware and pass on the info to PWA suing web sockets. Say, when a barcode is scanned, this native Android service will listen for and receive it and pass on to our PWA. Same thing goes to NFC.
2) Packing and deploying - There is no official way to generate an APK and distribute in corporate environment. We were able to extract the APK after adding the PWA app to home screen using some file explorer and use that to distribute though. Havent tried on iOS. Hope for latest versions for any mobile OS, we can use cordova(not pure PWA but we get most of the benefits like Service Worker) to package and distribute as well.
I have a game programmed in Unity3D in order to publish it in the end to iOS and Android.
Suppose the game App is installed on the mobile and I want to control it through an external Bluetooth Low energy device (for example - Heart rate sensor) What would be the better way to make the architecture for that for making it cross platform?
For example - to make it the easiest way to implement it on iOS and Android as well?
*External* *Mobile*
Bluetooth Low Energy device --> Something.. --> Unity
Something = What cross platform framework do you advice me to use that can interface with the Bluetooth Low Energy (in the future also with Database) and the Unity3D to pass it the logic ?
Thanks a lot
Unity does NOT have a Bluetooth API to use bluetooth on iOS and Android. The way to do this to make a plugin.
For iOS, you can write a plugin or functions in Ocjective-C or C++. You then place the .cpp or.mm file in your Assets/Plugins/iOS directory.
For Android, You have to write the Android plugin in Java or C++ then compile it into .jar exntention and place the jar file in Assets/Plugins/Android
Each plugin should have thesame function names so that they will be compatible with each other. When you want to compile for Android or iOS, Unity will automatically choose the correct plugin folder to use for the specified mobile platform.
The good way of making this plugin is to write a whole Application in iOS or Android and test your functions in XCode or Android Studio. If they work, then you can go ahead and convert it to plugin to be used in Unity. This saves time.
EDIT:
I don't like adversing products but I know this will help you so here is a plugin that you can use for Bluetooth LE communcaitions that works on Android and iOS. https://www.assetstore.unity3d.com/en/#!/content/26661
This plugin is new but ihas good reviews. That's why I posted it.
Please bear in mind that most Heart rate sensors come with a built in security and proprietary communication protocol. So, even if it uses Bluetooth, you will have to reverse engineer the protocol and then write a c# class using the Bluetooth plugin I linked here to be able to communicate with them. You can reverse engineer any Heart rate sensor. Just buy one of the famous ones then get an iPhone and Android phone.
Jailbreak the iPhone and root the Android device. Install bluetooth sniffing app and try to communicate your Heart rate sensor device with the with either iPhone or Android. You can read what is been sent to the Heart rate sensor device from the iPhone/Android or what iPhone/Android is sending to the Heart rate sensor device. That is what you need to be sending to it in your c# class to make it work. Other ways of doing this is de-compiling the app that comes with the Heart rate sensor device(Not recommended). You can see what's going on from there.
If the Heart rate sensor has an API for android or iOS, you will then have no other option but to write the plugin yourself on top of the API they provided for it.
If you are making your own Heart rate sensor device, then that should be easier. You can make a prototype with Arduino and communicate to it with the Plugin I linked here. If it works, you can then move on to make it a real product.
It looks like the H6 and H7 are the most famous ones. They also have a developer page. It hould be easy to communicate with these because they use standard protocol instead of proprietary ones just like some do.
http://developer.polar.com/wiki/H6_and_H7_Heart_rate_sensors
Android heart rate sensor code(standard):
http://developer.android.com/guide/topics/connectivity/bluetooth-le.html
iOS heart rate sensor code(not about standard):
http://developer.polar.com/wiki/H6_and_H7_Heart_rate_sensors#HR_example_code_for_Android
You can email the developer of the plugin I posted in link and ask they could support or help you implement heart rate sensor. They might even do it.
Good luck.
I’m completely new to Qt mobile, I even don’t have a solid mobile dev experience, so sorry if I’m asking something obvious.
I need to develop a mobile app that should have the ability to receive a call like functionality (over internet, not GSM call). When answered, it should start streaming audio and video from our server. The call should be one way only, meaning, that stream goes from server to device, but never from device to server.
So my questions is:
Is this possible in Qt? I chose Qt because I’ familiar with it and I want to support desktop, android and ios. maybe windows phone later.
Is it possible to receive a call when the screen is shut off and my app is not running? I mean, this is a mobile device, the app won't be running all the time, it should be started only when a call is made from server to device. How can I achieve that? I think Viber, Skype and other messaging apps do that.
Many thanks in advance :)
1 - Well, sure it can, although it might not be as easy and straightforward as you'd want. Qt Multimedia does provide the necessary classes, but you do have to check how supported they are on the platforms you need to target.
However, the classes Qt provides are either too high level to serve any purpose but their intended purpose, or too low level, so you must implement pretty much everything by hand. In this aspect, the benefit of Qt being capable of producing portable apps may not outweigh the ease of using certain platform specific libraries that offer video streaming out of the box. In other words, it might be easier to write separate Android and iOS apps using Android and iOS libraries than a single Qt app that will work on both.
But just in case you decide to go with Qt, as I mentioned for the time being you are left with one option - do most of the work yourself. This means you should record audio using QAudioRecorder and capture frames periodically from a QCamera in a buffer of given length, compress that data (and preferably encrypt it if security is a concern), send it to the client over a QTcpSocket connection, decompress (and decrypt) the data and play it back in sync. It is certainly doable, but as already mentioned, it will be much harder since Android and iOS libraries offer pretty much "out of the box" solutions. Alternatively, you might decide to use a third party solution that offers support for all the platforms you target.
2 - whether your screen is on or off - that will be a call to a platform specific API, so are requests to turn it on or to keep in on for a given duration. Whether your app is running on the device or not, that is easy - just try a TCP connection with the client on the device, if it succeeds then the client is running. If you want to receive calls while your app is not running, you will have to implement a platform specific service that runs all the time instead and starts your application when a call is received.
QT Mobility does not have a a framework for supporting VoIP as you can see from the reference :
http://doc-snapshot.qt-project.org/qt-mobility/
You could create the VoIP framework of your app natively (which is going to require a good understanding of the various audio and video frameworks available) but another way to go
would be to use a VoIP SDK that supports both iOS and Android such as the Twilio mobile client
https://www.twilio.com/client/mobile
Qt mobile will help you in your application's UI, however you will have to write some native code for each platform you are going to use. Note that Qt is extending fast, you might need not to get your hands dirty with platform specific native code in upcoming versions of Qt.
Yes, you can receive a VoIP call when your application is closed by creating a background service (but as I know so far Qt doesn't do the job for you, you'll need to do it natively), it is the way Skype and Viber work.
As per I know new Blackberry10 OS using qt for developing. There is one source code available about VoiP Calling in qt. I am still searching about video call.
Check below link, May be helpful
1) Blackberry Developer Blog
(2) PjSip Blog
(3)Download Source Code
I don't know how to develop app in Android, ios, desktop using qt language.
But I am suggesting develop app in all native language instead qt.
I am currently thinking about the best multi-platform language to build a multiplayer app with, and I was just wondering if anyone knows if AIR supports multiplayer locally between devices i.e over a LAN or bluetooth? Would I need to run some aspects of the game via a server?
Not to give too much away (of the game idea) but it would be similar to a "Simon" type game, with the only info being passed to each device either a score/amount of moves to beat or other simple piece of data.
Thanks
Adobe AIR supports the ServerSocket class so yes it's more than possible.
Edit
As #davivid accurately pointed out, ServerSocket doesn't seem to be implemented on mobile devices. You're not SOL here though, you can use Native Extensions or AIR and still accomplish your end goal. See this official adobe page for more info and a ton of downloadable examples.
Multiplayer on devices connected to the same local network is supported in Adobe AIR including iOS and Android. You use NetConnection.connect().
Example with source code.
If you are developing on iOS. It is best to use GameKit that came with iOS. GameKit is also connected to GameCenter. So, players can challenge their friends close to them or play against someone over the Internet. This is all handled for you by the API, so you don't need to worry about matchmaking or even low level socket communications.
AIR doesn't support GameKit out of the box, but there are some Native Extensions that support Multiplayer Gameplay. The one I use is at: http://airextensions.net/shop/extensions/game-kit-by-vitapoly/
Can anyone give a comparative information between developing Android mobile applications using Eclipse SDK and Adobe AIR?
Kindly share your opinion, anyone who has already having any experience on developing Android mobile applications using Adobe AIR.
I have gone through articles on developing Adobe AIR but wanted to know if anyone found it useful. I am aware that Android mobile applications developed using Adobe AIR is supported for Android 2.1 and 2.2.
Thanks in advance.
I will do my best to answer your question, though it's a little broad (if you could provide specifics on the information you need, I'd be happy to add more detail).
Firstly, there's a ton of information both from Adobe and from the Flash/Flex community on developing for AIR for Android. You can develop for AIR for Android using Flash and the Flash IDE or using Flex and the Flash Builder IDE currently in public preview on Adobe Labs (you can do straight ActionScript as well if you like).
One of the benefits of using AIR is that you can leverage your existing skillset in Flash/Flex/ActionScript rather than having to learn a new language. Another benefit is that yu can reuse code for existing Flash/Flex/AIR applications you may have built. Another benefit, and the one Sheikh mentions above is that Adobe is working on making AIR a cross-platform mobile runtime. If you search you will already find articles from Adobe and the community about people running AIR applications on the Playbook (the simulator anyway, since the device isn't released yet) and even using the preview Packager for iPhone to compile their applications to iPhone.
Although I haven't worked with AIR, but what I feel AIR is for, is cross compatibility.
Its like you're not building for Android, you're building for AIR. and since Android supports AIR, your applications will run on Android device.
In future more Mobile OS will start supporting AIR, so if you code an app for AIR, there will be a huge possibility that your same code runs on different platforms like Android, Windows Phone 7, iPhone (perhaps :-P). Thus, it will be saving a lot of coding effort for coders.
I have discovered that the cross-platform compatibility for AIR applications is quite good except for a few caveats:
1) User input boxes. They are generally not handled well in AIR applications. The popup keyboard can hide the input box, which it generally does not do with native JAVA apps for Android.
2) Real-time games. AIR for Mobile is SLOW. You may be disappointed if you try to develop any sort of real-time software.
3) Socket communication. This is my current peeve. I created a simple chat application in Flash and did some speed tests. This is in preparation for creating multi-player games for mobile devices. On the PC, the application can run over 200 messages per second to the server and get responses. On the AIR for Mobile, both on the iPhone and Android, it is about 11 messages per second max - and the app is doing nothing BUT sending and receiving the data strings. Add a layer of game play and the speed limitations could be crippling. This means real-time games may suffer if you need faster communications. It's plenty fast enough for turn-based or games that don't require lots of updates.
Basically, the cross-platform compatibility is nice. Just think about whether your particular project might be harmed by the speed issues as well as potentially poor handling of user input boxes. Do some testing.