I spent a little of my weekend time tweaking the new PhoneGap-based Android app to make it less dependent on, well, Android. And even on PhoneGap. ;)
The app can now build with PhoneGap for iOS[1] (iPhone, iPad, iPod Touch) though there are some problems. The iOS stub source and Xcode project are in the main git repo along with the Android bits, so nothing needs to be separately maintained or copied.
[1] http://www.mediawiki.org/wiki/User:Brion_VIBBER/iOS_build_notes
Do note the major problems noted at the bottom of that page; there may be a bug in PhoneGap itself that's causing articles to open in Safari instead of in the iframe[2], and we don't yet have a non-Android menu implementation so not all features are accessible[3].
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=32069 [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=32068
In addition, the app can now run without PhoneGap at all -- if you load it straight into a web browser it'll try to just go on its merry way without initializing the Android or PhoneGap-specific bits. This actually functions in Chrome -- but for now only if you launch Chrome with the --disable-web-security option which isn't a good idea. ;)
It needs currently-forbidden cross-origin access to things in the iframe and over XHR, and will need to be tweaked to work more directly in regular browsers... but this is a good indication that it'll be relatively easy to port this to other HTML/JS-based app environments, such as WebOS, ChromeOS, Mozilla's experimental Boot2Gecko project, etc.
If nothing else, it's a lot quicker to reload in Chrome than to relaunch the app in an Android emulator. ;)
As with the iOS version, there's no Android popup menu and we don't yet have an alternate.
A few features -- eg the 'Articles near me' map view -- currently are implemented as Android-specific plugins and will need iOS and general web variants too.
-- brion
Nice work Brion. If someone on this list wants to pickup the iOS porting then certainly pick it up as were likely not going to be able to get to it for another month or so.
We can certainly help were needed but are in the process of moving from one vendor to the work to another :(
I'm thinking that we have a good chance to cleanup the various platforms when we move this from github -> gerrit
How shall we organize this sanely once we get it moved?
--tomasz
On Mon, Oct 31, 2011 at 1:01 PM, Brion Vibber brion@wikimedia.org wrote:
I spent a little of my weekend time tweaking the new PhoneGap-based Android app to make it less dependent on, well, Android. And even on PhoneGap. ;)
The app can now build with PhoneGap for iOS[1] (iPhone, iPad, iPod Touch) though there are some problems. The iOS stub source and Xcode project are in the main git repo along with the Android bits, so nothing needs to be separately maintained or copied.
[1] http://www.mediawiki.org/wiki/User:Brion_VIBBER/iOS_build_notes
Do note the major problems noted at the bottom of that page; there may be a bug in PhoneGap itself that's causing articles to open in Safari instead of in the iframe[2], and we don't yet have a non-Android menu implementation so not all features are accessible[3].
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=32069 [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=32068
In addition, the app can now run without PhoneGap at all -- if you load it straight into a web browser it'll try to just go on its merry way without initializing the Android or PhoneGap-specific bits. This actually functions in Chrome -- but for now only if you launch Chrome with the --disable-web-security option which isn't a good idea. ;)
It needs currently-forbidden cross-origin access to things in the iframe and over XHR, and will need to be tweaked to work more directly in regular browsers... but this is a good indication that it'll be relatively easy to port this to other HTML/JS-based app environments, such as WebOS, ChromeOS, Mozilla's experimental Boot2Gecko project, etc.
If nothing else, it's a lot quicker to reload in Chrome than to relaunch the app in an Android emulator. ;)
As with the iOS version, there's no Android popup menu and we don't yet have an alternate.
A few features -- eg the 'Articles near me' map view -- currently are implemented as Android-specific plugins and will need iOS and general web variants too.
-- brion
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Tue, Nov 1, 2011 at 1:57 AM, Tomasz Finc tfinc@wikimedia.org wrote:
Nice work Brion. If someone on this list wants to pickup the iOS porting then certainly pick it up as were likely not going to be able to get to it for another month or so.
Whee!
We can certainly help were needed but are in the process of moving from one vendor to the work to another :(
Nooo!
I'm thinking that we have a good chance to cleanup the various
platforms when we move this from github -> gerrit
How shall we organize this sanely once we get it moved?
There's probably two ways to handle this. No, three!
The first is the single-repo all-in-one option: this will be easiest to set up I think!
Could re-lay out the directories something like:
www/... <- all the HTML/JS/CSS/images stuff www/android/ <- Android-specific web assets (PhoneGap JS) www/ios/ <- iOS-specific web assets android/ <- build modified to import www/ into assets/www android/src/... android/libs/... android/res/... ios/ ios/Wikipedia-iOS/... ios/Wikipedia-iOS.xcodeproj
It might be a good idea to separate out the platform-specific web assets for each platform, so we're not shipping Android-specific phonegap.js on iOS and vice-versa etc. But that might also make it a little harder to work with the source.
Split variant might look like:
www/ <- all platform-independent assets android/ <- build modified to pull in www/ as assets/www and android/js as assets/www/android android/js <- android-specific web assets android/src/ android/libs/ ... ios/ ios/js/ <- android-specific web assets ios/Wikipedia-iOS/ ios/Wikipedia-iOS.xcodeproj <- build modified to combine the www and js dirs
The build systems would have to be retooled to combine the base www assets and the platform-specific ones, which shouldn't be impossible in theory, but is a little extra pain.
Third crazy possibility is to do the above, but also split them in separate repos for the web core and the various platform-specific builds. You would then either have to check them both out, or use something like submodules to check out the generic web assets into the main project.
I suspect it's not worth the effort of separate repos for the number of platforms we're going to see; it's not like MediaWiki extensions where every one of them is a standalone unit.
-- brion