I am to develop a mobile application for the Java ME platform that sends SMS messages, containing binary data. However, the application is to use a custom port for sending these messages (so that it can register itself and automatically receive these messages, instead of the standard messaging system of the phone).
My question is:
1) Are BinaryMessages to custom port widely supported in mobile networks worldwide? Or is this something "extravagant" that would work only with a few telecom operators?
2) Normal TextMessages tend to be broken down to multiple parts when their text exceeds the limit of a single message. Are BinaryMessages treated the same way, and if so, how can I deal with this issue (fragmentation) in my application? Obviously part of the message will not do the work and ideally I would like to get the full message when all of its parts are received. Is this dependent on the carrier network?
I realize I could test this out, but I can't run the test on many telecoms, just those in my (small) country, and this is crucial to whether this application should be developed, or not.
I tried looking for the answers by myself, but I failed. Sorry if these are trivial questions and thank you for your time.
I see nothing wrong with this question. I can only offer a semi-answer though.
It is true that it is up to the individual network provider to choose whether they want to keep all ports open, or not. Therefor you cannot assume that it's always possible to send/receive a text message or a binary message.
However, I was told by another JavaME developer long time ago, that it's very unusual for them to close the ports. (Aren't the same ports used for a lot of other protocols such as sockets and http? If yes, then surely they are always open. Closing them wouldn't make any sense).
If I were you I'd add some code to check if messages are sent, and then output some error message to the user about it if it fails. (If possible, also call some URL as a way of error-reporting back to you).
About the broken down messages, that's a good question. I have no idea. I would make some real-device tests to find out.
Related
I'm looking for some advice on best/common practices with writing a log for a game server I wrote in Java (first time with server/client concept and I've never done anything with logging). I've tried some Googling, but the keywords involved are kind of vague and not coming up with any answers to my questions.
I have a server with users, game lobbies, and games. I think that I should create a log to keep a history of everything that happens on the server. And in this log I think I should record status changes of both the server itself (startup, shutdown, commands being processed), and socket connections (new/lost clients, incoming/outgoing messages).
I'm not sure if that's the best thing to do, or instead/also have a log with more human readable messages like "Bob781 joined lobby #4." or "microman12 beat sun44 in a game."
Should I write logs to the console or to a file? (2 separate files?)
What formats are best or most commonly used? Should they be the same formats?
I've come across the "Common Log Format", is this the best format choice for socket connections? Can it be used for the server statuses?
Should I use something in java.util.logging or just output the strings myself?
You always want to look for existing solutions before starting from scratch. When you use/create the logging, I would suggest the following tips based on my experience
Make sure you can reliable retrieve the logs whenever you might need them.
Make it easy to find a log file based on what you're looking for. For example if there is a problem with a specific game lobby, you should be able to easily navigate to the file or directory of files that pertain to that game lobby in question. Nothing worse than having to parse a huge gigantic log file...
Make each logging message meaningful. Don't just log stuff for the sake of logging. You will want to be able to read a log message and know relatively where in the server code that message is coming from. This will help later down the road when you run into bugs in your server code.
Have each log message time stamped at the point it's created and not when it's written to the log file.
I am trying to elaborate SIP messages coming to an Asterisk server and edit them on the fly using Java.
AMI is supposed to work fine with that. Although I can't send any SIP messages though the socket, cause every-time I tried to edit chan_sip.c the server breaks down. So I haven't find a way to access this information from other classes of the manager. I don't want to save those information to a file or database cause this will delay the whole process.
Using Kamailio is not an option cause I want to make a comparison of both solutions so I need Asterisk.
Is there any path I should follow to get this done? I can't figure why editing chan_sip.c bothers Asterisk making him nonfunctional..
Seams like no way with your qualification. Task seams really complex for me(i have more then 10 years experience, including asteirsk internal and c/c++ programming).Try do that using dialplan only
Hí,
I'm doing my second App, and The second one is a little bit complex, it's backup tool.
In some devices works perfect in others not.
I would like if is there a way to do my own Exceptions catcher to my server or log cats or smth, and receive them, and known if my app needs some fix or not etc.
Greetens and thanks
David
As pointed out, you can use ACRA. The site states:
Acra catches exceptions, retrieves lots of context data and send them
to the backend of your choice.
and that is what you seem to need. The Quick Setup Guide is there on the homepage itself.
You can also look into BugSense which you can use as a back end for your ACRA.
If you are using ACRA, you can use BugSense as your backend.
The only change you need to do is specify in formUri BugSense's url
and your API key:
#ReportsCrashes(formUri =
"http://www.bugsense.com/api/acra?api_key=YOUR_API_KEY", formKey="")
I am looking to record movement based on GPS, and plan to record it on the laptop that is in the vehicle. It looks like GlobalSat BU-353 is a good pick, but I am not clear on how to write a program for the actual receive/record. The existing answer seems to be fore Serial, and does not appear to be helpful for USB systems. I could use a USB-to-serial converter with a Serial based GPS device, but I don't like this complexity.
Can you point me a working example? I don't mind using a foreign language (Python perhaps), as long as I can run it on Windows without too much installation/programming headache. Please point me to evidence that this can be done, and how. Preferably a working example that was tested with x USB receiver.
Also I would like information on what the risk of compatibility problems there would be. I would expect that there are many programs out there along with many GPS devices so that a standard has been established (like USB cameras), but is this really the case?
Look up Prolific Technology USB-to-serial converter software. You install it, then your USB device data can be read off of one of Windows COM ports. I'm using the RXTX library to read the com port that is getting my USB data (RXTXcomm.jar).
It's a bit of a pain, because you don't know for sure which COM port is going to be used, it can depend on the order things are plugged into the USB ports on the machine, etc. On some machines, the same physical USB port tends to gravitate towards the same COM port, however, so maybe that will make things predictable enough. Anyway, that's what I'm using to read USB data. At least it's the installed converter, which does not involve code, and everything is java from there.
Yes, there is a defacto standard for the GPS output, the NMEA data strings. All the USB GPS devices I've come across use this. Essentially, as soon as they're turned on (which means as soon as they're plugged in), they start emitting strings of data in the NMEA format. The first letters designate what kind of record is being reported, and the rest of the string is the data. I'm sure some of them also have query capability, etc., but given the nature of GPS programs in general it also works in a lot of cases just to have the device spit out the characters until someone unplugs it. Each string is less than some reasonable maximum number of characters (80? 132? don't remember), and is terminated with some kind of EOL. My code reads them all and only processes the ones it's interested in.
Hope that gets you started.
I'm trying to implement a Cometd/Bayeux server on Android using iJetty. The Jetty implementation itself works just fine serving static pages along with servlets. I am trying to up the ante a bit and create a Bayeux application on the phone but I'm having some trouble. I can hit the page that has the dojo cometd scripts on it, but I am unable to subscribe to the channel. When I view firebug/chome developer tools, I see a series of posts/gets that last a couple of milliseconds (~14). However, when I run a cometd application on a normal machine, the posts/gets last several seconds (~14 seconds) before timing out and reopening the connection. This second scenario makes sense to me with my understanding of how continuation in HTTP works. So I'm thinking that something is not allowing those connections to hang open and prematurely returning a value and consequently closing the connection. I would post my source but I'm not sure what to post short of posting everything...(it is open source though so if you want to have a look it's at http://webtext-android.googlecode.com).
So my question is, does anybody think that there could be some underlying limitation imposed by the Android system that is preventing these servlets from working? Are there assumptions that are made by the Jetty Bayeux implementation with regards to the underlying system? Or is it more likely that somehow I have a bad implementation of the ContinuationCometdServelt? I should note that all of the posts/gets from the client return 200 OK messages so I'm not inclined to think that the Android system is simply terminating the connection.
I know this is a bit off the wall and I'm definitely trying to do something a bit out of the ordinary but any suggestions or tips would be greatly appreciated.
In case anybody discovers this and has similar problems (this applies to all cometd implementations regardless of host), I discovered that the issue was with using the Google js library. For some reason, the dojo scripts I was loading from Google (1.4) didn't have a valid implementation of cometd. I switched my dojo script to the one that was used by the jetty-1.6.23 example and it works perfectly.