Is adobe AIR still not supporting UDP for mobile devices?
Yes and you will also have a hell of a time getting any native extension to work in Flash CS5.5 as well. Flash Builder has built in ANE support but CS5.5 requires you to publish with the command line adt tool so you can use -extensionDir to compile the native extension. I haven't tried FDT but look that up, it is free and I think it is just a plugin for elipse.
I'm curious why you want to use a lossy protocol on a device that's bound to have enough issues staying connected while mobile as it is. I presume fast updates to a game.
Does flash.net.DatagramSocket not work for you on mobile?
I only ever used it on desktop apps. There's plenty of working examples in the code linked above.
You're going to need a 'server' on each device running your app sniffing for a connection on a port to make any of this work. This isn't going to work outside wifi without a centralized solution. e.g. messages sent to a single central server and devices running the app get info pushed to them or request it from the server (not good if you need speedy netcode but fine for chat-esque apps).
Ok, that make sense.
I found a ANE file for iOS and Android for UDP, but can I add this extension in AIR and use it on a PC?
I guess you only need an Mac to compile them and make them, right?
An other question, do you know anything about if real-time data visualisation is possible with Flash 5.5?
I want to make a real time graph of temperature input.
I don't even think you need the ANE. If you look at the AIR DatagramSocket class I posted, as3 supports opening up a UDP socket. If and only if that doesn't work for you would you need an ANE.
You can use an ANE without a Mac, yes. I use the "Do not backup bit" ANE for iOS and it works fine. I code/publish on a PC.
Flash or HTML5 canvas would be perfectly suited to something like that. It has gobs of tools to draw dynamically. Take a look at the graphics class to see what's already built in. Google around a bit for chart and graph pre-made code as well. Sometimes you can find some prewritten code that's cheap and easy to use that would take you a lot longer to code yourself.
ANEs are extremely easy to use in Flash Builder. I use 4.6 and in your project properties there is a panel you can add ANEs to directly just as you add SWCs, etc. As you're setting up your project for the first time you even have a chance to specify ANEs during creating the project.
I have tried UDP ANEs with Adobe Air 3.2 SDK on mobile devices for a long time and it cannot use. When i tried to send datagram packet with send method it seem not be affected and the return value of FREFunction always be zero(0) in integer or false in boolean. I'm confuse to solve. Please help me.
I've used UDP Native extension from this link http://blog.aboutme.be/2011/12/14/udp-native-extension-for-air-mobile- now-with-android-support/
i downloaded the ANE and sources of owner's blog. i've tried his ANE file and it's not work for me. Then i import his source code to compile my ANE for debugging the result that return by forcing the return value(integer) to 111 in send method under ANE file but it return only 0. In orther hand when i remove the routine that send datagram packet it return 111. I still don't understand why when it send datagram packet it always return 0 and not affect anything.
Oh, I thought you were asking if ANEs were supported in Flash Builder. I'm merely saying it has great built in support for ANEs. On that specific UDP ANE, I can't say if it works or not, I've never used it. Just that Flash Builder supports ANEs in general.
I don't even think you need the ANE. If you look at the AIR DatagramSocket class I posted, as3 supports opening up a UDP socket.
The page you pointed to is the official AS3 documentation about DatagramSocket and it says it is not supported on mobile devices (yes, f***ing unbelievable).
Are you saying it actually works despite the documentation saying it doesn't? Did they implement it and forget to delete that sentence from the documentation? Or did you only try on desktop?
Since the last date i've posted, i still not figure out how to implement UDP socket on mobile devices. But i'm using tcp socket instead ( this is very bad for me ) by using my ANE file because the original tcp class ( ServerSocket Class ) does not support on mobile devices too.
Oh sh** I thought I would use TCP as a (bad) alternative, but then that's not supported either. F***ing unbelievable, it's impressive how the Flash platform still survives despite all the effort Adobe puts in killing it and rendering it useless.
If you're using UDP you're clearly more interested in speed of updates rather than integrity of the transfer so I presume Apple (not adobe obviously) wants to cut down on people trying to do anything realtime with their device (gaming, etc).
This has been coming since before the smartphone. Service providers up to their same business model. Find the most premium feature, lure people in, cry about abuse and modify pricing models to rake in the cash. AT&T knew very well (since uh, home users have have unlimited internet for a decade before) that users will get used to using unlimited bandwidth. BTW, expect a non-unlimited home internet service pricing model, real soon. Now that people are hooked on using tons of bandwidth, welcome to the new long distance or the new roaming charge model.
Do you really think it costs more than a fraction of a penny to send an electron from inside the same state you're than across the country, if you own the wires? Large tel companies have only just now began debates about charging each other premiums for using each others networks. Before, they simply decided the +/- of each others usage wasn't worth as much as opening up communications was and no companies paid a single cent to send your phonecall across multiple companies lines.
They just charged you for it because you'd pay.
Welcome to your issue with UDP. You're trying to stream something game-esque that requires no integrity like a file transfer or you'd use the heftier TCP protocol.
With people now actually used to the idea of data caps after they successfully suckered people for years with unlimited, cried about network abuse (like they didn't forsee it) and removed the unlimited option, they're making sure it's not blindly easy to get a million calls the complaint department. As much as you want to recreate Crysis on a phone and let people play each other in realtime, they know the data usage is completely oblivious to the common user who plays on their (for now) unlimited home internet plan. They have no idea a couple hours of gaming can take a gigs worth of bandwidth, depending on the efficiency of the netcode.
They won't make it easy for you to use a persons bandwidth so the ISP gets nasty phonecalls because your app used their monthly bandwidth in 30 minutes. So it's of no suprise they're removing the ease of access to the protocol. And you should be very cautious to users of your app to explain how much bandwidth you require to use if you sense they are not on wifi. Otherwise expect nobody to use your app.
Interesting insight, except it does not apply here.
Sending and receiving UDP packets in Android (and I believe also IOS) is trivial and can already be done in native code without any difficulty. There's no limitation.
Adobe AIR has an API for sending and receiving UDP packets easily fron AIR applications which works on Desktop platforms.
So the ridiculous part is the inhability to use the UDP feature in AIR on mobile platform. This is entirely about Adobe, has nothing to do with either the device manufacturer, the OS vendor or the ISP. They simply didn't implement the "bridge" between the UDP API in AIR (the DatagramSocket class) and the UDP functionality in Android and IOS, which already exists and is fully functional. And there's no good reason for that.
Same can be said about TCP server socket.
By the way the discourse about easily using costly bandwith already applies to common network traffic such as http and is already addressed at the host OS level. For examle in Android you can chose whether or not to allow apps to use the network when there is no wifi connection. UDP adds no additional concerns or issues.
And by the way there's also local network traffic, which has no pay-for-bandwidth implication at all.
Adobe knows ANEs are the answer for almost all of these limits. As long as you're not trying to use a visual component an ANE will solve the issue. You can't port everything and ever expect to make money. AIR3.3 should come with the do not backup bit and a bunch more features as made mandatory. However I highly doubt you will see UDP.
Realtime gaming with inefficient netcode can consume as much bandwidth as video chat. Notice as soon as front facing cameras became available the ISPs immediately grandfathered the unlimited plans and slapped limits? That was planned. I bought the first phone in the USA to have a front facing camera, the HTC EVO 4G from Sprint. I saw where that was going, right away.
iOS devices do not show the user upfront permissions, only android devices do. When you load my iOS app I can easily consume 250mb in a very short time. I feel making socket usage a little tougher for game and video favored protocols who don't care about dropping packets was intentional. If you're smart enough to use an ANE, hopefully you're smart enough to both refrain from abusing the users data limits as well as warn the user about the data usage in a visible way. An options panel with bandwidth usage and/or a toggle to warn the user at a certain data usage would go a long way for games to keep users from rating you with 1 star and ranting about a $300 monthly bill.
Again, I feel Adobe did this deliberately. They did not completely block it, they just didn't make it easily abusable. Even though, well, it is. If it was completely intentional and demanded by the ISP/etc then you would see the ANEs unable to access those frameworks but they're clearly not blocked.
Adobe knows ANEs are the answer for almost all of these limits
ANEs are for extending functionality. Having to use ANEs to re-implement functionalities that are already in the core language for other platforms is ridiculous, and if that is by design it's a terrible design.
If you're smart enough to use an ANE, hopefully you're smart enough to both refrain from abusing the users data limits as well as warn the user about the data usage in a visible way
And what if you're smart enough to do that, and malicious enough to not do that?
You avoid abuses by enforcing limitations in a way that both does not make legitimate things more difficult to do, and cannot be overcome by smart-enough people. Not by degrading the quality of the API and implementation of a language. I wouldn't be surprised, however, if you were right and this was precisely what Adobe is doing.
Again, I feel Adobe did this deliberately.
Maybe, who kows. I don't think so, I think they simply have deemed not worth the effort to fill this gap. Which is consistent with their scarce sense of what is worth investing effort into (such as fixing critical bugs). If they actually did it deliberately for the reasons you mention, then they reveal an even deeper incompetence than I imagined.
They haven't implemented every single thing so I'd wager to say the demand for UDP is pretty small.
I'm not trying to make it out to be a gigantic conspiracy. However as I said, money being king, eventually you need to come to a release. If I was behind on the development cycle some bean counter was warning me about and my job is on the line, I'd easily chalk as much up to ANEs as I could. UDP is a perfect example. Low overall desire for usage, especially in the mobile context, and implementable via an ANE.
HTTP traffic? Well, that better work or you're dead obviously.
I've tried the ANE extension for UDP packets mentioned above: http://blog.aboutme.be/2011/12/14/udp-native-extension-for-air-mobile- now-with-android-support/
It simply doesn't work.
Does anybody know any other ANE that works? Or has anybody had success using this one?