In last week's blog entry, we mentioned that we have been getting increasingly involved in mobile applications. For those who have not yet studied the subject, it's important to understand that mobile applications fall into three major categories: browser based, hybrid and native.
The browser category pretty much explains itself, except to note that the browser is always "sandboxed" to some extent and cannot access certain hardware features. These restrictions are slowly being removed and the advent of HTML5 will hasten this process, but it's unlikely that they will ever be as capable as fully native applications. They also are limited in capability when disconnected although once again HTML5 holds out hope there. The major advantage is that, provided you use a Javascript framework to handle device differences, you can program in the same language that you use for your regular Web applications (e.g., RPG, Java, PHP, etc.).
Native apps are written to run on the device itself and can access all of its functionality. The biggest challenge with native apps is that to write for Apple's iOS devices (iPhone, iPad, iPod Touch) you must program in Objective C. To write for Android devices, you typically use Java, and for Windows mobile devices C#. Three different languages and three different development environments. Multiplatform tools such as Phonegap are emerging and gaining in capability and performance, but they basically require that you can write complete apps in Javascript. While we know basic Javascript, writing a complete app using it wasn't on our to-do list.
Hybrid apps typically utilize a native application framework whose components can be configured and controlled by some form of server-based interface. This allows you to use the native capabilities that are unavailable to a browser-based application, but of course you can only ever do things that the framework provides. Similarly stand-alone operations are limited to those supported by the framework. Like browser-based apps, hybrids have the advantage that you can usually use your existing language of preference to provide the server support.
We wanted to develop some native apps, but which language to learn? Which platform to target? Since we own an iPad and an iPhone, iOS was the obvious choice but Objective C is ... well ... different. This weekend we came upon a new tool that has just been released into the Apple App store--Kodiak PHP. As most readers will know, having basically failed at Java we have embraced PHP in recent years and have done quite a lot with it. Could we really use it to produce a native app on the iPad? The answer appears to be yes and no.
The yes part is that the Kodiak team succeeded in porting the Zend PHP engine to iOS and it runs beautifully and amazingly quickly. The built-in support for SQLite allows us to use an on-board database. We have yet to work out how to tie it in to the address book, etc., but the database access itself works very well. The color-coded editor has a "swipe" keyboard extension that makes block selection a breeze and also makes all symbols available without having to switch the keypad mode. That is a great help and makes the editor usable for off-line development even without an external keyboard.
The no bit is partly a function of the immaturity of the product and partly a function of Apple's rather strict rules on what native apps can and cannot do. For example, while you can enter and execute scripts in the editor you cannot download existing scripts. There are many ways to get round this limitation. The one that has worked best for us is i-FunBox, which allows your Mac or Windows machine to interface with your iOS device. You can drag/drop your PHP scripts directly into the application's associated folders. Other options also exist, and admittedly this one's user interface is a bit klutzy, but the free ad-supported version works very well for us and the ads aren't at all intrusive. The tool also supports the (de)installation of iOS apps, music files, videos, etc., but we haven't used that capability yet.
There is also a teeny tiny problem in the current implementation in that HTML Form submissions aren't working in the current release. At least we can't get them to work. That kind of limits the apps you can build! Based on the speedy response we have had from the support team when reporting other issues we expect to see a fast resolution of this problem and with that out of the way can start to do some serious development. The other major issue right now is the lack of documentation--there really isn't any. The basic interface is intuitive and presents few problems. The included sample scripts also demonstrate a few features, but nothing that shows how to access native functionality such as the camera or GPS. The probability is that the PHP wrappers for that native functionality have yet to be built. Without any documents that is tough to say.
In summary, we're excited at the potential this application presents. Its price is low enough ($10) that even if we can never produce a real native application it will have been money well spent as it provides a really easy way to dynamically test PHP constructs under circumstances (like too cramped aircraft seats) where using the laptop is just not practical. Also, it's just plain fun! Give it a try. We think you'll be impressed. The company's home page includes a video of the product in action. If you try it out, let us know what you think via the blog comments.
The browser category pretty much explains itself, except to note that the browser is always "sandboxed" to some extent and cannot access certain hardware features. These restrictions are slowly being removed and the advent of HTML5 will hasten this process, but it's unlikely that they will ever be as capable as fully native applications. They also are limited in capability when disconnected although once again HTML5 holds out hope there. The major advantage is that, provided you use a Javascript framework to handle device differences, you can program in the same language that you use for your regular Web applications (e.g., RPG, Java, PHP, etc.).
Native apps are written to run on the device itself and can access all of its functionality. The biggest challenge with native apps is that to write for Apple's iOS devices (iPhone, iPad, iPod Touch) you must program in Objective C. To write for Android devices, you typically use Java, and for Windows mobile devices C#. Three different languages and three different development environments. Multiplatform tools such as Phonegap are emerging and gaining in capability and performance, but they basically require that you can write complete apps in Javascript. While we know basic Javascript, writing a complete app using it wasn't on our to-do list.
Hybrid apps typically utilize a native application framework whose components can be configured and controlled by some form of server-based interface. This allows you to use the native capabilities that are unavailable to a browser-based application, but of course you can only ever do things that the framework provides. Similarly stand-alone operations are limited to those supported by the framework. Like browser-based apps, hybrids have the advantage that you can usually use your existing language of preference to provide the server support.
We wanted to develop some native apps, but which language to learn? Which platform to target? Since we own an iPad and an iPhone, iOS was the obvious choice but Objective C is ... well ... different. This weekend we came upon a new tool that has just been released into the Apple App store--Kodiak PHP. As most readers will know, having basically failed at Java we have embraced PHP in recent years and have done quite a lot with it. Could we really use it to produce a native app on the iPad? The answer appears to be yes and no.
The yes part is that the Kodiak team succeeded in porting the Zend PHP engine to iOS and it runs beautifully and amazingly quickly. The built-in support for SQLite allows us to use an on-board database. We have yet to work out how to tie it in to the address book, etc., but the database access itself works very well. The color-coded editor has a "swipe" keyboard extension that makes block selection a breeze and also makes all symbols available without having to switch the keypad mode. That is a great help and makes the editor usable for off-line development even without an external keyboard.
The no bit is partly a function of the immaturity of the product and partly a function of Apple's rather strict rules on what native apps can and cannot do. For example, while you can enter and execute scripts in the editor you cannot download existing scripts. There are many ways to get round this limitation. The one that has worked best for us is i-FunBox, which allows your Mac or Windows machine to interface with your iOS device. You can drag/drop your PHP scripts directly into the application's associated folders. Other options also exist, and admittedly this one's user interface is a bit klutzy, but the free ad-supported version works very well for us and the ads aren't at all intrusive. The tool also supports the (de)installation of iOS apps, music files, videos, etc., but we haven't used that capability yet.
There is also a teeny tiny problem in the current implementation in that HTML Form submissions aren't working in the current release. At least we can't get them to work. That kind of limits the apps you can build! Based on the speedy response we have had from the support team when reporting other issues we expect to see a fast resolution of this problem and with that out of the way can start to do some serious development. The other major issue right now is the lack of documentation--there really isn't any. The basic interface is intuitive and presents few problems. The included sample scripts also demonstrate a few features, but nothing that shows how to access native functionality such as the camera or GPS. The probability is that the PHP wrappers for that native functionality have yet to be built. Without any documents that is tough to say.
In summary, we're excited at the potential this application presents. Its price is low enough ($10) that even if we can never produce a real native application it will have been money well spent as it provides a really easy way to dynamically test PHP constructs under circumstances (like too cramped aircraft seats) where using the laptop is just not practical. Also, it's just plain fun! Give it a try. We think you'll be impressed. The company's home page includes a video of the product in action. If you try it out, let us know what you think via the blog comments.
Connect With Us: