PHP on mobile devices

Date December 20, 2007

I heard about this last week, which is an article about running PHP on Symbian mobile devices.  Haven’t seen much in the press about this, possibly because it’s not a full release, but just an announcement.  The crux of the article is that someone has ported Apache, MySQL and PHP to the Symbian E90.  They’re calling this “PAMP” - Personal Apache MySQL PHP.  Being able to run a browser on the phone and connect to local AMP apps might herald a new age in mobile app development, or perhaps not.  Palm was the primary game in town for awhile, but I found that to be too difficult (I’m not a C developer).  Windows Mobile seems to be the primary mobile platform right now, for quick app development and widespread deployment.  Apple’s iPhone and this new PAMP might be a next wave in mobile development.  What do you think?

 Did you like this post? Buy me a hot chocolate!

9 Responses to “PHP on mobile devices”

  1. Rob Young said:

    Far to0 big a stack for mobile devices. Resources are very scarce by design. It’s very different from the server space. In the server space, you have a small number of machines doing a large amount of work. With mobile devices the tables are turned, if you need 100k more memory to run your bigger stack that’s not just 100k more in each server, that’s a 100k in every single device you sell. Pennies very quickly add up to pounds. The point I’m trying to get at is that when developing for mobile devices, it’s worthwhile investing more time and money in development as the savings made from it add up.

  2. mgkimsal said:

    @Rob:

    I agree that the potential size and speed of these may be a hindrance, I’m not so sure. 10 years ago ’server class’ hardware where I ran shared hosting for AMP apps was 256 megs, 200 mhz computers. This e90 phone is 128 meg (80 meg free for apps) and 150mhz chips. While I wouldn’t run yahoo on this, using web-apps with mostly only one user probably wouldn’t tax these buggers to the point of being unusable. On the contrary, I’d think they would be usable. Considering Java apps have been running on slower phones for years, I don’t think PAMP apps would be that bad.

    Your point that investing more time in development is exactly where I think this whole discussion will be turning. If you can spend less time in development using tools that make development easier, why not? There’s a whole class of people who can write useful business apps for mobile devices, but do not have the skills to get in and manage memory at the C or assembly level to try to save 50k of memory. I also think mobile devices are getting to the point where those sorts of concerns won’t be the dominant consideration when designing apps.

    I used to do 6502 assembly language by hand, fitting programs in to less than 8k. Every byte counted in those days. For certain tasks, every byte still counts, but those tasks and arenas are getting more and more specialized. Some of my desktop icons are larger than entire business apps people used to write. The march of commodity hardware capacity makes certain ways of thinking less necessary.

  3. Keith Elder said:

    I don’t get it. Why would I want to write a web app to run on a mobile phone? You have a much better user experience writing the application to run natively within the confines of the operating system it runs on.

    I’ve written mobile applications for windows devices and and I would never think to embed IIS and Asp.Net code to write an application. The user interfaces on these devices are limited enough as it is and things need to run natively to get speed, best user experience and so on.

    I mean how would you build an app that integrated with the address book on the phone, or make a low level call to the API in the OS to turn off the backlight? The answer is you can’t. PHP is a scripting language, let’s just leave it at that and move on.

  4. mgkimsal said:

    You probably wouldn’t access an ‘address book’ as such. However, if phone providers were to provide, say, a SQLite database as part of the core phone, your ‘address book’ might just be an SQL call away. I know of a company that will be embedding an SQL database in to an upcoming phone, and it wouldn’t surprise me if others are already doing it or have plans for the next generation of phones.

    As the UIs improve, and we see more convergence between ‘desktop’ computers and ‘mobile’ devices, this sort of move seems to make sense to me. If there’s an easy way to embed VBScript on your phone to do things that would be too cumbersome to write ‘native’ apps for, wouldn’t you do it? You, Keith, might not, but many people would jump at the opportunity to use that sort of functionality.

    As for UI directly in web browser, I’d agree that most current phones would sort of stink for just porting over standard webapps. Doing this sort of thing with an iPhone UI (the embedded Safari iPhone experience is pretty slick). I also recently used a built in phone webbrowser in China that was pretty nice as well (not iPhone nice, but better than most of the surfing experiences I’ve had on mobile devices over there, including Windows mobile devices from 2005 and recent 2007 BlackBerries).

    So, in short, as the devices converge, this sort of idea will probably make more sense.

    Thanks all for the comments so far. :)

  5. developercast.com » SymbianOne.com: Your S60 Web server gets a boost said:

    [...] Kimsal points out an article posted recently concerning a new feature of the Symbain OS for mobile phones - a web [...]

  6. DJ Sipe said:

    It seems to me that the overall trend is for a service-based model with slim clients tying into remote applications (Twitter, Plaxo, GMail). You get the benefit (privacy issues aside) of a centralized database that can span multiple machines allowing you to never have data in one place that you can’t access from another. No more syncing.

    Running an app locally also defeats the main purpose of building web apps: rapid deployment. Now you’re into software updates and bug fixes. When clients run remote applications, there just one copy of the app to update–not thousands.

  7. mgkimsal said:

    Interesting point DJ. Keith Elder (noted above) might argue with you a bit on that point, in that Windows “smart client” technology provides arguably a best of both worlds - local copies running with syncing and updating logic built in to the supporting framework. Certainly mobile “traditional” web apps have their place, but I do think that local copies of apps running with local data (with occasional syncing when necessary) makes sense in some situations as well. Google Reader’s ‘offline’ mode may be the easiest example of that. Runs against remote data when necessary, and can be updated, but can also run locally against local data. That’s not what the point of this particular article was, but it points toward that.

  8. Varun said:

    Hey .. nice question raised.. given the computing power of mobile phones these days .. running a webserver on the mobile has become a reality ..

    it would be really cool to run a php website on my s60 phone but battery and screensize is what would spoil the party

  9. will said:

    It would be a great thing to have PHP running on Symbian phones, as Sun’s Java JVM is unbelievably slow.

    The only problems here are that PHP changes fairly frequently, and the extensions required to make it useful would weigh down the ‘portable’ aspect.

    To top it off, as stated in your recent ‘Sad Development State of PHP’ blog entry, developers for the Symbain OS or just users like ourselves which like to write things for our mobile devices will likely become frustrated because the fruits of our code will have to change every time PHP does.

    (Psst! Zend needs to standardize the way changes are made to PHP long before it becomes an integral part of the consumer electronics market.)

    I would not put PHP onto my phone just yet.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="">