Fought a lot with making QtQuick work everywhere today.
I am too tired to explain, so I'm just going to post links and hope it makes sense.
Thread that has the announcement for the port of QtMobility 1.1 to n900.
This link explain in greater detail how to install to your development systems.
Thursday, March 31, 2011
Wednesday, March 16, 2011
Symbian s^3 and Qt rock
I've finally got qgvdial working on Symbian to the point where it might actually be a candidate to send out on to Ovi.
I've tested qgvdial only on the Nokia C7, but from what I understand, that should mean that it works on all Symbian s^3 phones.
If you're the sort who likes to live on the bleeding edge, then head on over to the downloads list and look for the one that says "Symbian s^3. Testing only".
This sis file may not last out there for as long as you'd hope. I keep updating it as I add bug fixes. It comes and goes as I do this. It will break stuff.
You have been warned.
I've tested qgvdial only on the Nokia C7, but from what I understand, that should mean that it works on all Symbian s^3 phones.
If you're the sort who likes to live on the bleeding edge, then head on over to the downloads list and look for the one that says "Symbian s^3. Testing only".
This sis file may not last out there for as long as you'd hope. I keep updating it as I add bug fixes. It comes and goes as I do this. It will break stuff.
You have been warned.
Thursday, March 10, 2011
Symbian^3 and the Ovi store.
I've fought long and hard at figuring out how to make my app work on Symbian. Any Symbian.
It was just recently that I found out about the entire signing side of creating Symbian apps - thanks in part to the new Nokia SDK that has inbuilt Symbian build, sign, deploy and debug.
As I started reading more and more of this entire process, I got to learn about Symbian "target capabilities". These keys influence what your Symbian app can or cannot do.
For example, NetworkServices is necessary to be able to do *any* network communication - either you doing sockets or QtWebkit doing any sockets.
But that's not all. What the documentation does not state and what I found out after loooooong long hours of wasting my time searching Google, was that the following combination "Self sign + capability=NetworkServices + QtWebkit classes" can provide me with only http browsing.
If I want to do *any* https / secure sockets / ssl communication, then the sis file MUST have a valid signature. It cannot be self-signed.
So now what? How do I go about getting it signed?
The price for a signing certificate is about $250 / year. That may be affordable, however, Verisign (or any other trusted authority) will not provide a certificate unless they are able to validate the existence and the legitimacy of *your company*.
Which mean I need to have a company (?!?) Yikes.
..... or I can go the easy route and sign up with the Ovi store, which signs sis files that are published to the Ovi store for free.
Guess how I'll be signing qgvdial and where they will be? :D
It was just recently that I found out about the entire signing side of creating Symbian apps - thanks in part to the new Nokia SDK that has inbuilt Symbian build, sign, deploy and debug.
As I started reading more and more of this entire process, I got to learn about Symbian "target capabilities". These keys influence what your Symbian app can or cannot do.
For example, NetworkServices is necessary to be able to do *any* network communication - either you doing sockets or QtWebkit doing any sockets.
But that's not all. What the documentation does not state and what I found out after loooooong long hours of wasting my time searching Google, was that the following combination "Self sign + capability=NetworkServices + QtWebkit classes" can provide me with only http browsing.
If I want to do *any* https / secure sockets / ssl communication, then the sis file MUST have a valid signature. It cannot be self-signed.
So now what? How do I go about getting it signed?
The price for a signing certificate is about $250 / year. That may be affordable, however, Verisign (or any other trusted authority) will not provide a certificate unless they are able to validate the existence and the legitimacy of *your company*.
Which mean I need to have a company (?!?) Yikes.
..... or I can go the easy route and sign up with the Ovi store, which signs sis files that are published to the Ovi store for free.
Guess how I'll be signing qgvdial and where they will be? :D
Friday, March 4, 2011
C Linking is so much simpler
To make mosquitto support work in Windows, I rebuilt the mosquitto source to get mosquittopp.dll
All fine thus far, but then actually using it became a massive pain. The name mangling just didn't match up even though I was using the same compiler.
I gave up and started using the base C api and created my cpp wrapper around it based on the mosquittopp source.
Now it works for Linux, Windows, Maemo.
Time to start hacking at it on Symbian.
All fine thus far, but then actually using it became a massive pain. The name mangling just didn't match up even though I was using the same compiler.
I gave up and started using the base C api and created my cpp wrapper around it based on the mosquittopp source.
Now it works for Linux, Windows, Maemo.
Time to start hacking at it on Symbian.
Thursday, March 3, 2011
Mosquitto-es!
qgvdial does it's best to not update anything unless the user explicitly asks.
But then there is the issue of timely updates about new messages and calls - missed, received or otherwise. Google doesn't have a push api for this.
Why don't I just poll for it? Because polling means waking up every few seconds, opening a socket, sending a request, getting the data, parsing it, and then more times than not, figuring out that there is nothing new. This absolutely kills the battery life on the phone.
What I needed was a robust push mechanism.
This is where a qgvdial user - xur17 - suggested Mosquitto - a publish/subscribe message broker.
I've ported Mosquitto to Maemo and Diablo and added functionality to qgvdial to subscribe to a mosquitto topic to get inbox and contacts updates.
So now, qgvdial gets updates by just waiting (select) on a socket. No polling involved on the qgvdial side. All the heavy lifting and polling done on the publisher side, which resides in a place where there isn't any constraint on battery life or CPU consumption.
The publisher is a bunch of python scripts that continuously poll for changes in the GV inbox. On any changes, it publishes the change to the mosquitto server on the predefined topic.
This publisher can run on anything that has python. So any regular desktop OS would do. But I had another constraint: I wanted to energy footprint of the device to be as low as possible. What low power device do I have that I can afford to run continuously? I have 2: My DD-WRT router and the n810.
Right now, I've only run the scripts on the n810 and it turns out that this works pretty well to give me all the updates I wanted.
Pretty soon I'll attempt to make it all run even on the router so that I can really truly have only one device that is "always on", doesn't burn a lot of energy and still is a powerful enough machine to do everything I want.
But then there is the issue of timely updates about new messages and calls - missed, received or otherwise. Google doesn't have a push api for this.
Why don't I just poll for it? Because polling means waking up every few seconds, opening a socket, sending a request, getting the data, parsing it, and then more times than not, figuring out that there is nothing new. This absolutely kills the battery life on the phone.
What I needed was a robust push mechanism.
This is where a qgvdial user - xur17 - suggested Mosquitto - a publish/subscribe message broker.
I've ported Mosquitto to Maemo and Diablo and added functionality to qgvdial to subscribe to a mosquitto topic to get inbox and contacts updates.
So now, qgvdial gets updates by just waiting (select) on a socket. No polling involved on the qgvdial side. All the heavy lifting and polling done on the publisher side, which resides in a place where there isn't any constraint on battery life or CPU consumption.
The publisher is a bunch of python scripts that continuously poll for changes in the GV inbox. On any changes, it publishes the change to the mosquitto server on the predefined topic.
This publisher can run on anything that has python. So any regular desktop OS would do. But I had another constraint: I wanted to energy footprint of the device to be as low as possible. What low power device do I have that I can afford to run continuously? I have 2: My DD-WRT router and the n810.
Right now, I've only run the scripts on the n810 and it turns out that this works pretty well to give me all the updates I wanted.
Pretty soon I'll attempt to make it all run even on the router so that I can really truly have only one device that is "always on", doesn't burn a lot of energy and still is a powerful enough machine to do everything I want.
Subscribe to:
Posts (Atom)