iPhone A13 Bionic breaks Streaming SDK (encoding) - ios

I'm not sure where to head for this problem, so I'm asking here, maybe someone has experience with streaming SDKs for iOS.
We are a small company and we have an app that uses a proprietary Streaming SDK that our company has bought from another company a while ago (~4 years, we just inherited an app with this library recently). The library is used so that users can livestream themselves to the other users of the app. This functionality has been working fine on all iOS devices, until we got some reports form users that they can't stream on iPhone 11, 11 Pro and 11 Pro Max devices.
Today, our team finally got our hands on an iPhone 11, so we tried debugging the streaming library to see whats going on. It turns out the AudioEncoder of the library is reaching its "failed" state at the beginning of the stream and stopping the whole stream.
Before even getting our hands on a new device I suspected that the new CPU must be messing up some part of the audio/video encoding, and turns out I was correct.
Unfortunately, we do not have any contact (nor support) with the company that created this library, I'm pretty sure they don't exist any more, and besides some headers, the rest of the SDK is packaged in a .a file so we can't dig into the code to fix it.
My questions are:
If anyone who has developed any streaming libraries has faced any
similar issued with the new iPhones, and if you can point us on what
the problem is and how we could fix it and
Some streaming library
recommendations, preferably open source ones this time, so we don't
end back in such a situation again in 5 years.

Lucas,
We create Larix SDK for mobile streaming. From our experience, the SDK maintainer's main responsibility is not just develop new features, but maintain all the old and new OS and hardware releases. Every now and then some new system release may change APIs and add new restrictions so keeping app up-to date is critical in long-term.
Regarding iPhone 11 - there were no changes on those models in regard to audio, this is a library issue rather than the platform.

Related

SDK for Nokia 3310

I'm thinking some time about the possibilities to bring back some life to my loved Nokia 3310 by developing some software for it. The only downside is that there is not really much information on the Internet about the subject.
I've read that there is a SDK called Nokia PC Connectivity SDK 3.0, but every link that I tried is very old and the download links are always broken. Searching on Google just gives results to Mallware websites and the Nokia Developer website only holds an archived forum section without file support..
Does anyone knows where I can download this SDK or has a better idea/suggestion about developing software for this dinosaur of a phone?
AFAIK the offering is no longer available from the original site, thus I would not recommend using any versions available on any other site.
Anyway, the PC connectivity as far as I remember did not really enable you to develop any software for the device as such, it was used for making apps that could connect to the services of the device (such as SMS, logs etc.)
Quick internet search also suggest that the device might not even support AT commands, thus I would assume that there is no development offerings available for that old device anymore.

Acoustic Echo Cancellation in AIR Mobile on iOS - using Native Extensions?

We are developing a video chat app for iOS using AIR Mobile and the acoustic echo is a real show stopper. getEnhancedMicrophone() returns null so apparently Adobe can't help us here.
However, unlike Android, it looks like acoustic echo cancellation is a standard feature on iOS. Is there a way to use Native Extensions, for example, to enable AEC in our app using kAudioUnitSubType_VoiceProcessingIO?
This question is iOS-only, we're not interested in Android at this point.
Unfortunately, I am pretty sure you cannot use a native extension (ANE) for this to work with AIR mobile. NetStream can only attach Adobe's Camera and Microphone classes so there is no integration point.
And as you know, as of December 17, 2015, Adobe has still not addressed AEC for AIR on mobile devices, on either Apple or Android platforms.
However, a contact of mine talked with Chris Campbell at Adobe a couple of times early in 2015 regarding AEC for AIR Mobile, and Chris said at one point that they had cleared legal WRT licensing issues related to AEC, and he was pitching AEC for inclusion in AIR 20 for Mobile (December 2015) so it's possible it will be announced soon, though I'm not holding my breath.
I haven't seen any other public indications that Adobe is going to do this. I know it would be a tremendous enabler for developers of video chat-based apps, to include support for mobile devices.

iOS6 large downloads time out

It seems like all large downloads timeout on iOS6 using ASIHTTPRequest.
Does anybody know of any forks that have updated this library for iOS6. I love this library and really do not want to have to switch.
EDIT:
This issue is not specific to ASIHTTPRequest. Upon testing FSNetwork, MKNetwork, AFNetwork, and NSURLConnection they all fail.
A sample project can be downloaded from here:
https://github.com/BLamy/NetworkTest
It must be built to an actual device running iOS6 (I used an iPad2 unsure if that makes a difference).
I was having the issue with uploading. The solution I found was to set the cachePolicy of the urlRequest to NSURLRequestReloadIgnoringLocalAndRemoteCacheData. (There were a few other networking bugs I encountered too which only occurred on iPhone 5.)
Are you getting the timeouts on apps that are build against iOS SDK 5.x running on iOS 6 (ie your old builds. If you don't have access to an old build, how about the one you have existing on the App Store?).
Or are your symptoms ONLY occurring for new builds with Xcode 4.5 against iOS SDK 6.0? If the latter, and you really don't want to give ASI up, (and you don't want to implement any of the new iOS functionality), then you could consider building against iOS SDK 5.x instead of 6.0. See my answer here for instructions.
If you need to implement new iOS 6 features, or iOS 6 actually broke your implementation of ASIHTTP (built against iOS SDK 5.x), then you should consider other networking options. It's been over a year since Ben advised developers to seek other options, with good reason.
iOS6 has serious problem related to Wi-Fi. We use ASIHTTPREQUEST. We find small file downloads work fine, in some case large file(10MB above) downloads too, but after the download, we keep the device idle for a minute, again you try to add operation to the queue. The app crashes.
Initially, we got many Network unavailable alerts, though the internet was available. Later, we changed the Wi-Fi setting security mode WAP to NONE. Then for sometime we did not find the network unavailable error, as well downloads were ok..
However, when the server itself becomes loaded, the connectivity and download becomes to halt at mid of the progress. I have noticed this behavior, even in native SDK facebook app.
The simulators work very fine, even the devices like iPad1, iO5.0, iPhone 4 with iOS5.0, the never crash.
I sum up..Apple half baked the iOS6.0, may be the iOS6.0 is suitable only for iPhone 5,the new antenna structure. Unless Apple fix the iOS6.0 issue may not be solved.

Which BlackBerry Devices/OS to target? (July 2012)

We have a fairly simple mobile application, completed for iPhone and Android that does the following:
queries a web service to verify the user's account information
display an animation to show that the user, in fact, has a valid account
We got the application working very quickly on a PlayBook by using the Android version.
Now the customer has asked us to explore getting it to work on other BlackBerry devices.
None of us know that much about BlackBerry, and the main source for our question returned from google searches (http://us.blackberry.com/developers/choosingtargetos.jsp) comes up as 404 page.
According to this chart there is still a wide variety of devices in use. Which ones does it make sense to target?
Thanks
I had posted an answer last year about this here on stackoverflow, but as you noted, that link has recently broken.
The only thing I've found that's similar is this BlackBerry developer page. It shows, for example, that paid apps are being purchased by devices that are about 97% on OS 5.0 and above.
From what you've told me, I don't know that your app is going to be that different on different devices, aside from maybe the obvious smartphone vs. Playbook difference. Different devices certainly have different screen sizes, so you'll need to make sure your UI is coded to handle that gracefully.
If you guys are new to BlackBerry, you might want to stay away from OS < 5.0. There are some things in prior OS versions (e.g. location services / maps, browser, and networking) that are a little tough to work with, and with such a small percentage of paying customers still on OS < 5.0, it probably isn't worth it to you.
So, I guess I'm recommending that you target specific OS levels (e.g. 5.0+). That will be a bigger driver for how you build your app, than a specific set of devices. This is because each OS version adds more and better APIs to use.
Once you've decided which OS to target, then you should download the SDK for each major OS. For example, if you use the Eclipse BlackBerry plug-in, you can install the 5.0 SDK (aka component pack), the 6.0 SDK, the 7.0 and 7.1 SDK.
Once you have those SDKs installed, you'll then have a bunch of simulators (each SDK has a simulator folder). Run your app on all those simulators, and that'll probably be a good start.
Of course, there's no substitute for running on real hardware, too, but if your app does mostly standard things (not interacting with hardware sensors, just displaying web pages, and making HTTP requests), the simulators should give you a pretty good test environment. They certainly will give you all the screen size configurations.

Is it worth it to write BlackBerry apps for the older OS with BBX coming out?

As a mobile app developer on all platforms, I am interested to know if it is worth it to write BlackBerry apps for the older OS now that BBX is coming out. I heard the new OS will have an Android player that will supposedly run Android apps on it. It seems that any apps written for the older OS won't be compatible with the BBX OS. Also, is using WebWorks a viable option? What do you guys think?
The road map ahead for developing for BBX announced at DevCon is:
HTML5, WebWorks, Adobe products (Air)
Native C/C++
Android Applications repackaged to run on the Android Player
BlackBerry OS is deprecated after OS 7. That said however, there are currently 70 million (according to RIM) BlackBerry smartphones in use, none of which will likely ever support BBX. RIM will continue to support those devices and the development environments for them. If you only want to work in one environment, and want to support the greatest number of devices, both BlackBerry OS and BBX, then WebWorks is the way to go. If you only want to support the PlayBook and BBX devices then you can use any of the approaches listed above. If you can't do what you want in WebWorks, or want to support devices prior to the introduction of WebWorks support then you will have to use the BlackBerry Java Environment.
At some point in every product line you will come to the end of useful life of a product and, as a developer, have to face moving on into the future. It is going to be worth while developing for BlackBerry OS as long as doing so helps you achieve your goals, what ever they are. So you have to look at your target market and decide if it includes those users who will be carrying BB OS devices, for probably at least the next 3 years, or not.
That's correct, legacy BlackBerry code will be useless:
DevCon update: BB-Java is dead, no java support for QNX.
By the way, the Android player will have several limitations too. Your best bet is C++ for BBX. Luckily, BlackBerry market share is declining and there's not a single BBX device out there yet.
Update: New BlackBerry 10 (as BBX is called now) phones have just been released. Here are the final dev options:
Native C++ API (optional libraries are available)
Android API, partial support
Adobe AIR API, partial support
HTML5 API, partial support

Resources