I'm currently facing the task of programming an app (IOS and Android) where one feature will be a metronome for drummers.
I do not want to have multiple projects so i decided to use cordova. I stumbled upon many problems and solved some of them:
Can't use setInveral() or such for accurate timing
Can't use any other kind of "triggering" audio
The cordova NativeAudio plugin does also not do a good job in really accurate timing
So i came across the Web Audio API which is not supported by the Android Stock browser on most platforms so i found the crosswalk project which is ment to support the Web Audio API.
The good news is that my metronome test works great on a chrome browser on Desktop. It runs absolutely accurate in parallel with my hardware metronome. It also runs great if i open it with the current Android Chrome app.
It also runs on the android cordova application (Android 4.3.1, Galaxy Nexus) but there are two things that i couldn't figure out yet:
1.) When playing the click sound it sometimes sounds a bit laggy (like it has been triggered twice at a time but not always) and more important:
2.) The tempo seems to be constant but about 10-20 bpm slower compared to my desktop PC with the same settings.
It's kind of hard to put this into a fiddle but i hosted it myself under:
http://gonzales.capella.uberspace.de/sound/
You can find all the sources via the chrome debugger.
Any hint on why this is running slower on Android devices and how i can fix this will help a lot.
"Temp consistently slower" sounds like a sample rate conversion issue. At any rate, looping a generated audio file will work, but is kinda inefficient - I'd suggest a strategy more like the one I detailed in http://www.html5rocks.com/en/tutorials/audio/scheduling/.
BTW - the stock android browser is now Chrome, as of KitKat. That doesn't hit all Android out there, of course, but we are getting there.
Related
I recently started exploring the world of visual recognition and was particularly interested in SLAM. I have tried and tested different SLAM implementations on a laptop from openslam.org
I'm still new to the field and still learning about it. I want to implement SLAM on an android device. Can anyone point me to any such implementation. Or can you suggest which implementation of SLAM would work best on an android device. I have access to top of the line android devices such as the Galaxy S6 or the Nexus 5.
Before starting to work on my idea I just wanted to know which implementation would work best in terms of efficiency and accuracy on an android device.
Thankyou
Those guys are quite good, the source is available under GPLv3 license (in user friendly form) and a friend of mine was able to run it on android in real-time (It was developed for MAVs and they state that it should reach 50FPS on current embedded computers).
https://github.com/uzh-rpg/rpg_svo
(Check out the video on the homepage as well)
orbslam is a open source slam system basing on sparsity method.
on pc orbslam can reach about 35 FPS，on smartphone it can‘t perform like on pc， so you can't move the phone too fast. That is because the feature extraction process of orbslam take so much time.
svo is a good choice as for speed, however, svo is only a visual odometry, it dosen't have a loop closing module, therefore when run for a long time, the drift may be large.
therefore, i recommend orbslam.
many people have migrate the code to android, you can search on github:https://github.com/search?q=orb-slam+android&ref=opensearch
I've decided to take a closer look at Phonegap, which means currently I'm not developing anything, but trying different things, e.g. the camera. Apparently this can't be tested with Ripple for Chrome - as far as I know it needs to be tested either in the emulator or on the device itself. My computer isn't slow, but building an app and installing it either on the emulator or the device still takes "a lot" of time (if you're just playing around).
So my question now: Is there any way of speeding up the process of testing applications e.g. in the computer's browser even if you are using things like camera?
Here are the things I've tried so far:
Using my Sony Xperia Mini Pro
Using Intel-Android-Image
Booting emulator from snapshot
Ripple (which can emulate a lot, but not the camera)
Thanks :)
I ended up building the app each time, it's kind of fast if you use build scripts.
But you can also try cordova browser https://play.google.com/store/apps/details?id=com.eas.cordova.browser
or Cordova Fast https://play.google.com/store/apps/details?id=org.Bellinux.CordovaFast
I haven't tried the latter myself though.
cheers
I built a very VOIP app for android phones. All i have is a text field that lets a user enter the username of the person they'd like to call. Then when they press call, it will wake up the recipients phone and play a ring tone. The recipient can answer or decline the call.
At the moment the app "almost" works fine on the following devices:
Galaxy Note 1 with OS 4.0.4
GS3 with OS 4.2.2 and 4.3
GS2 with OS 4.0.4
Nexus 4 with OS 4.2.2
Some minor issues I'm having are calls between some GS2 phones (GT-S7530M) to some GS3 phones, where the audio is extremely quiet. I'm not sure why this is, even though we maxed out the volume. Other times, there's plenty of crackling in the calls, or you miss out on people's sentences. We made sure the network speed was always at least 15mbps download and 1.5mbps upload.
Every other phone seems to work fine.
I am using linphone as the sip library for the phone. I am using asterisk as the telephone server. I am using GSM as the codec for the phone and for the asterisk server. I'm pretty sure I'm not doing anything "special" with my code. It's a simple app and I think any experienced Android developer will find my code pretty minimal and simple.
My question is, assuming I correct the issues for the targeted phones above, is it realistic for a single programmer to attempt to make this voip app work on 70% of modern android phones that are running OS 4.x+? Let's assume I want to be able to hit 70% target within a few weeks.
Some of you might think my question is too broad, so I want to make it clear that i'm just looking for a yes or no answer to whether it's realistic or not and the reason for your answer.
The reason I'm asking is because I had an earlier prototype, and I asked some strangers with other phones like Sony Xperia ZL, HTC One etc... and they seemed to have problems getting my app to work correctly. They experienced problems like the ring tone didn't work, or they couldn't receive a call (even though they successfully connected to my asterisk server), or the audio quality was extremely poor. This led me to do a bit more research on the popular problem known as Android Fragmentation. When I saw all the android phones out there, it scared me. Can I really reach 70% of modern android phones running OS 4.x all by myself in the next two weeks? Will this new version that I've created with bug fixes for Note 1, S3, S2 and Nexus 4 work perfectly on the other phones?
It's a very simple app
I long for the day when we can actually describe a custom VOIP app as being simple. It's 2013, and we cannot say that today with any degree of accuracy. IMHO, your app is rather complicated. It just so happens that most of the complicated bits are in a glob of open source code that you did not write (linphone) and a third-party server that you did not write (Asterisk).
It's a simple app and I think any experienced Android developer would find my code pretty minimal and simple
Pretty much all of the symptoms that you have described would either be part of linphone or part of Asterisk, from what I can tell. Your code may be simple, but your app is not.
is it realistic for a single programmer to attempt to make this voip app work on 70% of modern android phones that are running OS 4.x+?
If you remove linphone and Asterisk from the equation -- say, by rewriting your app to play a ringtone based upon an GCM user notification -- your objective seems reasonable.
However, since your app as presently constituted is almost completely linphone and Asterisk ("any experienced Android developer would find my code pretty minimal and simple"), your success is gated by how well linphone works on Android, and how well linphone-on-Android works when communicating with Asterisk.
Hence, the only people who will be able to answer that are those experienced with those technologies. You might try asking on some dedicated linphone and/or Asterisk resources. Or, you might ask fresh StackOverflow questions, with tags appropriate for those technologies, with more focus.
No. Some carriers inflict inanity: sip hostility or not awesome flavors of IPv4 to IPv6.
Currently I am also working on an Android VoIP client.
Actually there is no any difference between the different hardware and OS versions except this audio handling headache.
Unfortunately there are a lot of inconsistencies in the audio implementation by the different vendors. I would suggest you to have a look at some open source SIP softphone source code such as sipdroid, mizudroid and csipsimple. I was learnt a lot especially from sipdroid, although the code is not well commented. Be prepared to a lot of workaround handling each devices differently.
I've been developing a mobile app for both iOS and Android. Due to time/budget constraints, we initially selected PhoneGap/Cordova as mobile app framework so we could write once and deploy to both platforms.
This plan has worked fine for iOS, but we're finding that Android's browser/engine is kind-of a piece of garbage (to put it nicely). Every time we add a new feature, we find one more thing that the Android browser doesn't support, or only partially supports, or fully supports but will randomly fail from time to time, etc. Even once we code around the Android issues and get things working smoothly, test it on multiple devices/versions, and deploy a new app to the Android market, we immediately start getting emails and reports from customers who can't get the app to work on their device. We have them uninstall/reinstall, reboot their phone to clear the memory, etc., and their device still consistently fails (and by "fail", I mean it typically just freezes and/or won't respond to touch input - it usually doesn't crash, or anything). The app works fine for most people, but there are still quite a few devices that inexplicably fail.
I don't mean for this to be a rant, I'm trying to analyze whether the Android+PhoneGap path is the correct path for us. Specifically, I'd like to find out the following:
Are there people out there having success with an Android+PhoneGap app? or is Android+PhoneGap always going to be a problem on certain devices?
Am I likely to have more luck with a native Android app (I've never attempted one)? Or are multiple devices/versions always a problem on Android, even with a Native app?
1) Yes. There are are good apps which are based on Phonegap and works well in all devices.
2) It depends on what features of the Android you are going to use. Few versions that does not support some features that's available only to new version.
BTW, what is the minimum required version that you have selected for your app? I assume you are developing the app with Android as base version.
When creating a new Android project, you have to set the minimum required platform version. If you set something higher and use the app in a lower version which does not support the feature, results are going to be different.
After having worked with Android+Cordova for some time now, I have the following suggestions/comments for anyone thinking of going that direction.
Consider using Sencha Touch, or jQuery Mobile, or another mobile framework that has already coded around the Android-browser issues (which there are a LOT of). Consider not straying too far from the default styling that come with those frameworks. Simply styling a normal web page to look like a mobile app is a constant headache to get working on multiple versions of the stock Android browser.
Although the stock Android browser is garbage, Mobile Chrome is pretty nice. In Android 4.4, the Chrome engine becomes the default engine used by a webview of an Android app. If you don't like Sencha or jQuery Mobile or the like, you could hold off and just use a mobile web site for a while until Android 4.3 and below become insignificant. It's not hard to get things working on Mobile Chrome.
Even without Sencha/JQM, you can still muscle your way around the stock browser issues, but it's almost as frustrating as developing for IE6. Okay, maybe not that bad… but close.
I've started experimenting some with a native Android app, and, so far, it seems like less of a headache than building an app with Android+Cordova+lackOfSenchaOrJQMorTheLike. The things I've experimented with work pretty consistently among different Android versions. But I don't have much experience there, so I can't comment too much on a native Android app.
Has anybody blogged about this comparison, or does anyone want to give it a shot here? Would be nice to see some reasoned thoughts on Adobe AIR on Android vs. the "native" Android SDK (in Java).
Edit: Despite few views and no answers, I'm leaving this question up here since it's a topic that needs to be covered at some point... but if it gets no attention I'll delete it in a few days.
I think it's ultimately very similar to the question of whether to use AIR or Java for a desktop application. Ultimately it comes down to three points:
Does AIR do everything you need? Obviously the android SDK gives you complete access to device capabilities, but AIR purposely doesn't, in order to stay portable. For example, AIR may not support intents, at least initially (I don't think Adobe has announced yet one way or the other). Also, AIR requires Android 2.2. If those limitations are troublesome, regular android SDK may be best.
Are you looking to make something that would be well-suited to doing in Flash? If you're planning a design-heavy app with animations, video, sound, or the like, then building it in Flash may be significantly easier than using Java. On the other hand, if your app will be pure code using only standard visual components, then it might not make a lick of difference which platform you use. Or on the gripping hand, if you'd have existing Flash animations or the like, then trying to shoehorn them into a Java app will be bothersome.
Are you targeting other platforms besides Android? If so, AIR may be a big win, as the same app content should run on windows, mac, linux, and later on, other devices that plan to support AIR, like Blackberry, some TVs, blu-ray disc players, etc. If you are only targeting Android, AIR may lose some of its appeal.
I hope that helps some. Realistically, unless you're effectively locked out of using AIR because you need something it doesn't give you, or effectively locked into using AIR because you're doing design-heavy work and you need the tooling, then I think the pros and cons of the two SDKs are largely questions of convenience. Either platform will work, so it's merely which will get you to the finish line the fastest and most reliably.
One issue to consider is compatibility with Android devices. Both fancy smart phones and cheap phones run in Android, but they don't have the same capabilities. Even if you application is simple or can be done beautifully in AIR, its relevant to mention that AIR is not compatible to all Android devices.
Some very popular devices currently sold (such as Samsung ACE and other "cheap" devices) use ArmV6 chips, and AIR or Flash are not compatible to this architectures, even when running on Android 2.2 or so.
AIR is interesting because same development works in different technologies, but consider that AIR doesn't run on "old" iPhones either, its only guarantied to work on new technology with big processors.
Check this Adobe link http://www.adobe.com/flashplatform/certified_devices/
AIR should be ruled out in your decision of technology if in your requirements you are targeting as much phones as possible, including those that are not so fancy or new.
I have experience with AIR mostly and little with Android SDK when I was building a native extension to AIR. My biggest hurdle with AIR is it's immaturity, it's bugs, and it's inconsistent behavior. Yes, you can go to the shiny page at adobe.com and see how cool is the AIR... All bright with tons of features which seems to cover all your needs. Yet, once you start building your app you'll find many ugly surprises:
Stage text in not working appropriately. link besides this bug StageText has few other bugs, like behavior in Scroller for instance.
Sound() object doesn't play the stream (it does on emulator only). link
Lack of features like AEC makes AIR useless to whole list of chat applications, as you'll will hear echo and screaming noise. link
Overloaded (and immature for mobile) Flex SDK (I hope folks at Apache will rewrite it from 0 and make it more manageable).
No H264 support on iOS devices: link (yes, I know it's Apple problem, that they want to control HD delivery on their platform, still it's Adobe problem too, as they couldn't fight right to bring their technology to forefront).
Sound object doesn't take variable bidrate (only 44.1KHz is possible). Flash "second generation" Speex codec samples at 16Khz. Now, try playing this back through Sound and you'll enjoy a funny circus. At the end you will need to write your own upsample algorithm.
I'm sure people will add more to this list. So, my answer would be native SDK is more preferable for anything serious. You won't work like a QA person with it - testing countless little examples trying to understand why an AIR feature not working, shuffling internet for answers and looking at AIR bug database... only to find that critical bugs are sitting there from release to release. That is my experience with AIR. Going native SDK makes your application not really "cross-platform", but AIR SDK can't claim this title anyway for anything more serious then couple of "Employee directory" examples. And if you will need to build for the other platform, you will just use native tools for it.
GL.