getAppProperty(String key) is instance method in MIDlet class. Since all midlet in midlet suite share same manifest/jad file, so why cant it be a static method?
If the phone runs several MIDlet suites inside the same JVM process, they all share the same MIDlet Class object.
If you then make the method static, it won't know which JAD file to retrieve information from.
Neither the CLDC nor the MIDP specifications prevent phone manufacturers from running several MIDlet suites inside the same JVM process. It is in fact more efficient to do so in a resource-constrained environment.
This is the most pressing issue you are asking about J2me? J2me is old dirty and most of API's interfaces suck.
On a scale of things that are wrong with J2me static vs instance of getAppProperty are sooo low I don't even think this question deserves an answer.
Further more I don't even think this question is answerable full stop.
Related
I tried to generate code for a device changing the implementation type to SharedLibrary and renaming the Entry Point to Device_Name.so. I was able to generate and build, but in main.cpp it kept a main function not a make_component to be called by ComponentHost. the device constructors deals with arguments that ComponentHost doesn't, like the Device Manager IOR. I believe this functionality extension implies changing the source code of ComponenHost. Is it part of REDHAWK roadmap? any comments on how can I make it work?
So are you trying to use the shared process space within a node to communicate between devices and services? Because I don't believe that there is tooling specifically for this yet, but I think there is a way to do this. Just to be clear I haven't tried this, but based on the test used by the bulkio ports to determine local vs remote transport usage, I think this will work.
If you look at the persona pattern, you'll see that there is a Programmable Device which is responsible for loading Persona Devices. Most of the details for this aren't necessary for what you're trying to do, but the pattern should be helpful. To accomplish communication between Devices using shared memory, you could generate a Programmable device whose sole purpose is to forward parameters from the DeviceManager to the Personas. The Personas would then act as your normal Devices normally do, just launched in the same process space as one another.
The code generators for the Programmable and Persona Devices are not yet integrated into the IDE, so you'll have to create a new Device project in eclipse for each Device you want (so that you'll have the spd files). Be sure to add the appropriate AggregateDevice interface to your Devices. This let's the framework know that multiple devices can technically be considered one entity, but you can also individually communicate with each. Also make sure that the Programmable is an Executable Device, since it needs to launch the Persona Devices. Then, from the command line, you can run redhawk-codegen - - pgdevice </path/to/programmable/spd> to generate a Programmable Device, and redhawk-codegen - - persona </path/to/persona/spd> to generate your Persona Device(s).
Once all of this is done, you'll notice the main function for your Programmable launches the Device like you described in your question. However, the main function for the Personas has code to launch the Device as either a standalone Device or as simply an object in its own thread.
This should allow the bulkio ports of the Programmable and Personas to communicate with each other via shared memory. Obviously this will break down if you attempt to push data out of the process, at least until someone adds interprocess shared memory via something like shm. Not sure if that's on the road map, but it would certainly be neat.
Update: It appears that interprocess shared memory was added in RH 2.1.2, so you should be able to communicate between collocated Devices, Services, and Components using that mechanism. This renders the above unnecessary, but I'm going to leave it for earlier versions of RH.
Let me know if you have any questions!
As of RH 2.1.2, the default behavior for Devices/Services/Components whose user code uses redhawk::buffer for the data memory allocator and the stream API for interaction with the bulkio port is to use a shared memory transport between C++ entities that are running in different processes
I would like to write a program that lists all DirectX3D applications running on a Windows System and displaying the resources they use. I know how to enumerate the adapters using the IDXGIFactory interface and the adapter outputs via the IDXGIAdapter interface. I also know how to find out the adapter used by an ID3D11Device using QueryInterface and GetParent. Though, I need the reverse: an enumeration of ID3D11Device which operate on a given adapter. You need to specify an IDXGIAdapter creating an ID3D11Device via D3D11CreateDevice. So there must be a connection. Are there any ideas how to get such an enumeration?
Thanks a lot.
You can try searching processes that have loaded directx dll. finding loaded dll
OR
You can place a global hook on D3D11CreateDevice and whenever some application calls it enlist that application.
I wanted to know whether is it possible to make use of COM component in other platforms like linux,etc..,
My question is that COM component is supposed to be registered with OS &
For that OS need something like registry so that client can use COM components.
Can anyone shed light on my question ?
If you want to have the ability to create COM classes by specifying a "string", and wish the OS can search for the correct binary library to load from as well as creating the actual COM class (object), then some form of registering is needed.
Other than that, if you only want to use COM-style interfaces (interfaces derived from IUnknown, IDispatch, etc) you can do that in any C++ languages (as long as the vtable implementation of that C++ compiler is compatible with COM).
Finally, some COM capabilities such as inter-process communication and remote invocation are provided as part of Windows OS. You will need to implement your own if these capabilities are needed.
The Wikipedia page on CORBA appears to have some references to a number of choices. Check the See Also section.
The wikipedia entry for Microsoft COM says in the "Overview" that "the interface standard has been implemented on several platforms", but fails to specify which ones. If you're looking for a cross-platform approach, you may be better off with something like XPCOM instead.
Technically speaking, COM is just an architecture that can be implemented in any platform. Looking up registered classes in the registry, for example, is something you could implement in an equivalent way on any other platform. The rest of it is about DLLs and MIDL, which you can get working on any platform.
Practically speaking, COM is for Windows (and even that's dying pretty quickly).
The theoretical answer is yes, it's possible to use COM components on other platforms.
Here's an article from way back in 1998 on Building COM Components on UNIX. However, even back in the day this was not a popular (or prudent!) approach.
Somebody know about possibility to establish in different threads of J2ME Midlet 2-3 parallel HTTP connections. I's looks possible but works unstable. Maybe somebody have more information about topic.
It is certainly worth a try and I believe this will work on some good phones but this is typically something that the JSR-118 Test Conformance Kit doesn't test for (as far as I can remember) so it could very possibly fail on some phones too.
Is it possible to write a mobile application with J2ME and whenever we want to implement a functionality not offered by J2ME call native mobile API ? (kind of like what is done with .NET, whenever you need something not provided, you just call the Win32 API from the .NET platform).
While JNI is not officially supported in J2ME, the Symbian implementation of J2ME obviously uses something very similar.
Since most J2ME APIs have a corresponding Symbian OS C++ API, what Symbian did (a lot) is develop adaptation layers between the 2.
Between that and the new modular architecture of the IBM J9 virtual machine (from Series60 3rd edition feature pack 2 onward), it is technically possible to add a new API to the virtual machine without actually needing to recompile most of a handset firmware.
However, third party developers simply are not allowed to do it without a lot of help from the handset manufacturer.
A loopback socket connection is the solution that people have tipically implemented to transfer data accross the language barrier. Large-scale deployment is not the easiest task, though, as you technically need to install 2 applications on the device. Once you understand the threading model of the Symbian J2ME implementation, you also realize how ugly and inefficient a hack it is.
When you reach that kind of issue, it's time to learn Symbian OS C++ and do it right.
No. That's not possible with Java ME.
Only sort of. Actually it is possible but not directly. You can write a native server that listens on a local socket and send requests to it from your Java MIDlet. Someone even released a framework to do this called MIDP-JNI (as opposed to real JNI). Obviously the form of the solution imposes some limitations on what you can do with it but it isn't actually impossible.
Be aware that using this approach can make your application much more complex to debug.
If you are specifically looking out for Nokia/Symbian, then APIBridge http://wiki.forum.nokia.com/index.php/J2ME_API_Bridge_Interface could be a solution. Typically it is the 'official' version of 'native server on local socket' kind of thing. The APIBridge is 'extensible' & you can write your own 'plugins' for your suitable 'low-level' task.