i try create application for Alcatel OT 808. But when I load application with class that implements DiscoveryListener, and then start this application, phone says: Java app stopped.
But in emulator all right.
Thanks for answers!
This model doesn't support bluetooth in user's Java applications. Problem solved by using antoher device.
Hey Hi, DiscoveryListener method does not return or the return is delayed, the system may be blocked. Please read DiscoveryListener API, Also Check Code with Discussion
Related
I am trying to create an App to Stream screen to Chromecast.
I follow the Tutorials and able to create button & connect device.
However, what is next step to cast over ?
Anyone know how using the latest Android Sender 17.1.0 ?
Thanks
You should register your receiver app and a Cast device to test (https://cast.google.com). Anyway, I guess you have your mediaRouteIMenuItem created.
Now you have to use RemoteMediaClient to load some content in your cast device (Video, audio...). What's your problem exactly?
I have an App require to cast the screen (mirror) to the Chromecast or other similar device. I notice in SDK-28 Phone which I use for testing, the Android-OS already has this feature.
Could I could simply invoke(control) this Android feature within my App using API ? I could not find how to do it.
Furthermore reading the material, it indicates if I am using default Cast device protocol, I could just use the "CastMediaControlIntent.DEFAULT_MEDIA_RECEIVER_APPLICATION_ID" = "CC1AD845".
Is this correct ?
I found a project "android_library_screen_mirroring_chromecast-master" in GitHub created 2 years ago to use "CastScreenPresentation" but when I rebuild the project using "com.android.tools.build:gradle:3.5.0" and it would not work.
I've just managed to implement my first daemon using C# and mono (hurrah). It's working all fine except one thing. In windows for a service to log into system's log base, one should use System.Diagnostics.EventLog class. This class comes with a method named WriteEntry to log a string into system logs. The same class exists in mono and compiles just fine but it seems it does nothing. Or perhaps I don't know where to look. Where does the logs generated this way go?
It's not 100% clear from your question - are you expecting the event log code to be working on Linux?
If so, perhaps this answer will help you.
I want to use MemoryMappedFile to communicate between a native app and a .NET app. The problem that I am wondering is How do I tell the .NET app that I am done updated the file? or vice versa.
I believe I could use a windows message to communicate, but I was wondering if there is a better way, any suggested are very appreciated.
Thanks.
Dave McNulty
Native app. - CreateEvent(... name), SetEvent, ResetEvent etc.
Managed app. - EventWaitHandle.OpenExisting(... name)
I have developed a Java ME application for CLDC platform. It works fine when executed in an emulator. But when i deploy it to my N70 phone the application doesn't start at all in the phone. In my application there are some 14 classes and am creating an instance of each and putting them in the vector on application start. The classes just have one variable and 2 methods. Can this creating of lot of instances be the reason for its crashing?
Is there any way I can find out the reason why the application is not able to start in the phone?
Update:
Its running fine on emulator. And one more thing I would like to mention is that- The code stops executing only at the point where am creating those 14 instances and adding them to the vector. Till that point the code executes fine.
It might depend on where in the code you are creating those instances. If you are creating them in your MIDlet constructor or the startApp method try moving the initialization into the run method of your application.
One way of debugging J2ME applications that don't start on the phone is by adding "printf" style debug messages in your code to be written in the record store system and adding another MIDlet to your application to read from RMS and display those messages.
Or you could just comment bits of code and see if it works.
You can debug on device. If the emulator you are using is part of the Nokia SDK then there should be facilities elsewhere to carry out on-device testing and debugging. (I'd post more detail on this but I've only done this with Sony Ericsson phones recently.)
Another option is to use the Nokia tools that allow you to view the standard output and error for your application when it is running on your device (via Bluetooth for example).
The probability that your application is actually crashing the Java Virtual Machine bytecode interpreter thread and terminating the whole native process is very small.
It has happened before but you need to eliminate several other potential issues before being convinced of an actual crash.
It is more likely that either:
Your MIDlet is not created or not started because the MIDP runtime decides it is not correct.
or
Your MIDlet simply throws an exception that you don't catch, which can make it look like it was brutally terminated.
Since the MIDlet installer is supposed to prevent you from installing a bad MIDlet, the uncaught exception issue is more likely.
How to find an uncaught exception:
Start with the simplest HelloWorld MIDlet, using a Form so you can easily insert more StringItems at the top of the screen.
Create and start a new Thread in MIDlet.startApp()
In your override of Thread.run(), add a try{}catch(Throwable){} block.
Inside that block, do whatever your original MIDlet did.
Use the form as your standard output for debugging.
You can use Form logging to make sure you don't enter an infinite loop, to display exception classes and messages, to flag logical milestones, to display variable values...
That's the first step to figuring out what is going on.
I also faced a similar problem and when I recompiled my MIDLET as Midlet 1.0 then it worked fine. It seems like N70 is not able to run the new version of MIDLET. I think you downgrade and re-test your midlet.
Regards
Junaid
I'm trying to develop a portable J2ME appli, but Netbeans do a class preverification of LWUIT library that uses optional APIs that some configurations don't have, so I get this error when I try to compile on a configuration without JSR-184 (M3G Optional API):
Error preverifying class com.sun.lwuit.animations.Transition3D
VERIFIER ERROR com/sun/lwuit/animations/Transition3D.initTransition()V:
Cannot find class javax/microedition/m3g/Node
I don't want to remove the classes from the LWUIT API because that classes works on other configurations compatibles with JSR-184
What I want is that NetBeans do not preverify the library, It is posible?
Here are some code:
//#ifdef JSR184
//# import com.sun.lwuit.animations.Transition3D;
//#else
import com.sun.lwuit.animations.CommonTransitions;
//#endif
Transition out;
//#ifdef JSR184
//# out = Transition3D.createRotation(500, true);
//#else
out = CommonTransitions.createSlide(CommonTransitions.SLIDE_HORIZONTAL, true, 500);
//#endif
setTransitionOutAnimator(out);
Thanks
We had the similar problems, as I remember BlackBerry handsets are problematic (?) for this JSR-184. What I did to solve this problem, I created different configurations for different targets and removed this problematic classes from LWUIT library, rebuild library for that target, and also modified project settings of related configuration accordingly. Hope it helps.
There is a native blackberry port of LWUIT as well as quite a few tutorials and instructions on how to use it. The native port uses native RIM API's which work far better on the blackberry devices than MIDP API's.
LWUIT's use of 184/226 doesn't bother devices that don't support these profiles other than blackberry which has a broken classloader implementation.
It may be possible, though I havent tried it. Netbeans has two xml files, build.xml and build-impl.xml. Look at these files and look for preverify task, then you can do a bit of testing and ensure that it doesnt preverify the library.
Netbeans ant plugin is a pretty simple setup and you can change it which ever way you want to.