[Qt-interest] How can I write Qt apps for my everyday cell phone?

[Atlant Schmidt]

K Frank:

  (I'm not "Android intimate"; I knew more about
  Nokia's Symbian/S60 so I'll answer the questions
  that have more-generic answers or answer based on
  Symbian.)


> Are most / all android phones arm based?

  As far as I know, *ALL* mainstream phones are based
  on one generation or another of the ARM processor
  whether it's implemented as a discretechip (usually
  within a pre-packaged assembly that includes the
  ARM chip, RAM chip(s), and Flash ROM chip(s)) or
  as "IP" within a larger gate-array.

  The capabilities of the ARM in your particular phone
  may vary, of course.


> Is the development cycle basically: build on host, deploy to target,
> run on target, observe bugs on target, fix bugs on host, rebuild,
> re-deploy, etc.?

  Yes, basically that's it. It may be complicated by you not
  having (easy access to) a console that can catch printf()
  output.


> Or is there some way to run / debug on the host? Paul mentioned
> "USB debugging."  What is that?

  I can't speak for Android, but in Symbian Nokia definitely
  offered this under the names "Application TRK" and "System
  TRK". That connected a full-fledged debugger running on
  your PC through the USB to your application running on
  your phone. We rarely used it, though. Nokia also provided
  (and so does Apple) a very-capable emulation environment
  that ran purely on your PC (albeit somewhat slowly); that
  contains the usual debugging environment(s) (the Eclipse
  debugger; I think you could also run with gdb).


> On modern pc's you have to try pretty hard to write a user
> app that screws up the system (to be contrasted, for example,
> with programming in the old dos days).  Is programming for
> an android as safe as programming for a modern pc?  Or is
> it more like programming for an old dos pc?

  All modern phone OSs are fully-preemptive, memory-protected
  multi-tasking environments. (Even iOS; don't believe any FUD
  about it not being multi-tasking; Apple is just "picky" about
  which apps they will allow to fully "background".) The tricky
  part is you can still lose control of your phone if your app
  is burning lots and lots of CPU and net, but unless you've
  also rigged your app to auto-start, then powering your phone
  off and on should regain control.

  At Nokia, though, we often did full Flash reloads of everything
  on the Symbian C: drive (using the JTAG flasher) rather than
  just replacing the app-under-test; Nokia's software isn't
  well-partitioned so we were often depending upon fixes in
  other parts of the software (other apps, the UI layer, or
  even, occasionally, base Symbian) to (help) resolve bugs in
  the app that we were developing.


> Last question:  I realize that a well-designed cell-phone Qt app
> will look rather different than a desktop app.  But, for simple
> apps, can I run the same app on both platforms, or are they
> inherently different? ...

  Graphical "Hello, world!" is still graphical "Hello, world!"
  and should be runnable pretty much anywhere. The key differences
  that I can think of are:

    o Mouse versus touchscreen

    o Radically different screen size even if the pixel
      area isn't that much different

    o Usually, far fewer (sensible) font choices

    o The need to look like the rest of the phone apps

    o The need to integrate with any "chrome" that the
      phone usually wants to keep present (network
      name, signal bars, battery level, etc.)

    o The need to design cleverly for the processing
      constraints of the mobile world (CPU, RAM, battery,
      "disk", etc.)

    o The fact that your running app can often be "ejected"
      if the phone decides you're not important right now

    o Highly-variable network connectivity

    o Additional "mobility" APIs


  I'm sure others will have other comments.

                                          Atlant


-----Original Message-----
From: qt-interest-bounces+aschmidt=dekaresearch.com at qt.nokia.com [mailto:qt-interest-bounces+aschmidt=dekaresearch.com at qt.nokia.com] On Behalf Of K. Frank
Sent: Wednesday, August 24, 2011 17:33
To: Qt-interest
Subject: Re: [Qt-interest] How can I write Qt apps for my everyday cell phone?

Hello All!

Thanks to all who replied.

On Tue, Aug 23, 2011 at 2:15 PM, Paul Miller <paul at fxtech.com> wrote:
> On 8/23/2011 11:51 AM, Yuvraaj Kelkar wrote:
>> Assuming you get an Android phone and root it:
> ...

Some follow-up questions, if I may.

It sound like android is the (semi-) consensus.  So my first step would
be to buy a Verizon (CDMA) compatible android phone.  Any particular
recommendation?  I would want 1) a good-quality "conventional" smart
phone, and 2) the ability to build / deploy my own Qt apps to it.

Asked another way, are there any android phones that might look good
but that I should stay away from?

Are most / all android phones arm based?

So if "platform" means os + processor, then I would be targeting the
android / arm platform.  True?  So my second step would be to
download the version of the necessitas sdk that is hosted on windows
and targets android / arm.

I've been poking around the necessitas wiki, but there are still some
things I'm a little vague on.  How would I deploy an app to an android
phone?  On a pc I can simply copy an executable (or an executable
plus some libraries) to the target machine and then run it.  I may
also have to add something to my path.  Can I simply copy an
executable to an android over a usb cable?  Do I have to build some
kind of official android "deployment package?"

Is the development cycle basically: build on host, deploy to target,
run on target, observe bugs on target, fix bugs on host, rebuild,
re-deploy, etc.?  Or is there some way to run / debug on the host?
Paul mentioned "USB debugging."  What is that?  It sounds like I
could run the debugger on the host, run (a debug version of) the app
on the target, and that the debugger hooks into the running app over
a usb cable.  That would be cool.  Is that what "USB debugging" means?

Atlant mentioned some ways an app can misbehave, mainly by using
too much of some resource.  That I understand, and am not really worried
about it.  I can  always just exit / kill off the misbehaving app.  (I
can, can't
I?)  I'm more worried about the possibility of a rogue app  messing up
the phone in a way that persists after the app is shut down so that I
would have to reboot the phone, or worse, re-load the phone's os.
How much of a worry is that?  On modern pc's you have to try pretty
hard to write a user app that screws up the system (to be contrasted,
for example, with programming in the old dos days).  Is programming
for an android as safe as programming for a modern pc?  Or is it more
like programming for an old dos pc?

Last question:  I realize that a well-designed cell-phone Qt app will look
rather different than a desktop app.  But, for simple apps, can I run the
same app on both platforms, or are they inherently different?  Let's say
I write a simple "hello world" app -- maybe it has a couple of buttons or
other widgets that do something simple -- and I get it working on the
desktop.  Can I simply rebuild it for the cell phone and have it run
correctly (even if it's design is not really appropriate for a cell phone)?

Any other things I should know?

As you can see, I'm trying to get an overview of what writing Qt apps
for a cell phone would actually entail before I decide to jump into it.

Since it seems like the way to go is to get an android and use necessitas
to build Qt apps for it, I would especially like to hear from folks who have
built Qt apps for android and run them, presumably using necessitas.
Is this something that works "in principle," or have people actually done
this and found it to be satisfactory?

Thanks again for all of your advice.


K. Frank
_______________________________________________
Qt-interest mailing list
Qt-interest at qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-interest

This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.