This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Questions regarding Mesh Android app:

thanks for the answer on the previous post.

What I came to know from our firmware engineer was that your initial version of the Android app could not support

1. multiple subscriptions for the nodes and

2. also adding clients

But he said he read somewhere that this functionality is there in the Android library but is disabled.

Can you tell me the handlers and data structures to do these 2 things in my version of the app?

Parents
  • Hi,

    1. The app supports mulitple subscriptions and is not disabled.

    2. Adding clients is not supported yet in the app. That's something that will be implemented in the near future. This is a more complex functionality that will need some time to build. Unfortunately its not something I can explain here. You will have to do it manually in your UI by creating the Models you need for this.

  • There is one more thing which many other developers might need. The pain point of this library is the documentation. My firmware counterpart gets a lot of documentation from the Nordic website. He gets explanations of each and every statement of the firmware SDK up to the point where the input and output parameters of each function, structure, object, etc. He even easily gets any getting started examples, intermediate examples .etc. The Android library, however, doesn't explain anything. Absolutely nothing. We desperately need documentation for the Android nRF Mesh library. Along with documentation of using examples and getting started guides .etc. I'm understanding your code in bits and pieces but I need concrete documentation on how to use it and what can be achieved with which statements to go ahead and start changing it for my use.

    Like if I want to send a certain msg byte array to a certain 2-byte element address then how do I send it? Where to get started? Which structures to use? I need to be sure what the answers are and not spend many hours implementing something that may be wrong.

  • Hey, If you look at each and every message that is implemented, there is a class for every message. In MeshConfigurationhandler.java  there is bindAppKey method. youll see that there is a class with ConfigModelAppBind. In this class there is createAccessMessage() method whcih creates a message and executeSend() that sends a message. Once you send a message, a received corresponding notification is handled in the MeshConfigurationHandler in the parseConfigurationNotifications method. This is as simple as it can be and can't that difficult to follow the same principle. This will be common for all messages that you will implement. If you just follow the same principle you can implement any message you want.

    Please note that this is not a production ready library yet and we have not implemented the whole mesh specification.

  • I can see in ModelConfigurationActivity.java where you have implemented 

    mViewModel.getExtendedMeshNode().getMeshNode();

    and

    mViewModel.sendGenericOnOff(node, .... );

    at lines 347 and 352 respectively. This gets me to the first question:

    1) Does that mean that I can get the mesh node reference I'm connected to using this piece of code from any of my Activities?

    Now, mViewModel is of type ModelConfigurationViewModel which in turn relates to ModelConfigurationRepository. This ModelConfigurationRepository, in turn, sends control messages to a mBinder which is declared in the extended class of BaseMeshRepository. Over here, mBinder is declared as MeshService.MeshServiceBinder. In the service, it looks like the Binder connects to a device and uses BleMeshManagerApi.

    2) So basically, my idea was that you can directly cut through all of the other structures and just use the mBleMeshManagerApi or MeshServiceBinder from the service to connect and send messages. Is this possible and is it the right way of doing it?

    3) Also, regarding the MeshService. I want to have control over the when the service starts and stops. How do I do that?

    4) I have an activity which connects to your MainActivity which does scanning and connection to the network in the respective fragments. Also, somewhere, (I don't know where) your MainActivity starts the MeshService. But after connecting to a Proxy node, if I press Back on MainActivity which goes to my activity, the service stops and disconnects from the proxy. I don't want it to stop and disconnect from the proxy. How do I achieve this?

    5) Now if that is solved, I want to use the mBleMeshManagerApi that the service is using. I will have to use either Binder or something of the service from my activity to send data to the mesh. How do I get the MeshService Context such that I can get the context of:

    mMeshManagerApi = new MeshManagerApi(this);

    at line 221 in the service. I guess that is only how I can use the service BleMeshManagerApi. How do I do it?

Reply
  • I can see in ModelConfigurationActivity.java where you have implemented 

    mViewModel.getExtendedMeshNode().getMeshNode();

    and

    mViewModel.sendGenericOnOff(node, .... );

    at lines 347 and 352 respectively. This gets me to the first question:

    1) Does that mean that I can get the mesh node reference I'm connected to using this piece of code from any of my Activities?

    Now, mViewModel is of type ModelConfigurationViewModel which in turn relates to ModelConfigurationRepository. This ModelConfigurationRepository, in turn, sends control messages to a mBinder which is declared in the extended class of BaseMeshRepository. Over here, mBinder is declared as MeshService.MeshServiceBinder. In the service, it looks like the Binder connects to a device and uses BleMeshManagerApi.

    2) So basically, my idea was that you can directly cut through all of the other structures and just use the mBleMeshManagerApi or MeshServiceBinder from the service to connect and send messages. Is this possible and is it the right way of doing it?

    3) Also, regarding the MeshService. I want to have control over the when the service starts and stops. How do I do that?

    4) I have an activity which connects to your MainActivity which does scanning and connection to the network in the respective fragments. Also, somewhere, (I don't know where) your MainActivity starts the MeshService. But after connecting to a Proxy node, if I press Back on MainActivity which goes to my activity, the service stops and disconnects from the proxy. I don't want it to stop and disconnect from the proxy. How do I achieve this?

    5) Now if that is solved, I want to use the mBleMeshManagerApi that the service is using. I will have to use either Binder or something of the service from my activity to send data to the mesh. How do I get the MeshService Context such that I can get the context of:

    mMeshManagerApi = new MeshManagerApi(this);

    at line 221 in the service. I guess that is only how I can use the service BleMeshManagerApi. How do I do it?

Children
  • 1) No, that's the mesh node that is passed in to that activity from the previous activity. This will point to only the node you want to talk to. Since its a mesh network you can connect to a random one and the configure the one you click and select from the main network menu. You might want to read up on Android services. A binder is used to connect to a service from an activity.

    2) You may do that and will make it very simple to you since you are new to dagger2, viewmodels and repositories. This way you can write your own app without having to dig deep in to our source.

    3) Like I said you might want to read up on Android services.

    4) If you have gone through the code you might see in the ViewModel attached to the main activity has onCleared(), disconnects and unbinds from the service and stops it.

    5) to get the context you will have to call getApplicationContext in the service

    If you're very new to Android I would suggest you go down the acitvity and service approach (you can find lot of documentation related to services) removing all the viewmodels and repositories. The reason for using viewmodels is to use the new Architecture Components in Android which makes it very easy to handle configuration changes and lifecycle changes in Android.

    Going down the service approach is only a change in the design and you can have all the api calls related to meshmanager api within the binder in the meshservice. This way you call the meshMaangerApi methods via the binder.

Related