I am trying to build an NFC enabled application that transmits data to another device via Android Beam (pushing a NDEFMessage).
While I know there is a success callback void onNdefPushComplete(NfcEvent event), I can't find a failure callback, which would be really useful.
I tried to think of other way to sort of guess whether the transfer happened, if it succeeded or failed but cannot really find anything satisfying. Even a dirty timer would not work since I cannot know for sure when and even if the user actually starts the beam.
I feel pretty much bound by the API since the OS is handling most of the functionality and the application is only providing the message to send.
Any suggestions, something I might have missed? I'd rather avoid rooting the device if possible, but if it cannot be accomplished without tinkering with the core NFC code, then so be it.
Cheers
No, there is no such callback. Or a notification or anything that would give you a clue that things didn't worked.
Unfortunately.
In general the Android Beam API has not been designed with error handling in mind.
Related
I'm not very experienced when it comes to implementing Android apps which make a lot of use of Services and I couldn't find any good advice or examples to help me on SO or github (or by just googling) so I decided to ask my own question.
When my app is started, it needs to start discovering nearby Bluetooth LE beacon devices and it has to continue doing so at least until it's gone to the background. The only thing I need from these beacons is to get the basic data (like the UUID) of the one whose signal is the strongest.
What is the best approach to achieve this?
Currently I've got only got a regular Service which runs the startLeScan() method on BluetoothAdapter as soon as anything is bound to it. However, I've got more than 1 Activity in the app and I don't think binding to the Service and unbinding from it in each of them is the best thing to do. I thought about starting the Service instead of binding to it but then again stopping it could involve a lot of coding - it isn't exactly easy to determine when an Android app is put into background afaik.
Any hints and advice could be useful.
Sounds like you are using iBeacons. Check out radius networks beacon library. It has a bunch of examples and instructions for how to download. Here is the link:
http://developer.radiusnetworks.com/ibeacon/android/pro/download.html
Included in the library are methods for discovering new beacons and easily getting there info (UUID, Major, minor, etc..). They even have examples showing how to do it.
In addition to other answers, I recommend this iBeacon scanning app.
BeaconBox for Android
It is useful for you to testing your beacons on smartphone.
I hope that you reach your goal.
Right, I don't consider myself an expert so feel free to correct me whenever I'm wrong.
I'm dumb - I didn't realise that the startLeScan() and stopLeScan() methods both take a BluetoothAdapter.LeScanCallback parameter and that this callback actually contains a method named onLeScan() called asynchronously upon a BluetoothLE device being scanned.
That means that no Service is necessary at all - it's enough to actually implement the onLeScan() method and it should do. I also put all of that in a singleton class instead so it's accessible from everywhere in the app.
I'll mark my answer as the correct one for now but do answer if you've got a better solution.
I have been working a bit on reading radio logs to retrieve USSD replies, rather than the aidl,
though I am not yet sure which suits my purpose better. I am still hoping to trap menus as well as simple exchanges.
Anyway, I can now read the replies programmatically, but they still land onscreen in a system dialog that I need to press OK to dismiss.
Is there a programmatic way to dismiss this system dialog?
What I am writing is some code that will execute my own USSD (ie 3rd party from carrier) on an android used without human interfacing (there is no one present to press OK). It's used more to send info to the server than to receive info back. I did this on an old Wavecom modem ages ago, so it has been a frustration discovering how difficult this was to do in Android.
In as much as the documentation is minimal, this app actually does a good job intercepting USSD responses:
https://github.com/alaasalman/ussdinterceptor
I have having problems with a WSDL/SOAP service call in an app I have built in flash builder for mobile. I have connected to the service using flash builders built in data/services functionality.
For the most part, the service call works perfectly but once in a while it will cause the app to crash - on my android device it completely locks up (spinning animation stops) and then Android informs me that the app is not responding and asks if I want to close it.
The crash appears to occur quite frequently but not with any pattern. One time it happened on my third attempt, another time it took approximately 30, a couple of times I could not get it to happen and most times it occurs somewhere in between.
It appears that the crash happens after a service call is made but before any response is received. Neither the success or the fault listeners are ever fired. I am very confident that I am sending exactly the same variables to the service every time.
I have used web service calls in other apps without trouble so I have to assume there is something in this particular build that is causing problems but I can't seem to find anything.
Any thoughts on possible causes, things to test or even a solution would be hugely appreciated.
Thank you,
Jamie
Your question lacks essential details, so now I can suggest you to setup Charles proxy and monitor you requests trough it.
If you send too many requests simultaneously, you shall not be confident in fault/result events as air runtime has limitations (in any case, it is a good practice to handle request timeout).
I've released my second game project on the Android Market this week, and immediately had multiple 1-star reports due to force closes. I tested it on many handsets and many emulators with zero issues. I'm completely at a loss for how to proceed and looking for advice.
I use Thread.setDefaultUncaughtExceptionHandler to intercept and report uncaught exceptions, then close gracefully. The people reporting force closes aren't getting to any of that, even though it is the first thing set in the application's main task constructor, and everything is wrapped in try/catches throughout. They are also reporting that there is no "Send Report" option in the force close popup (providing the Developer Console error reports), so I have absolutely no way of knowing what the problem is.
Uses Android 2.0, with android:minSdkVersion="5". Only Permission required is INTERNET.
(on Android market as 'Fortunes of War FREE' if you want to test)
I'm a bit surprised about the missing "Send report" button. What API level did you build the game with? I usually build the level with your minimum API level to make sure you're not using any API calls beyond that, but then switch back to the highest API level so you can use functionality like "install to SD".
I'm sure there's at least one user who wrote you a mail. Can you ask them to install LogCollector and mail you the log?
Btw, in general, I wouldn't use Thread.setDefaultUncaughtExceptionHandler so there IS the option to send a report. (It's ominously missing in your case, but normally, it should be there.)
Btw btw, the exception handler applies to the current thread. If you have an OpenGL app, maybe the crash happens in the GL thread?
I'm not sure if I understood you correctly, but as far as I know Android only shows that report dialog if you use its default UncaughtExceptionHandler.
Try this:
In your UncaughtExceptionHander's constructor, call Thread.getDefaultUncaughtExceptionHandler and save the returned object in a variable (let's call it defaultHandler). In your Handler's uncaughtException() do the things you want to do, and then call defaultHandler.uncaughtException() afterwards.
Maybe something you should know:
In my experience, your Context isn't functional anymore at uncaughtException(). So, you can't send broadcasts, etc anymore.
By the way, if you really wrapped everything in try/catch, that could be the reason why error reporting doesn't work as expected? :P
Good luck
Tom
Perhaps the force closes are caused by stalls, rather than exceptions. Users may not notice the difference. This kind of problem can occur more often if users have CPU hogging services running at the same time as your application, which explains why you're not seeing the issue in your testing.
Permission Internet sounds a lot like you try to transfer data from the net, which is very fast in your local LAN, but all of a sudden becomes slow (and time consuming) when people try this over their GSM connections.
If you then do the data transfer in the UI thread, this one is blocked and the system detects the block - but then this should end up in a "Did not respond" -- but then I've seen one user report an error with in the market on my app that was such a slow down cause.
I would like to know how to intercept incoming calls and also how to forward them. I know there are several questions regarding this topic here and elsewhere on the net, but all the answers use the android.intent.action.PHONE_STATE action which is broadcast always after the phone begins to ring and the call screen is shown.
That's why I'm looking for a solution where i could intercept the call in an early stage before any notification (ringing etc..) has been done. I would like to know if maybe this is possible on a platform level in native code and if yes how ? Or perhaps with some kind of trick with the SDK ?
In general, if you can't do it in Java, you can't do it in the NDK. Most of the time the opposite is true: You can't do MOST things on Android in the NDK.
I don't know of a way to do that, and frankly doubt it exists: It would be a huge security hole if you could download an application that would forward calls to another number.
You may want to look at this source code, it may help you : http://code.google.com/p/auto-answer/
None of the existing apps in Android can forward a call based on a given number. All they can do is forward all or nothing. There's one app in particular (cBlocker) that can forward calls on schedule besides blocking incoming and outgoing calls and SMS based on rules.