I'm trying to make my j2me application to auto-start when the phone is powered on. (The phone is Sonim XP1301.)
I added jad attribute "MIDlet-Launch-Power-On: yes", and now application starts automatically but stays on the background... This is useless for me because the application is UI-based and requires user interaction...
Is there any other jad attribute that would force the application to start in foreground, or some j2me command to bring the application to foreground?
Edit: At Sonim developer site I found this:
"We have our emulator library in which you can check whether the application is in background. Once you get the result you can bring it to foreground
JavaBackgroundMode.isRunningInBackground(Midlet m); is used to check whether the Midlet is in background. If it returns true then it means it is in the background.
JavaBackgroundMode.bringToForeground(this); is used to bring an app to foreground."
..But I have NO IDEA what this actually means... What "emulator library"? Where can I download it and how to use it? If I try just to add this line to my code:
JavaBackgroundMode.bringToForeground(this);
..NetBeans gives me error "Cannot find sybmol: Variable JavaBackgroundMode".
Any ideas?
Edit2: Tested "push registry", does not work. JAD file looks like this:
MIDlet-1: Contactless,,example.contactless.ContactlessDemo
MIDlet-Description: This is basic JSR257 Contactless Communication API demo.
MIDlet-Jar-Size: 7738
MIDlet-Jar-URL: Contactless.jar
MIDlet-Name: Contactless
MIDlet-Permissions: javax.microedition.io.Connector.file.read, javax.microedition.io.Connector.file.write, javax.microedition.io.Connector.http, javax.microedition.io.PushRegistry
MIDlet-Push-1: autostart://:, Contactless, *
MIDlet-Vendor: Oracle
MIDlet-Version: 1.0
Manifest-Version: 1.0
MicroEdition-Configuration: CLDC-1.1
MicroEdition-Profile: MIDP-2.0
I never heard of MIDlet-Launch-Power-On before. Had to Google for it to learn that it is a Sprint specific JAD attribute.
Try using the standard way of auto-starting a MIDlet: Using PushRegistry.
Add these two lines in your JAD file instead, and remove the MIDlet-Launch-Power-On attribute.
MIDlet-Permissions: javax.microedition.io.PushRegistry
MIDlet-Push-1: autostart://:,NameOfMIDlet,*
See if that makes a difference.
Oracle-MIDlet-Autostart: 1
Oracle-MIDlet-Restart: false
Oracle-MIDlet-Restart-Count: 10
Just an additional answer to this question:
Every MIDlet that is started automatically needs to be configured via its jad file and the following properties:
Oracle-MIDlet-Autostart: [0-5], autostart order. 0 means no autostart. For MIDlets with
the same level the order is not defined.
Oracle-MIDlet-Restart: [true|false], if true the MIDlet is automatically restarted if it terminates non gracefully, e.g. by an uncaught exception.
Oracle-MIDlet-Restart-Count: [number], number of allowed MIDlets restarts before the
whole module is rebooted
Related
My Qt 5.9 program (on X11 Linux) launches other applications, using QProcess.
I would like to have control over windows these applications spawn, so I obtain their winId value and use QWindow::fromWinId to get a QWindow instance.
The problem is these instances are invalid and do not represent the window they are supposed to.
If I check the winId values using xwininfo, the correct information is returned, so I know they are good.
What am I doing wrong?
Edit: An example won't help much, but here goes:
QProcess *process=new QProcess(this);
...
process.open()
... // wait until window appears
WId winId=PidToWid(process->processId()); // this function returns the Window ID in decimal format. I test this with xwininfo, it's always correct
...
QWindow *appWindow=QWindow::fromWinId(winId);
... And that's basically it. appWindow is a valid QWindow instance, but it does not relate to the actual window in any way. For example, if I close() it, it returns true but the window does not close.
Even if I provide a wrong WId on purpose, the end result is the same.
This is not proper solution with explanation why it should work, however it may be helpful for somebody...
I had the same issue with my application when I switched from Qt4 QX11EmebeddedContainer to Qt5 implementation using QWindow. What I did to resolve / fix this issue was following:
Client application:
widget->show(); //Widget had to be shown
widget->createWinId();
sendWinId(widget->winId()); //Post window handle to master app where is constructed container
Master application:
QWindow* window = QWindow::fromWinId(clientWinId);
window->show(); //This show/hide toggle did trick in combination with show in client app
window->hide();
QWidget* container = QWidget::createWindowContainer(window, parentWindowWidget);
After this I was able to control window properly through QWidget container.
All JS I register with an id such as ++theme++mythemename/js/myscript.js gives me the following error on portal_javascripts: (resource not found or not accessible)
I know the id is correct because I can access localhost/mysite/++theme++mythemename/js/myscript.js (even if Diazo is disabled).
If development mode is on the resource gets delivered on the final HTML. However on production mode cooking process fails silently. Or almost. Besides getting a different cachekey than the one showed on portal_javascripts/manage_jsComposition, I see the following error message by accessing the cooked file:
/* XXX ERROR -- access to '++theme++mythemename/js/myscript.js' not authorized */
Any hints on how to deal with those? Or will I really need to leave them uncooked?
Have you tried a browser:resourceDirectory instead of a plone:static ?
<browser:resourceDirectory
name="yourJsFolder"
directory="yourJsFolder"
layer=".interfaces.IThemeSpecific"
/>
and calling your js with :
++resource++yourJsFolder/yourJsFile.js
i added your observatorio.tema package to an existing plone 4.1 buildout and added a random js file to the js registry (positioned after collapsibleformfields.js so it gets properly cooked)
GS export looks like:
<javascript authenticated="False" cacheable="True" compression="safe"
conditionalcomment="" cookable="True" enabled="True" expression=""
id="++theme++observatorio/js/ui.js" inline="False" insert-after="collapsibleformfields.js"/>
no error in portal_jacascripts and the javascript file is included in /jquery-cachekey-e7bee35d43da7a91eb29c6586dcbd396.js
did you add cacheable="False" and cookable="False" for testing purposes?
https://github.com/observatoriogenero/observatorio.tema/blob/master/src/observatorio/tema/profiles/default/jsregistry.xml#L373
since plone:static internally is a resourceDirectory both should and do work with resourceregistries.
maybe there is some other code in your buildout that re-registers another (empty) directory for the same name (observatorio)?
This is in response to dan's (dan^spotify on IRC) offer to take a look at my testcase, but I post it here in case anyone has encountered similar issues.
I'm experiencing a problem with libspotify where the application crashes (memory access violation) in both of these two scenarios:
the first sp_session_process_events (triggered by notify main thread callback) that's called after the sp_session_logout() function is called crashes the application
skipping logout and calling sp_session_release() crashes the application
I've applied sufficient synchronization from the session callbacks, and I'm otherwise operating on a single thread.
I've made a small testcase that does the following:
Creates session
Logs in
Waits 10 seconds
Attempts to logout, upon which it crashes (when calling sp_session_process_events())
If it were successful in logging out (which it isn't), would call sp_session_release()
I made a Gist for the testcase. It can be found here: https://gist.github.com/4496396
The test case is made using Qt (which is what I'm using for my project), so you'd need Qt 5 to compile it. I've also only written it with Windows and Linux in mind (don't have Mac). Assuming you have Qt 5 and Qt Creator installed, the instructions are as follows:
Download the gist
Copy the libspotify folder into the same folder as the .pro file
Copy your appkey.c file into the same folder
Edit main.cpp to login with your username and password
Edit line 38-39 in sessiontest.cpp and set the cache and settings path to your liking
Open up the .pro file and run from Qt Creator
I'd be very grateful if someone could tell me what I'm doing wrong, as I've spent so many hours trying anything I could think of or just staring at it, and I fear I've gone blind to my own mistakes by now.
I've tested it on both Windows 7 and Linux Ubuntu 12.10, and I've found some difference in behavior:
On Windows, the testcase crashes invariably regardless of settings and cache paths.
On Linux, if setting settings and cache to "" (empty string), logging out and releasing the session works fine.
On Linux, if paths are anything else, the first run (when folder does not already exist) logs out and releases session as it should, but on the next run (when folder already exists), it crashes in the exact same way as it does on Windows.
Also, I can report that sp_session_flush_caches() does not cause a crash.
EDIT: Also, hugo___ on IRC was kind enough to test it on OSX for me. He reported no crashes despite running the application several times in a row.
While you very well may be looking at a bug in libspotify, I'd like to point out a possibly redundant call to sp_session_process_events(), from what I gathered from looking at your code.
void SessionTest::processSpotifyEvents()
{
if (m_session == 0)
{
qDebug() << "Process: No session.";
return;
}
int interval = 0;
sp_session_process_events(m_session, &interval);
qDebug() << interval;
m_timerId = startTimer(interval);
}
It seems this code will pickup the interval value and start a timer on that to trigger a subsequent call to event(). However, this code will also call startTimer when interval is 0, which is strictly not necessary, or rather means that the app can go about doing other stuff until it gets a notify_main_thread callback. The docs on startTimer says "If interval is 0, then the timer event occurs once every time there are no more window system events to process.". I'm not sure what that means exactly but it seems like it can produce at least one redundant call to sp_session_process_events().
http://qt-project.org/doc/qt-4.8/qobject.html#startTimer
I notice that you will get a crash on sp_session_release if you have a track playing when you call it.
I have been chasing this issue today. Login/logout works just fine on Mac, but the issue was 100% repeatable as you described on Windows.
By registering empty callbacks for offline_status_updated and credentials_blob_updated, the crash went away. That was a pretty unsatisfying fix, and I wonder if any libspotify developers want to comment on it.
Callbacks registered in my app are:
logged_in
logged_out
notify_main_thread
log_message
offline_status_updated
credentials_blob_updated
I should explicitly point out that I did not try this on the code you supplied. It would be interesting to know if adding those two extra callbacks works for you. Note that the functions I supply do absolutely nothing. They just have to be there and be registered when you create the session.
Adding the following call in your "logged in" libspotify callback seems to fix this crash as detailed in this SO post:
sp_session_playlistcontainer(session);
I made a streaming music player and it works fine in the foreground.
But in the background iOS4, it doesn't play the next song automatically. ( remote control works )
The reason is AudioQueueStart return -12985.
I already check the audio session. it just fine. I use AudioQueueStart when it start to play the music.
How can you remove AudioQueueStart?
- (void)play
{
[self setupAudioQueueBuffers]; // calcluate the size to use for each audio queue buffer, and calculate the // number of packets to read into each buffer
OSStatus status = AudioQueueStart(self.queueObject, NULL);
}
I read the answer in the web about the AudioQueueStart fail subject.
One thing to check is that the AudioSession is active first.
In my case, I had previously set the session to inactive between song changes before starting a new song:AudioSessionSetActive(false);
Once I removed this AudioQueueStart works just fine from the background.
In my experience, the -12985 message occurs because another app already has an audio session active when you try to start playback in your app. Options are to 1) instruct the user to close the other app, or 2) set mix mode (see kAudioSessionProperty_OverrideCategoryMixWithOthers).
The disadvantage of mix mode is if you depend on lock screen art or remote controls, they won't work with mix mode set.
I also faced with such problem week ago. I've spent two days to find solution and I found it. May be this link will help (it is official answer): http://developer.apple.com/library/ios/#qa/qa1668/_index.html
Make sure that you activate session from applicationDidEnterBackground task handler. Now my application can play sound in background.
See this.
You probably need to include the following:
[[UIApplication sharedApplication] beginReceivingRemoteControlEvents];
Towards the bottom there is a reiteration of the how important that line is. As it is not mentioned in any of the three main audio audio guides (AVFoundation, AudioSession, or AudioQueue) it can easily be missed.
I have the same problem.
I registry the AudioSessionInterruptionListener, pause the audio when phone call, resume it after the call end. but get -12985 error code when call AudioQueueStart to resume.
My solution is that I try to call AudioQueueStart after 0.02s.
I don't know the reason.
On iOS7, AudioQueueStart was returning '!int' ('tni!'), though i'm sure no one would be surprised to find that it's not documented in the docs or headers. It was the same issue, though, and the same fix (setting the audio session to active in the background task handler) worked for me.
I'm working on a online quiz client where we use a dedicated custom-made linux distro which contains only the quiz client software along with text editors and other utility software. When the user has started the quiz, I want to prevent him/her from minimizing the window/closing it/switching to the desktop or other windows. The quizzes can be attempted using only the mouse, so I need the keyboard to be completed disabled for the period of the quiz. How could I do this, using Qt or Mono? I'm ready to use any low-level libraries/drivers, if required.
You may use QWidget::grabKeyboard and QWidget::grabMouse, and please note the warning in comments:
Warning: Bugs in mouse-grabbing
applications very often lock the
terminal. Use this function with
extreme caution, and consider using
the -nograb command line option while
debugging.
Have you looked at XGrabKeyboard? That should do a global grab of the keyboard.
Did you try to use EventFilter ? You have the opportunity to block all the events related to, as instance, keypress...
More information here : http://qt.nokia.com/doc/4.6/eventsandfilters.html
Hope it helps !
Something like :
bool MyWidget::event(QEvent *event)
{
if (event->type() == QEvent::KeyPress)
{
return true;
}
return QWidget::event(event);
}