I extracted android bt stack from AOSP and compiled it on arm.
I implement an application that connect via bluetooth with the phone and provides metadata and controls the volume.
Currently the application can connected via A2DP, using the interface bt_av.h but now i meet the problem that it does not receive the avrcp callbacks related to playStatus,track_change, attributes provided by the interface bt_rc.h.
Studying the AVRCP protocol, it say that at startup the application have to request register_notification_cmd and getcapabilities_cmd but the intrface bt_rc does not support them.
Please give me an idee how to use this interface to access title, artist, and so on and the callbacks specified in bt_rc.h.
Thank you for support.
Related
I understand GeneXus has the 'External Object' feature, which I can only assume is used for setting up API calls, however, I can't seem to find any documentation online for doing this. I have an external software and I wish to run a GET API call (ie api.domain.com/example) and input the received data into a transaction in my GeneXus software. Any way of doing this?
For calling HTTP APIs you should use the HttpClient Data Type.
&httpclient.Host = "labs.genexus.com"
&httpclient.BaseUrl = "/mobilecrm/rest/"
&httpclient.Execute('GET','WorkWithDevicesCompany_Company_List_Grid?fmt=json')
&companies.FromJson(&httpclient.ToString() )
Look at this sample
External Objects are used to integrate native objects, such as External Programs packaged as DLLS (.NET) or JARs (JAVA). This seems not to be your case.
Is byte-buddy agent capable of overcoming Attach API restrictions e.g. "new method definition", "static variable changes" ? I can see that redefineClasses method is being called from Agent Builder, but not sure if this is also following the same restrictions as the attach API.
I am trying to understand whether I can do the following:
1) Load the agent jar using an application class loader e.g. ParallelWebappClassLoader. My application is a servlet webapp and during runtime it uses the above classloader to load all application classes.
2) Fully redefine my classes i.e. any method addition/updates and static/local variable changes/updates/addition.
I do have an agent which currently works within the Attach API restrictions, but I am struggling to delegate the class loading from System Class Loader to application.
Many Thanks,
This is a restriction of the Java virtual machine you are running. Byte Buddy is capable of "fully redefining" a class by using its API but most VMs will reject such changes. Have a look at the dynamic code evolution VM for being able to apply such changes.
I'm looking for design advice for a domain model scenario I have.
Let's say I have have a squad of Robots, each controllable via a wireless network connection.
I have an IRobot domain object that represents a real-world robot. The interface looks like so:
public interface IRobot
{
void MoveHeadUp(int toAngle);
void MoveHeadDown(int toAngle);
int GetHeadAngle();
}
Example scenario: A virtual robot is shown in a GUI. In offline mode, the GUI shows what would happen if we tell the domain object (IRobot) to raise its head 5 degrees.
In online mode, the GUI would show the robot move AND the command would be sent to the physical robot and it would move as well.
I'm trying to add remote capabilities around this domain object, ie. getting/setting remote state via Ethernet or serial, etc. I don't want to pollute the domain object with network connectivity issues.
What is the best approach to implement IRobot domain behaviour and keep remote connection implementation details separate?
My take on this is messaging.
All of your commands (and that's what you're giving your robots), could be efficiently communicated over whatever you need (transport of your choice) and your robot (virtual or physical) would receive the command and act on it.
You can think of these robots as endpoints. Each endpoint has a name/address. You're dispatching a command to those robots and it's no longer your concern how on the robot (physical or emulated) command is executed.
You have mentioned
In online mode
Does that mean you also have an offline mode? If so, I'd look into messaging for sure.
We're currently working on a Worklight project using Dojo (more specifically dojox/app). We managed to create a basic example with a store, model, controller and a view. However, now we want to connect this to our Worklight adapter.
What is the best approach in connecting a Dojox/app application to the backend? We were thinking about feeding our store with the data from the Worklight adapter, however, we need to do all CRUD operations and our data should be in sync with the server because multiple users might be working at the same item.
The best general solution I can think about is using a JsonRest store, but we're using the WL.Client.invokeProcedure function that calls our adapter, so we're not directly using the service.
We found a solution by using the WL.JSONStore from WorkLight. The API of it isn't compatible with the dojo/store API (logically since it wasn't meant to be), but we wrote a dojo/store API based proxy class which does nothing more than translating and forwarding calls to the WL.JSONStore.
I don't usually program in the .NET framework however I've needed to use it to create a simple exe application that logs data from some measurement equipment. I want this application to have an automation interface with a couple of methods. I've done this before using Delphi/Pascal and it was very straightforward, and I can create a Class Library in Visual Studio that registers itself and the methods and can easily be interfaced with but adding a ComClass to the windows form application doesn't work, can anyone point me in the right direction?
This started as a comment but just kept growing, hopefully i am not off track ...
You can only register a dll. So the short answer would be to add a class library to your project and put the com class in there. This would allow you to share the functionality of the class, but not the same instance of that class.
I think your problem is that you are trying to establish Interprocess Communications. My immediate suggestion is not to do that, at least at first.
For a start you could have your com app interface with a .net class library which would log data. You could then have another project with a .net executable that displays the log, and updates periodically. Now you have .net code on both sides of the fence and can start investigating ways to get them to talk to each other.
The hard part is invoking methods and returning values. If you really need a responsive system you can investigate named pipes inter-process communication, or using a WCF service with callbacks between the two systems. The problem is that in either case you are hamstrung by the class library not being hosted by .net so you have limited functionality (no config file etc). If you can put up with a time lag I would suggest simply starting with writing messages to a local datastore and then polling from each client, every 30 seconds or so. For example the app would create a message saying "give me measurement A" and then start polling every second. The DLL would have a timer and within 30 seconds would read that message and write its own message with the measurement, which the EXE would read and then display. Once you get that system up and running you can decide whether you need to tackle inter-process communication, which is really just a different interface.