Hi, It would be really nice if offline (=zim) support was integrated in the   official wikipedia app:  The user could switch between online access and offline reading. If I understand Tomasz correctly, it is planned to implement the wikipedia app with phonegap, so having zim support for phonegap would allow integration of offline support into the app. Therefore I think its a good idea to implement zim support for phone gap. Regarding the technical details there a basically to ways to implement zim support in phonegap: - Using phonegap API. Theoretically device independent, but questionable whether  actually working with sufficient performance on all target platforms. -  As plugin: Implemented as a native component, with bindings to phonegap. I'd prefer the plugin approach. The additional effort of implementing the zimlib plugin for different platforms is not that high. The zimlib (and liblzma) is already available  for     C++  (STL): Symbian[1], Meego[2],                         Android  (with NDK, cleaner is to use Java),                         iPhone (untested, may have some issues (see [5]), alternative would be to port to objective-C)                         and probably Bada     Java (less mature than C++ implementation) : Android, Blackberry  and other J2ME [3]  (not sure whether possible on J2ME, but this is even more true for phonegap API approach) Porting needs only to be done to:     C#: Windows Mobile     Other: ? In addition the plugins for the platforms need to be written but this shouldn't be a too high effort. The zimlib is already pretty stable, so the maintenance effort for the ports should not be too bad. An additional benefit of the plugin-approach  is that the ported zimlibs plugins can also be used for native apps. (Besides having the plain zimlib, the plugin projects can be used as a starting point for new projects). For the phonegap API approach zimlib must be ported to java script.  As mentioned before I doubt that the javascript zimlib would work with sufficient performance on all (if any) . devices.    See for example [4] Best regards, Christian [1] Neither File (required for phonegap API approach) nor plugins officially supported in phonegap. However, should be pretty easy to add.               (Either in official (=WRT) phonegap, or in QT port. Probably better in QT port). [2] Not supported by phonegap. However, should be possible to use QT phonegap port. [3] Not supported by phonegap. [4] http://community.phonegap.com/nitobi/topics/how_to_implement_lzma?from_gsfn… [5] http://stackoverflow.com/questions/823116/how-do-i-use-c-stl-containers-in-… Am 27.08.2011 10:34, schrieb Manuel Schneider: > Hi, > > is this maybe also useful for ZIM - to make ZIM readers which are > working cross-platform? > > As far as I understood phonegap is mainly a framework to create mobile > apps based on HTML 5. At least the display of ZIM contents should be > simple then as we just need a HTML widget for that. > But what about libraries needed to read file contents, such as zimlib? > I > couldn't find out if Phonegap itself supports native file access (so > we > could re-implement ZIM features with that) or if it allows the use of > native libraries. > > /Manuel > > Am 27.08.2011 02:44, schrieb Tomasz Finc: >> Thanks for the super detailed write up Brion. I've been actively >> talking with the PhoneGap guys after doing some more research on this >> and it seems like a really good fit to have a consistent experience >> across a whole host of devices. >> >> What were looking at is not necessarily a lot of depth in every >> single >> platform but a lot of horizontal range. Phonegap platform support >> beats out Titanium pretty easily there. >> >> We'll be working a lot closer with the PhoneGap team going forward to >> quickly have something in the android store to start. >> >> If anyone is interested in helping then we'll have plenty of >> opportunities to join in. Over the next weeks we'll be adding bugs >> and >> sending out more calls to get involved. >> >> --tomasz >> >> >> >> On Tue, Aug 16, 2011 at 1:50 PM, Brion Vibber<brion(a)pobox.com> >>  wrote: >>> On Tue, Aug 16, 2011 at 1:14 PM, Tomasz Finc<tfinc(a)wikimedia.org> >>>  wrote: >>> >>>> I've been asking around on IRC but thought it would be good to open >>>> up >>>> to a larger audience. >>>> >>>> Has anyone here used PhoneGap (http://www.phonegap.com/) for mobile >>>> app development? I'm eager to get your thoughts and potentially >>>> brainstorm some new ideas. >>>> >>> I haven't used PhoneGap except for some brief testing, but I have >>> used >>> Titanium Appcelerator, which is another framework in that space, in >>> working >>> on StatusNet's iPhone&  Android app. >>> >>> Between the two I'd recommend PhoneGap for our usage as preferable >>> over >>> Titanium, but would appreciate more feedback from people who've done >>> fuller >>> PhoneGap work. >>> >>> A few key differences: >>> >>> PhoneGap models around extending a full-screen web view with >>> additional >>> JavaScript-accessible APIs to use device&  OS capabilities (camera, >>> address >>> book, notifications, etc). This gives you few/no "native widgets" >>> for your >>> primary screens, but can make it relatively easy to create an >>> HTML/JS-based >>> web application that's extended with native abilities and can be >>> shipped >>> into native app stores. >>> >>> Titanium was originally based on a similar model, but switched to a >>> native >>> widget bridging system, where your JavaScript code instantiates and >>> manipulates objects which are bridged to native UI components and >>> such. This >>> can make your widgets look&  feel more native, and can make some UI >>> bits >>> faster. But it also makes behavior less consistent between >>> platforms; many >>> widgets or features simply aren't available on all platforms, and >>> last I >>> checked there was basically *no* working support other than iOS and >>> Android. >>> (An early BlackBerry demo came out, was insufficient to do anything >>> we >>> needed, and never got updated that we saw.) >>> >>> Since the Wikipedia app is mostly a webview and ......  maybe a >>> menu? >>> PhoneGap is probably a good choice. Titanium can also embed a >>> webview, but >>> it's a lot more work to deal with two levels of JS! PhoneGap has >>> much >>> broader device support, but be warned -- it'll use the native >>> webview on >>> each system, so JS and HTML/CSS support will still vary across >>> platforms. >>> >>> >>> Debugging in PhoneGap basically devolves to being able to debug a >>> web >>> application; various tools likehttp://phonegap.github.com/weinre/ >>>  can help >>> with this (or if you code carefully you may get away debugging your >>> app in >>> your favorite desktop browser directly ;) >>> >>> >>> Titanium was always a bear to debug things in and basically came >>> down to >>> 'watch the system log output in Android, that's the only place >>> you'll >>> actually see low-level errors'; this may be better now with their >>> IDE >>> support. >>> >>> Titanium also pretty aggressively pushes their support&  training >>> services >>> which I find offputting; their project build tool wants you to login >>> to >>> their 'cloud' stuff to let you hook up to their remote build& >>>  analytics >>> services, which we didn't ever really use. >>> >>> Support seemed to center on getting people to take training webinars >>> or >>> pointing people at the documentation and examples when they ask how >>> to do >>> something; I didn't find them very responsive about platform bugs or >>> missing >>> documentation except by contacting their couple of Android >>> developers >>> one-on-one in IRC to ask for merges -- which was usually a pretty >>> good >>> experience! Getting fixes for iOS merged was very difficult; I could >>> never >>> get ahold of their iOS developers directly, and they didn't seem to >>> be any >>> more responsive to low-level bugs we filed through their customer >>> support >>> system. >>> >>> We had to build with a patched version of the iOS and Android >>> runtimes for >>> quite some time as there were serious bugs. On the plus side, >>> maintaining a >>> patched branch in git was very easy -- a lot of 'git pull origin >>> master' and >>> occasionally tidying up conflicts. Their source is all on github and >>> is easy >>> to fork and not too awful to build, at least for the mobile runtime. >>> >>> >>> Note that both PhoneGap and Titanium frameworks are open source& >>>  hosted on >>> github, though both require a CLA to submit code upstream. (I have >>> signed >>> the Titanium CLA to submit patches to them last year; haven't done >>> for >>> PhoneGap yet.) >>> >>> -- brion >>> _______________________________________________ >>> Wikitech-l mailing list >>> Wikitech-l(a)lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>> >> _______________________________________________ >> Wikitech-l mailing list >> Wikitech-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Hi, It would be really nice if offline (=zim) support was integrated in the   official wikipedia app:  The user could switch between online access and offline reading. If I understand Tomasz correctly, it is planned to implement the wikipedia app with phonegap, so having zim support for phonegap would allow integration of offline support into the app. Therefore I think its a good idea to implement zim support for phone gap. Regarding the technical details there a basically to ways to implement zim support in phonegap: - Using phonegap API. Theoretically device independent, but questionable whether  actually working with sufficient performance on all target platforms. -  As plugin: Implemented as a native component, with bindings to phonegap. I'd prefer the plugin approach. The additional effort of implementing the zimlib plugin for different platforms is not that high. The zimlib (and liblzma) is already available  for     C++  (STL): Symbian[1], Meego[2],                         Android  (with NDK, cleaner is to use Java),                         iPhone (untested, may have some issues (see [5]), alternative would be to port to objective-C)                         and probably Bada     Java (less mature than C++ implementation) : Android, Blackberry  and other J2ME [3]  (not sure whether possible on J2ME, but this is even more true for phonegap API approach) Porting needs only to be done to:     C#: Windows Mobile     Other: ? In addition the plugins for the platforms need to be written but this shouldn't be a too high effort. The zimlib is already pretty stable, so the maintenance effort for the ports should not be too bad. An additional benefit of the plugin-approach  is that the ported zimlibs plugins can also be used for native apps. (Besides having the plain zimlib, the plugin projects can be used as a starting point for new projects). For the phonegap API approach zimlib must be ported to java script.  As mentioned before I doubt that the javascript zimlib would work with sufficient performance on all (if any) . devices.    See for example [4] Best regards, Christian [1] Neither File (required for phonegap API approach) nor plugins officially supported in phonegap. However, should be pretty easy to add.               (Either in official (=WRT) phonegap, or in QT port. Probably better in QT port). [2] Not supported by phonegap. However, should be possible to use QT phonegap port. [3] Not supported by phonegap. [4] http://community.phonegap.com/nitobi/topics/how_to_implement_lzma?from_gsfn… [5] http://stackoverflow.com/questions/823116/how-do-i-use-c-stl-containers-in-… Am 27.08.2011 10:34, schrieb Manuel Schneider: > > Hi, > > is this maybe also useful for ZIM - to make ZIM readers which are > working cross-platform? > > As far as I understood phonegap is mainly a framework to create mobile > apps based on HTML 5. At least the display of ZIM contents should be > simple then as we just need a HTML widget for that. > But what about libraries needed to read file contents, such as zimlib? > I > couldn't find out if Phonegap itself supports native file access (so we > could re-implement ZIM features with that) or if it allows the use of > native libraries. > > /Manuel > > Am 27.08.2011 02:44, schrieb Tomasz Finc: >> >> Thanks for the super detailed write up Brion. I've been actively >> talking with the PhoneGap guys after doing some more research on this >> and it seems like a really good fit to have a consistent experience >> across a whole host of devices. >> >> What were looking at is not necessarily a lot of depth in every single >> platform but a lot of horizontal range. Phonegap platform support >> beats out Titanium pretty easily there. >> >> We'll be working a lot closer with the PhoneGap team going forward to >> quickly have something in the android store to start. >> >> If anyone is interested in helping then we'll have plenty of >> opportunities to join in. Over the next weeks we'll be adding bugs and >> sending out more calls to get involved. >> >> --tomasz >> >> >> >> On Tue, Aug 16, 2011 at 1:50 PM, Brion Vibber<brion(a)pobox.com> >>  wrote: >>> >>> On Tue, Aug 16, 2011 at 1:14 PM, Tomasz Finc<tfinc(a)wikimedia.org> >>>  wrote: >>> >>>> I've been asking around on IRC but thought it would be good to open >>>> up >>>> to a larger audience. >>>> >>>> Has anyone here used PhoneGap (http://www.phonegap.com/) for mobile >>>> app development? I'm eager to get your thoughts and potentially >>>> brainstorm some new ideas. >>>> >>> I haven't used PhoneGap except for some brief testing, but I have >>> used >>> Titanium Appcelerator, which is another framework in that space, in >>> working >>> on StatusNet's iPhone&    Android app. >>> >>> Between the two I'd recommend PhoneGap for our usage as preferable >>> over >>> Titanium, but would appreciate more feedback from people who've done >>> fuller >>> PhoneGap work. >>> >>> A few key differences: >>> >>> PhoneGap models around extending a full-screen web view with >>> additional >>> JavaScript-accessible APIs to use device&    OS capabilities (camera, >>> address >>> book, notifications, etc). This gives you few/no "native widgets" for >>> your >>> primary screens, but can make it relatively easy to create an >>> HTML/JS-based >>> web application that's extended with native abilities and can be >>> shipped >>> into native app stores. >>> >>> Titanium was originally based on a similar model, but switched to a >>> native >>> widget bridging system, where your JavaScript code instantiates and >>> manipulates objects which are bridged to native UI components and >>> such. This >>> can make your widgets look&    feel more native, and can make some UI >>> bits >>> faster. But it also makes behavior less consistent between platforms; >>> many >>> widgets or features simply aren't available on all platforms, and >>> last I >>> checked there was basically *no* working support other than iOS and >>> Android. >>> (An early BlackBerry demo came out, was insufficient to do anything >>> we >>> needed, and never got updated that we saw.) >>> >>> Since the Wikipedia app is mostly a webview and ......  maybe a menu? >>> PhoneGap is probably a good choice. Titanium can also embed a >>> webview, but >>> it's a lot more work to deal with two levels of JS! PhoneGap has much >>> broader device support, but be warned -- it'll use the native webview >>> on >>> each system, so JS and HTML/CSS support will still vary across >>> platforms. >>> >>> >>> Debugging in PhoneGap basically devolves to being able to debug a web >>> application; various tools likehttp://phonegap.github.com/weinre/ >>>  can help >>> with this (or if you code carefully you may get away debugging your >>> app in >>> your favorite desktop browser directly ;) >>> >>> >>> Titanium was always a bear to debug things in and basically came down >>> to >>> 'watch the system log output in Android, that's the only place you'll >>> actually see low-level errors'; this may be better now with their IDE >>> support. >>> >>> Titanium also pretty aggressively pushes their support&    training >>> services >>> which I find offputting; their project build tool wants you to login >>> to >>> their 'cloud' stuff to let you hook up to their remote build& >>>  analytics >>> services, which we didn't ever really use. >>> >>> Support seemed to center on getting people to take training webinars >>> or >>> pointing people at the documentation and examples when they ask how >>> to do >>> something; I didn't find them very responsive about platform bugs or >>> missing >>> documentation except by contacting their couple of Android developers >>> one-on-one in IRC to ask for merges -- which was usually a pretty >>> good >>> experience! Getting fixes for iOS merged was very difficult; I could >>> never >>> get ahold of their iOS developers directly, and they didn't seem to >>> be any >>> more responsive to low-level bugs we filed through their customer >>> support >>> system. >>> >>> We had to build with a patched version of the iOS and Android >>> runtimes for >>> quite some time as there were serious bugs. On the plus side, >>> maintaining a >>> patched branch in git was very easy -- a lot of 'git pull origin >>> master' and >>> occasionally tidying up conflicts. Their source is all on github and >>> is easy >>> to fork and not too awful to build, at least for the mobile runtime. >>> >>> >>> Note that both PhoneGap and Titanium frameworks are open source& >>>  hosted on >>> github, though both require a CLA to submit code upstream. (I have >>> signed >>> the Titanium CLA to submit patches to them last year; haven't done >>> for >>> PhoneGap yet.) >>> >>> -- brion >>> _______________________________________________ >>> Wikitech-l mailing list >>> Wikitech-l(a)lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>> >> _______________________________________________ >> Wikitech-l mailing list >> Wikitech-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l