QPython built-in Libraries¶
QPython is using the Python 2.7.2 and it support most Python stardard libraries. And you could see their documentation through Python documentation.
QPython dynload libraries¶
Just like Python, QPython contains python built-in .so libraries.
Usually, you don’t need to import them manually, they were used in stardard libraries, and could be imported automatically.
- _codecs_cn.so
- _codecs_hk.so
- _codecs_iso2022.so
- _codecs_jp.so
- _codecs_kr.so
- _codecs_tw.so
- _csv.so
- _ctypes.so
- _ctypes_test.so
- _hashlib.so
- _heapq.so
- _hotshot.so
- _io.so
- _json.so
- _lsprof.so
- _multibytecodec.so
- _sqlite3.so
- _ssl.so
- _testcapi.so
- audioop.so
- future_builtins.so
- grp.so
- mmap.so
- resource.so
- syslog.so
- termios.so
- unicodedata.so
QPython stardard libraries¶
The following libraries are the stardard QPython libraries which are the same as Python:
- BaseHTTPServer.py
- binhex.py
- fnmatch.py
- mhlib.py
- quopri.py
- sysconfig.py
- Bastion.py
- bisect.py
- formatter.py
- mimetools.py
- random.py
- tabnanny.py
- CGIHTTPServer.py
- bsddb
- fpformat.py
- mimetypes.py
- re.py
- tarfile.py
- ConfigParser.py
- cProfile.py
- fractions.py
- mimify.py
- repr.py
- telnetlib.py
- Cookie.py
- calendar.py
- ftplib.py
- modulefinder.py
- rexec.py
- tempfile.py
- DocXMLRPCServer.py
- cgi.py
- functools.py
- multifile.py
- rfc822.py
- textwrap.py
- HTMLParser.py
- cgitb.py
- genericpath.py
- mutex.py
- rlcompleter.py
- this.py
- chunk.py
- getopt.py
- netrc.py
- robotparser.py
- threading.py
- MimeWriter.py
- cmd.py
- getpass.py
- new.py
- runpy.py
- timeit.py
- Queue.py
- code.py
- gettext.py
- nntplib.py
- sched.py
- toaiff.py
- SimpleHTTPServer.py
- codecs.py
- glob.py
- ntpath.py
- sets.py
- token.py
- SimpleXMLRPCServer.py
- codeop.py
- gzip.py
- nturl2path.py
- sgmllib.py
- tokenize.py
- SocketServer.py
- collections.py
- hashlib.py
- numbers.py
- sha.py
- trace.py
- StringIO.py
- colorsys.py
- heapq.py
- opcode.py
- shelve.py
- traceback.py
- UserDict.py
- commands.py
- hmac.py
- optparse.py
- shlex.py
- tty.py
- UserList.py
- compileall.py
- hotshot
- os.py
- shutil.py
- types.py
- UserString.py
- compiler
- htmlentitydefs.py
- os2emxpath.py
- site.py
- unittest
- _LWPCookieJar.py
- config
- htmllib.py
- smtpd.py
- urllib.py
- _MozillaCookieJar.py
- contextlib.py
- httplib.py
- pdb.py
- smtplib.py
- urllib2.py
- __future__.py
- cookielib.py
- ihooks.py
- pickle.py
- sndhdr.py
- urlparse.py
- __phello__.foo.py
- copy.py
- imaplib.py
- pickletools.py
- socket.py
- user.py
- _abcoll.py
- copy_reg.py
- imghdr.py
- pipes.py
- sqlite3
- uu.py
- _pyio.py
- csv.py
- importlib
- pkgutil.py
- sre.py
- uuid.py
- _strptime.py
- ctypes
- imputil.py
- plat-linux4
- sre_compile.py
- warnings.py
- _threading_local.py
- dbhash.py
- inspect.py
- platform.py
- sre_constants.py
- wave.py
- _weakrefset.py
- decimal.py
- io.py
- plistlib.py
- sre_parse.py
- weakref.py
- abc.py
- difflib.py
- json
- popen2.py
- ssl.py
- webbrowser.py
- aifc.py
- dircache.py
- keyword.py
- poplib.py
- stat.py
- whichdb.py
- antigravity.py
- dis.py
- lib-tk
- posixfile.py
- statvfs.py
- wsgiref
- anydbm.py
- distutils
- linecache.py
- posixpath.py
- string.py
- argparse.py
- doctest.py
- locale.py
- pprint.py
- stringold.py
- xdrlib.py
- ast.py
- dumbdbm.py
- logging
- profile.py
- stringprep.py
- xml
- asynchat.py
- dummy_thread.py
- macpath.py
- pstats.py
- struct.py
- xmllib.py
- asyncore.py
- dummy_threading.py
- macurl2path.py
- pty.py
- subprocess.py
- xmlrpclib.py
- atexit.py
- mailbox.py
- py_compile.py
- sunau.py
- zipfile.py
- audiodev.py
- encodings
- mailcap.py
- pyclbr.py
- sunaudio.py
- base64.py
- filecmp.py
- markupbase.py
- pydoc.py
- symbol.py
- bdb.py
- fileinput.py
- md5.py
- pydoc_data
- symtable.py
Python 3rd Libraries¶
- BeautifulSoup.py(3)
- pkg_resources.py
- androidhelper
- plyer
- bottle.py
- qpy.py
- qpythoninit.py
- setuptools
- pip
Androidhelper APIs¶
To simplify QPython SL4A development in IDEs with a “hepler” class derived from the default Android class containing SL4A facade functions & API documentation
Источник
Создание и управление интерфейсом на Android с помощью Python
Программирование для смартфонов
Добрый день.
Хотел бы предоставить на ваш суд свою первую статью о программировании на Python под Android. Сразу оговорюсь, что я не специалист в этой области, учусь вместе с вами. Как и многие из нас, начинал писать приложения на старой доброй OS Symbian. Однако прогресс не стоит на месте, и на смену старому всегда приходит новое. Вот с этим новым мне и пришлось столкнуться, когда я приобрел HTC Wildfire на платформе Android.
Разобравшись с новым устройством, я решил, что, наконец, пришло время установить полюбившийся многим интерпретатор языка программирования Python .
В Интернете наткнулся на SL4A (Scripting Layer For Android) — оболочку, которая, позволяет создавать и запускать скрипы,
написанные на различных языках
сценариев (Python, Perl, Ruby, Lua, BeanShell, javascript и Tcl) прямо на Android — устройствах. Описывать работу с этой оболочкой я не буду, поскольку ниже есть ссылка на соответствующую статью от «Питон на Android. Начало».
Наверное, ни для кого не секрет, что «родные» приложения для Android пишутся на Java (не путайте с платформой Java2ME). Так вот, сценарии, написанные с помощью SL4A, имеют доступ ко многим API, доступным для нормального Java приложения, но с упрощенным интерфейсом.
Установил, проверил, стало грустно. Потому что, если на Symbian Python был чуть ли не всемогущ, и зачастую приложение, написанное на нем, не уступало аналогам на Си, то на Android, сделать что-то большее, чем общение с пользователем посредством диалоговых окон или запуск скрипра в фоновом режиме, увы, не удастся. С другой стороны мы имеем модуль android, который позволяет программисту создавать все те же диалоговые окна, selection list, вызывать прогресс бар, отправлять/читать сообщения и многое другое. То есть с его помощью мы имеем доступ практически ко всем необходимым для разработки приложения функциям смартфона. Но! Мы не имеем возможности создать более менее приличный интерфейс к нашим приложениям. К счастью, все это заблуждение!
На платформе Android Python-программист имеет возможность создавать интерфейс пользователя двумя способами. Первый — с помощью функции из модуля android webViewShow, которой в качестве аргумента передается строка, путь к html-документу, который и будет интерфейсом приложения. Все события такого приложения будут передоваться в Python-сценарий с помощью кода на Java-script в html-странице интерфейса приложения. Подробнее о webViewShow можно прочитать в статье от пользователя Zaterehniy Питон на Android. Начало . Однако должен сказать, что у этого способа создания интерфейса есть огромный минус — html перестает отвечать на действия пользователя буквально после нескольких обработанных событий. Увы, но это так. К счастью у нас есть второй, на 100% действенный, способ
создания пользовательского
интерфейса — fullScreenUI.
Начиная с версии SL4A_r5, появился новый, как заявили разработчики, пока что
экспериментальный, способ создания пользовательского интерфейса — fullScreenUI. FullScreenUI позволяет создавать интерфейс, используя стандартные виджеты Android (кнопки,
текстовые поля, радиокнопки, и
проч.), а также обрабатывать события от них.
Весь интерфейс нашего приложения, как и в «родной» программе на Java, будет описан в xml-макете, код же самого сценария будет записан в отдельном файле. Android-разработчики используют два определения термина «макет». Первое — тип ресурса, определяющий то, что будет на экране. Макеты хранятся в виде xml-файлов в /res/layout директории приложения. Второе определение: макет — это просто шаблон для экрана пользовательского интерфейса, компановка тех или иных элементов, которые будет видеть пользователь.
В xml-контейнере мы лепим визуальную часть приложения: здесь будет текстовое поле, оно будет черного цвета, внизу будет кнопка с надписью «Сохранить», она будет зеленого цвета и так далее. На самом деле это очень удобно, поскольку мы отделяем интерфейс от кода нашей программы. В этой статье я не буду вдаваться в подробности xml разметки на Android, а всего лишь покажу как управлять этими елементами из сценария на языке Python.
Более подробно об xml разметке на Android вы можете прочитать здесь .
Все примеры, которые я приведу в этой статье, используют droidInterface.py — оболочку для работы с модулем android. Оболочку я пишу для себя, потому что мне так проще, это не конечный результат, и если вы не испытываете затруднений с использованием модуля android, она вам не нужна, перепишите примеры под оригинальный API.
Итак, начнем. Все сценарии у меня лежат в . У вас они могут находится где угодно. Создадим папку нашего первого примера. Назовем ее Example. В этой папке создайте папку ресурсов res, в которой будет подпапка layout. Я всегда придерживаюсь данной структуры приложения, чего и вам советую. В итоге у вас должна получится директория . В корне проекта будет находится наш Python-сценарий, demo.py, а в папке layout файл макета интерфейса main.xml с нижеследующим содержанием:
А вот сам Python сценарий:
Вот, что у нас получилось:
Теперь немного о самом коде.
— оболочка для работы с модулем android.
— переменной droid присваиваем экземпляр класса Android, который определен в модуле droidInterface; через droid мы будем работать со стандартным API.
— получаем полный путь к папке с нашим сценарием.
— вешаем на кнопку «menu» наше меню ;первый аргумент — название пункта, второй — имя используемой иконки; если мы хотим меню из нескольких пунктов, тогда нам нужно передать в функцию set_menu список кортежей:
— думаю здесь понятно, метод fullShow принимает строку с нашим макетом интерфейса;
— функция droid.eventWait останавливает сценарий и ждет действий от со стороны пользователя; результатом выполнения (переменная event) будет ассоциативный массив с именем события и информацией о нем;
— для начала проверяем значение event[«name»], если оно равно «key», то была нажата кнопка, код
которой можно узнать из event [«data»][«key»] ; если же оно равно
«click», то было нажатия на один из виджетов, id которого можно узнать из event[«data»][«id»] ; посмотрите содержимое появляющегося окошка, проанализируйте.
Теперь давайте попробуем динамически изменить наш интерфейс.
Вот, что у нас получилось:
Теперь если мы нажмем на кнопку «Ok», наш интерфейс динамически поменяет свой облик:
Динамически изменять элементы графического интерфейса и содержание форм мы можем с помощью метода droid.fullSetProperty, который принимает три параметра: id виджета, название свойства, присваиваемое значение.
id виджета. Находится в файле main.xml и задается программистом. Например форме для ввода текста мы присвоили id — «».
Название свойства. Это может быть, например, текст в форме или имя кнопки. Заметьте, что изначально в форме мы не указывали свойство «text» («properties edited»)
Присваиваемое значение. Тут, думаю, все понятно. Это может быть новое имя пункта, список Listbox, цвет фона и т.д.
Так, если бы мы захотели динамически изменить и имя кнопки на, скажем, «New Name», то должны были добавить в условие строчку
На этом все. Основные принципы, думаю, понятны. Если кому-то помогла это статья, пишите, выложу еще. И оставляйте комментарии, потому что мы учимся вместе
Источник
Пишем список дел на Python 3 для Android через QPython3 и SL4A
Движок QPython (и QPython 3) для Android – вещь по-прежнему плохо изученная, и особенно что касается его встроенной библиотеки Scripting Layer For Android (SL4A), она же androidhelper. Эту библиотеку написали несколько сотрудников Google по принципу 20% свободного времени, снабдили ее спартанской документацией, которую почти невозможно найти, и отправили в свободное плавание. Я искал информацию об SL4A по крупицам, но со временем нашел практически все, что мне нужно.
SL4A позволяет задействовать практически все возможности консольного Python 3 вплоть до библиотек типа matplotlib, при этом используются стандартные диалоги Android: ввод текста, списки, вопросы, радиокнопки, выбор даты и т.д. Программа не будет поражать красотой, но многие задачи решать сможет. Самое главное, что мы получим доступ к различным функциям устройства. Например, можно:
- делать телефонные звонки
- посылать SMS
- менять громкость
- включать Wi-Fi и Bluetooth
- открывать веб-страницы
- открывать сторонние приложения
- делать фото- и видеосъемку камерой
- извлекать контакты из контактной книги
- посылать системные оповещения
- определять GPS-координаты устройства
- определять заряд батареи
- считывать данные SIM-карты
- воспроизводить медиафайлы
- работать с буфером обмена
- генерировать голосовые сообщения
- экспортировать данные на внешние активности (share)
- открывать локальные html-страницы
- и др.
В нашем примере мы напишем простейший список задач. Мы сможем создавать и удалять задачи, а также экспортировать их. Программа будет вибрировать и разговаривать. Мы будем пользоваться тремя видами диалогов: список, текстовый ввод и вопрос «да/нет». На все про все нам хватит менее 100 строк кода. Интерфейс сделаем английским ради универсальности (и GitHub).
Вот весь код и комментарии к наиболее существенным моментам.
Создаем объект droid класса Android(), который будет отвечать за взаимодействие с SL4A.
Переменная path будет содержать абсолютное имя файла, в котором хранятся задачи. Почему так длинно? Дело в том, что SL4A не может работать с локальным путем, поэтому приходится определять абсолютный, а абсолютный может отличаться на разных Android-устройствах. Мы обойдем эту проблему путем определения местоположения папки Download с помощью метода droid.environment() . Затем мы отсекаем Download и добавляем путь Qpython/Scripts3 (он всегда одинаков) плюс имя файла.
Определяем функцию, отвечающую за вывод списка задач. Это делается с помощью метода droid.dialogCreateAlert() . Затем ряд вспомогательных методов выводят собственно пункты, создают кнопки и получают результат от пользователя. Названиями двух кнопок служат Unicode-символы (об этом чуть ниже). Для упрощения мы упакуем все эти методы в одну простую функцию, которой будем передавать список задач. В более сложных скриптах можно передавать больше аргументов: заголовок, названия кнопок и т.д.
Определяем функцию, отвечающую за создание новой задачи. Принцип аналогичен. В аргументе default мы передаем ей текст, который по умолчанию появляется в строке ввода (пустой при «»). В более сложных программах можно передавать различные подписи и кнопки.
Эта функция будет задавать вопрос пользователю, чтобы получить ответ да или нет. Мы передаем ей текст вопроса.
Создаем цикл (чтобы скрипт не вышел после первого же действия) и первым делом читаем файл задач и загружаем его в список tasks . Если файла нет, создаем пустой список.
Выводим список задач. Когда пользователь делает какой-то выбор, метод dialog_list() возвращает это действие в виде значения, которое мы присваиваем переменной response .
Начинаем обрабатывать действие пользователя. Поскольку метод droid.dialogGetResponse() , который мы используем в функции списка, выдает довольно сложную структуру в виде словаря, его придется препарировать не самым очевидным способом. В данном случае по простому клику на пункт списка он удаляется – мы выполнили дело. Сообщим об этом во всплывающем сообщении и одновременно сделаем (чисто забавы ради) виброзвонок на 200 миллисекунд и сгенерируем голосовую фразу Дело сделано! .
По нажатию на среднюю (нейтральную) кнопку с ножницами можно разом удалить все дела. При этом будет выведен подтверждающий вопрос.
Здесь мы создаем новую задачу. Обратим внимание на переменную cancel – ее выдает droid.dialogGetResponse() в случае клика вне диалога (на пустую область экрана). Чтобы корректно обработать такую ситуацию, мы ввели дополнительное условие. По средней кнопке ( neutral ) поле ввода будет очищаться. При positive мы создаем новый пункт списка и выходим из цикла. Если нажать на самую правую кнопку, сработает else и мы просто выйдем из цикла, ничего не сохранив (хотя формально это будет значение negative в input[«which»] ). Последняя строка означает, что пользователь нажал на Exit . Тогда мы устанавливаем флаг exit в True .
После каждой обработки списка сохраняем список задач в файл.
Если пользователь решил выйти, мы выходим из главного цикла while .
В самом конце мы спрашиваем у пользователя, надо ли экспортировать все задачи куда-нибудь – на почту, в облако, в мессенджер и т.д. При положительном ответе список задач преобразуется в строку и экспортируется.
На этом всё. Программа будет выглядеть, как на скриншоте выше.
Полный листинг
Окончательный полный листинг (с комментариями на английском):
Пара замечаний. SL4A не позволяет использовать никакую графику, однако можно использовать довольно большое количество всевозможных смайлов и эмодзи как Unicode-символы. Это могут быть хоть домики, хоть собачки, хоть кошечки. В нашем примере мы использовали знак плюс ( \u2795 ), ножницы ( \u2702 ) и листок бумаги ( \ud83d\udcc3 ). C каждой новой версией Unicode их становится все больше, но этим не стоит злоупотреблять – новые смайлы не будут отображаться на более старых версиях Android.
Для запуска скриптов QPython нужно заходить в собственно QPython, но существует интересный плагин для приложения Tasker, позволяющий проделывать довольно мощные вещи с QPython-скриптами, например выводя их на рабочий стол в виде иконок или запуская по различным условиям.
Источник