Best Practise for Android

[nevil...@gmail.com]

Hi everyone,

I'm migrating an Android app from a REST endpoint to gRPC, and so far things are going well. I just have a few questions on some aspects that I'm unsure of, I hope that someone can help me out.

1. Should I be making RPC calls on the main thread? I've been doing that so far with blocking stubs, and performance is good, but sometimes the main thread gets infinitely frozen. I don't know if I'm perhaps not handling errors properly.
2. I've so far been initialising a new stub/connection on every activity/fragment, would this mean that multiple HTTP connections are open? Would initialising a single stub in my Application be a better solution? I just haven't tried it out as I don't know how I'd tell if there's a difference.
3. I'm using Node.js as my server, and so far I've struggled with using an async connection, I've looked at the examples a few times, but I'm still struggling. Is there anyone who can point me to other resources on the net? Unfortunately for me, most people using gRPC in public/GitHub are using the golang version.

Thanks in advance

Neville

[Carl Mastrangelo]

Answers inline 

On Tuesday, August 2, 2016 at 2:30:20 PM UTC-7, nevil...@gmail.com wrote:

Hi everyone,

I'm migrating an Android app from a REST endpoint to gRPC, and so far things are going well. I just have a few questions on some aspects that I'm unsure of, I hope that someone can help me out.

1. Should I be making RPC calls on the main thread? I've been doing that so far with blocking stubs, and performance is good, but sometimes the main thread gets infinitely frozen. I don't know if I'm perhaps not handling errors properly.

If you are using the blocking stubs, then no you should not make calls from the main thread.  Under the hood, gRPC will run your requests on the network threads, and an application provided Executor.  (or a  default, if you don't set one).  However, waiting for the RPC to finish would still happen from the main thread.  You can use the Future API if you would like a nice way of handling the response from a different thread.  Note that RPCs will not time out if you don't provide a deadline.  You can use stub.withDeadline() to set one.

 

1. I've so far been initialising a new stub/connection on every activity/fragment, would this mean that multiple HTTP connections are open? Would initialising a single stub in my Application be a better solution? I just haven't tried it out as I don't know how I'd tell if there's a difference.

Yes.  You should create just one stub and let it handle the connections.  It will automatically create and release connections as needed.  Stubs should be safe to use by multiple places. 

[nevil...@gmail.com]

Hi Carl,

Thanks for the response, I've added deadlines as a start, so my app is hanging far less. I'll be moving to worker threads and trying out the async API. I'm fairly inexperienced with Java, so the Future API looked like Greek at first read, but I'm sure I'll figure it out.

I'm also going to go with one stub like I've been doing with a shared websocket.

Thanks again

Neville

[Eric Anderson]

On Wed, Aug 3, 2016 at 9:45 AM, <nevil...@gmail.com> wrote:

Thanks for the response, I've added deadlines as a start, so my app is hanging far less.

In v1.0.0-pre1, we now have some new options that may help prevent/detect hangs. If you're having trouble during periods of activity, you can set enableKeepAlive() to have gRPC monitor the connection. If you're having trouble after periods of inactivity (e.g., you do a request, wait a minute, then do another request, and that second request hangs), then you can set idleTimeout() to have gRPC close the connection after a period of inactivity. Take a look at the release notes for a little more detail.