Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

And as a manufacturer, we'd love to get our hands on this guide.

It's really tough, trying to figure out how to deliver a M2M platform and accompanying SDK based on Brew without service provider implementation specifics (just how *does* one correctly implement IModel?)

Without more involved information it's taking us through a lot of guesswork to bludgeon our API development efforts along when there are almost certainly better ways to deliver value on the Brew platform...

Jerry  :-)

 

 

 

Well, I don't blame the nice folks doing support here.  I blame their lawyer overlords..

Well, I don't blame the nice folks doing support here.  I blame their lawyer overlords..

what are you trying to implement a service for? what kind of information are you looking for regarding services?

what are you trying to implement a service for? what kind of information are you looking for regarding services?

As already stated, show me how to implement the IModel interface properly.  Not that I can't implement it but that I had to implement it without any direction or guidelines.

As already stated, show me how to implement the IModel interface properly.  Not that I can't implement it but that I had to implement it without any direction or guidelines.

And I am looking to implement a service as the code is not an app but will be integrated with OEM code.
So some documentation would be nice.

And I am looking to implement a service as the code is not an app but will be integrated with OEM code.
So some documentation would be nice.

The general guidelines actually are described in the programming model doc. See:
https://developer.brewmp.com/resources/tech-guides/programming-model/cod...
Basically writing a service is not much different from writing an in-process class (the same concept as extension class in BREW 2x/3x) except that:
1. The interface needs to be remotable and therefore you need to use IDL to define your interface
2. Since right now all the service can only be instantied in the Kernel process, the service code needs to be thread-safe since kernel process outside BREW shell is a multi-threaded environment.
3. The service can only be implemented in .mod1 and you can *not* use ISHELL or any BMP API that has SHELL dependency.
 
3. above is currently the challenge for most developers because there is no documentation yet (in progress) on exactly which API has SHELL depedency. However, currently service development is more or less limited to the OEMs and if you are an OEM, you should be able to directly work with Qualcomm's customer engineering team assigned for your OEM to get further support on issues you have encountered with any particular API in your service. If your service doesn't use any platform API, then of course you won't run into this type of issues.
 
Thanks
-Tony

The general guidelines actually are described in the programming model doc. See:
https://developer.brewmp.com/resources/tech-guides/programming-model/cod...
Basically writing a service is not much different from writing an in-process class (the same concept as extension class in BREW 2x/3x) except that:
1. The interface needs to be remotable and therefore you need to use IDL to define your interface
2. Since right now all the service can only be instantied in the Kernel process, the service code needs to be thread-safe since kernel process outside BREW shell is a multi-threaded environment.
3. The service can only be implemented in .mod1 and you can *not* use ISHELL or any BMP API that has SHELL dependency.
 
3. above is currently the challenge for most developers because there is no documentation yet (in progress) on exactly which API has SHELL depedency. However, currently service development is more or less limited to the OEMs and if you are an OEM, you should be able to directly work with Qualcomm's customer engineering team assigned for your OEM to get further support on issues you have encountered with any particular API in your service. If your service doesn't use any platform API, then of course you won't run into this type of issues.
 
Thanks
-Tony

In addition, in the VS/Eclipse plugins from BMP SDK, you can also generate service class template through "Add Class" for your project. 

In addition, in the VS/Eclipse plugins from BMP SDK, you can also generate service class template through "Add Class" for your project. 

I am more interested in the API interface implementations than the service execution environment itself.  Our purpose is to deliver "middleware" using Brew MP as a platform to distribute to third-party developers.
Obviously, it's better to fashion our APIs to resemble those most familiar to other Brew developers using constructs such as the IModel, IPort and other standard Brew interfaces.
The publicly available documentation is fine if one is creating a self-contained application, using the "client side" of published interfaces.
It falls very short when one is working to deliver API for other developers.   There is not adequate information in the current public SDK to implement the provider-side of the aforementioned interfaces (and others), even when the implementations are running as "in-process" extensions.

I am more interested in the API interface implementations than the service execution environment itself.  Our purpose is to deliver "middleware" using Brew MP as a platform to distribute to third-party developers.
Obviously, it's better to fashion our APIs to resemble those most familiar to other Brew developers using constructs such as the IModel, IPort and other standard Brew interfaces.
The publicly available documentation is fine if one is creating a self-contained application, using the "client side" of published interfaces.
It falls very short when one is working to deliver API for other developers.   There is not adequate information in the current public SDK to implement the provider-side of the aforementioned interfaces (and others), even when the implementations are running as "in-process" extensions.

it looks like what you are asking is more related to "how to implement an API that is very similar to how BMP APIs are designed", rather than "how to implement a service class". 
 
And to that question, most of the platform APIs are implemented as service classes so that the API's can be remotable and would enjoy many other benefits a service class provides. But I don't think there are guidelines currently on how to write a platform-esque API. 
 
 

it looks like what you are asking is more related to "how to implement an API that is very similar to how BMP APIs are designed", rather than "how to implement a service class". 
 
And to that question, most of the platform APIs are implemented as service classes so that the API's can be remotable and would enjoy many other benefits a service class provides. But I don't think there are guidelines currently on how to write a platform-esque API.