Connect to ttn account from android app and retrieve all applications

Please forgive me if my question has been asked before, I have done extensive search but didn’t see what I was looking for. I am developing an android app that will allow me to query a ttn account so that I can see all available applications and I can select any of the application and then add a device.

I have been able to find rest api to add a device but nothing to obtain all applications with specifying the application id. I hope I have been clear enough.

Any suggestions will be greatly appreciated. Thanks!

P.S. I am writing my android application in Java.

See https://www.thethingsnetwork.org/docs/network/account/api.html#get-applications

1 Like

Thank you very much for reply. Much appreciated. I was trying to test this using postman but I don’t know know how to get a bearer token. Any suggestions?

You’ll need to implement OAuth, and request an OAuth client id for your application: https://www.thethingsnetwork.org/docs/network/account/clientid.html

1 Like

I honestly can’t thank you enough for your quick reply. While trying to request a client id, I had this error

"INFO Testing Callback URI: com.XXXX.fipy:/oauth/callback?code=test&state=test
ERROR Callback URI test failed. error=Get com.censis.fipy:///oauth/callback?code=test&state=test: unsupported protocol scheme “com.XXXX.fipy”

What should a valid callback uri looks like for a native android app?

The OAuth 2.0 protocol is very well documented, and is not at all specific to LoRaWAN, so I’m not going to help you with that. See OAuth 2.0 Beginner's Guide - DZone, OAuth 2 Simplified • Aaron Parecki or one of the many, many, other resources.

Also, beware that in V3 things might be very different. I’ve not checked for the differences, and I’ve no idea when V3 is to be expected for the community network, but you’ll have to decide if it is worth your while to implement things for V2.

That seems weird on many levels. Why is the domain backwards? This is not some Java package name, it should be a true, operational URL to which TTN can send OAuth requests and for which TTN should get a valid response before they’ll issue a client id.

(The colon without a port number, and the missing slashes are not valid for a URL, and it’s missing the http:// or https:// protocol prefix, which is why TTN now erroneously derives com.XXXX.fipy for the protocol instead.)

Thanks!

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.