PHP as a cross-platform desktop app development language? Blasphemy! Nonetheless, it’s possible.
A few years ago, everything those
interested in bringing PHP to the desktop had had was the now long
abandoned GTK PHP. Since then, new players have appeared, though let’s
first answer the “why”.
Why?
Why would anyone develop cross platform
PHP Training in Jaipur apps for the desktop? Why not opt for something that can actually
tie into the low level APIs of the operating system, like Adobe AIR? Why
not go with something outdated and bloated but reliable, like Java? Why
not make it a Chrome app and if you need native support, use Native
Client? Hell, if you want a scripting language, why not just go with
Python? Everything goes, as long as we avoid having to bundle a server
with the whole shebang, right?
Off the top of my head, I can think of several far fetched scenarios:
- You need a good middle ground between easy syntax and good
structure, which is PHP, and you can’t be bothered to learn new
languages like ActionScript
- You’re running IT in a company with highly computer illiterate
people, and the only way to force them into using a good browser for
your company app is to embed it into the app you deliver. It’s still a
web app, but opens in a headless Chrome!
- You want to avoid paying hosting costs for your own personal
application, and you like to carry it with you on a USB stick. You just
plug it in, run it, and your app is there – using the same SQLite DB
from before. If you need to sync online, you send the whole DB export to
Dropbox or some such service at the click of a button, thus making sure
you’re literally the only one who can access your “web app” even
without your computer.
- You don’t need low level OS API access – you just want to make a
browser based game, or a helper app, or something similarly simple. PHP
is perfectly fine for that, and you already know the language.
These scenarios might look like grasping
at straws, and indeed, I really can’t think of a REAL, practical reason
to want to do it that doesn’t have a viable alternative. Still, it’s
nice to know it’s possible. Let’s see how.
1. Nightrain
Nightrain is a pre-packaged set of
PHP-hosting prerequisites powered by PHP 5.5.x at the moment. It’s a
packager written in Python that uses PHP’s internal server to host your
app, thus avoiding Apache and Nginx and minimizing configuration
shenanigans. However, this also means some more advanced aspects are
unavailable, and you can only really use it for very rudimentary apps.
Another big con is that on Windows, a
command prompt is launched first, and then the “app”. The command
windows must stay open if you want to use the app, and this might be
more than a little confusing to the technically illiterate people of
scenario 2) above.
What’s more, you can only run one
nightrain app by default, because it actually launches a server on port
8000 and then makes the headless browser that opens “secretly” visit localhost:8000. If you want to launch several different nightrain apps, you need to change the port in settings.ini. This also means that simply visiting localhost:8000 in your host machine’s browser will show you the same app.
Nightrain is compatible with most PHP
apps/frameworks out of the box, as long as you change the database to
SQLite, which is what’s used, and tweak the bundled php.ini
for some missing extensions, if any. MySQL is not bundled and
installing it alongside the regular stack is no simple matter. It’s very
simple to make the app send the SQLite data upstream to a server you
use for a centralized database anyway, so using only SQLite on the
system where the app is running is somewhat logical.
By far the biggest drawback of the app
is that it uses WX widgets to power the headless browser, and on
Windows, this seems to come down to IE7. Changing it seems possible, by
means of WXPython as mentioned in the issue linked above, but hasn’t yet
been attempted. One can only hope the browser object will be updated to
something more usable some time soon – until then, and until all the
other critical drawbacks are fixed, I can’t even begin to imagine a use
for Nightrain.
2. WXPHP
wxPHP stands for “wxWidgets for PHP” and is a PHP
extension that wraps the wxWidgets library, which allows to write
multi-platform desktop applications that make use of the native
graphical components available to the different platforms. – Wikipedia
You install wxPHP as a separate program, which then gives you support for execution of .wxphp files by simply doubleclicking on them.
This means your applications are mere
files, and you can distribute them everywhere with ease. You can
organize your code into files and classes as usual and distribute
folders. The main .wxphp file can then include these other resources.
The installation comes with several
examples, including one which initializes WebView and loads the wxPHP
website in a wx frame. One thing to note is that with wxPHP you aren’t
developing websites as you would on the web. In other words, you don’t
develop offline websites, but string together various wx widgets. As
such, the library has a bit of a learning curve, and you’ll be lacking
the HTML5 features you might be used to, or the simplicity of web
development. There is some Proof of Concept of the internal PHP server
running and serving requests, but that’s experimental and complex, and
once again exposes the localhost, just like Nightrain.
wxPHP also comes with an adorable form
building tool which will help you automatically generate the PHP code
you need for your wxPHP apps by means of a wysiwyg editor.
Before you dismiss wx as trivial, people
have developed more than basic apps in it. For example, here’s a PHP
Editor with remote debugging and a plugin API.
If you’re serious about PHP desktop
development, wxPHP is by far the better option when compared to
Nightrain, even though Nightrain lets you write good old HTML for GUI.
One of the biggest advantages of wx here is the fact that once installed, all .wxphp
files can be run at the click of the mouse. No additional installs, no
awkward console windows. For technically illiterate people, that’s a
godsend – you can easily distribute the app inside your company via a
simple email, and the update procedure is as simple as overwriting a
file.
3. TideSDK
TideSDK has a somewhat different
approach than the above two. You install an SDK to be able to develop
applications, and each platform has certain prerequisites. TideSDK is
actually the renamed Titanium Desktop project. Titanium remained focused
on mobile, and abandoned the desktop version, which was taken over by
some people who have open sourced it and dubbed it TideSDK.
Once installed as per the Getting
Started guide, and once we have the TideSDK Developer app (a helper
application which will guide us in bundling our application into a
distributable package), we can get started developing. Apps you build
with Tide (via the helper app, or via the command line) will be both
distributable as purely executable, or can be distributed as installable
packages which get the whole “app” treatment, including an installation
procedure embedded, making them uninstallable via Add/Remove Programs
on Windows or your package managers on other operating systems.
Applications resources are used in conjunction with a
WebKit client and a familiar and extensive API. The API is privileged,
providing filesystem access that allows you to read and manage files.
APIs are also provided to create and interact with a local database.
Network API allows to create clients and servers or to interface with
HTTP at a much lower level. It is also possible to open socket
connections to other services.
Generally, TideSDK uses HTML, CSS and JS
to render applications, but it supports scripted languages like Python,
Ruby and PHP as well. The engine behind the rendering is WebKit which
means it’ll be somewhat slow to start, but it’ll support the latest web
technologies.
The heart of TideSDK is an object bridge compiled into
the WebKit component. The bridge allows other scripting languages –
python, php or ruby – to run on the HTML page using script tags in the
DOM, just like JavaScript. You can also directly call .py, .rb or .php
files from within your application.
PHP is activated by adding a module statement to the manifest file, like so:
#appname:HelloWorld#appid:com.tidesdk.helloworld#publisher:Software in the Public Interest (SPI) Inc#image:default_app_logo.png#url:http//tidesdk.org#guid:845e9c3c-c9ff-4ad4-afdf-9638092f044f#desc:Sample Hello World application#type:desktop
runtime:1.3.1-beta
app:1.3.1-beta
codec:1.3.1-beta
database:1.3.1-beta
filesystem:1.3.1-beta
media:1.3.1-beta
monkey:1.3.1-beta
network:1.3.1-beta
platform:1.3.1-beta
process:1.3.1-beta
ui:1.3.1-beta
worker:1.3.1-beta
php:1.3.1-beta
Note that using the script modules for
scripting languages will incur significant performance penalties on the
installation and runtime of your app(s).
Interestingly, TideSDK features an
object bridge which lets you, when using PHP in your apps, convert data
seamlessly from JS to PHP and back. You can read more here, but a
detailed TideSDK tutorial is coming soon.
There are two major downsides to using TideSDK for PHP desktop app development:
- The PHP development workflow is severely underdocumented and highly susceptible to bugs, but almost impossible to debug.
- The bundled PHP version is terribly outdated – version 5.3.X at the
time of this writing. While it’s relatively easy to replace it with an
up-to-date one through the
/modules folder in the SDK’s
installation directory, it’s an additional nuisance and lacks many
modern PHP features which might come in handy in desktop app
development, not to mention the built-in server which also might get an
esoteric use case here.
- There is a learning curve. The DOM API is different from what you
may be used to in web development. To echo something on screen, you
would need to call
$document->write() rather than echo. It’s a minor difference, but it isn’t well documented and can trip you up.
- By far the biggest downside is the compilation. The package you get
by building an app is bound to the platform you’ve built it on. To build
the app for multiple environments, you need to HAVE those multiple
environments. The Windows/Linux disparity is easily solved with virtual
machines (though easier to solve if your host is Windows and you have
Linux VMs than the other way around), but good luck compiling it for OS X
unless you’ve got an OS X device, too.
TideSDK is a neat option, but it’s far
from usable. It’ll do great for HTML/CSS/JS delivery, but when it comes
to PHP, I believe wxPHP is still your best bet.
