now for the bad news: until the very last moment (uploading the
distribution version) it was a PhoneGap application, but in the last
few days I removed PhoneGap.
The reason was, I got a code signing error that did not appear in the
development signing. But when I try to sign a distribution version, it
did not work. I asked for help in this forum ( see post
http://groups.google.com/group/phonegap/browse_thread/thread/e13fd465... ) but the tips I've got did not help to solve the problem.
I must be doing something wrong... because obviously other people DO
successfully upload Iphone apps made with phonegap. But I could not
find out what was wrong.
At the moment this all happened, I was pretty desperate, because I had
really worked hard on it, and I wanted to finish the project. I also
had a UIWebView tutorial downloaded, and felt a little bit more in
control trying to compile my own browser wrapper than hunting down
really really odd signing errors. So I went that way.... and it turned
out to be suprisingly easy. Two days later, I had a working "my-own-
private-PhoneGap-built-from-scratch".
One might wonder what the value of PhoneGap is, if you can build a
private "phonegap like" app in just 2 days (although it is a very
minimalized version and does not do a lot of things PhoneGap can do).
I have mixed feelings about it. I really love wat PhoneGap tries to
do: bringing the Iphone/Android/Blackberry platforms to web
developers. Being a web developer myself, with little (objective) C
experience before, I appreciate it's value, and I do not want to write
private phonegaps, and I hope I will switch back to PhoneGap for
future versions and apps.
But, I do think that PhoneGap is focussing a little bit on the wrong
priorities. I think a library like this deserves excellent
documentation and a great build process. When making my own phonegap
app I had to git clone a repository, remove Phonegap developer's names
on many places in xcode before it started to work with my developer
provisioning profile in the first place. Also I noticed that there was
a lot of objective C code for all device specific features (camera,
contacts, etc.. ....) which my application did not use at all, but
there was no way to remove them from the project. (except by digging
into the objective C code yourself)
I do not like such an unclean "start project".
Also, when making my own "phonegap", I discovered that javascript/
objective C communication is really not very hard. (Although my app
did not require any specific objective C functions, so I did not
really build any of this bridge code - but from the UIWebView tutorial
I learned how you can do it, and it does not require rocket science).
The bridge between objective C and javascript is very generic. To me
as a developer, this really calls for a great plugin structure, in
which all phonegap users can contribute objective-C stuff, add it to a
very small base version of phonegap. I imagine an empty project with
a kind of perl/python/ruby based startup wizzard, and you just check
which functions you need (Contacts, camera, GPS, ...) and then the
right plugins are installed.
So, summarized, my impression of PhoneGap is that it's developers are
in a "make as much features as fast as you can" culture. I think a
great library like this deserves an other culture: "be easygoing on
the device features, and really go for quality, documentation,
plugins, clean build process". More a "wikipedia" mindset than a "do
everything yourself ASAP" mindset.
If everyone can contribute plugins, the device features will still be
there in no time ;-) and PhoneGap will head for a great future!
I still hope to use it for android, and perhaps, for the iPhone again
in a next release or an other app.
On Sat, Sep 19, 2009 at 7:38 AM, jan <jan.tuit...@gmail.com> wrote: > now for the bad news: until the very last moment (uploading the > distribution version) it was a PhoneGap application, but in the last > few days I removed PhoneGap. ... > So, summarized, my impression of PhoneGap is that it's developers are > in a "make as much features as fast as you can" culture. I think a > great library like this deserves an other culture: "be easygoing on > the device features, and really go for quality, documentation, > plugins, clean build process". More a "wikipedia" mindset than a "do > everything yourself ASAP" mindset.
> If everyone can contribute plugins, the device features will still be > there in no time ;-) and PhoneGap will head for a great future! > I still hope to use it for android, and perhaps, for the iPhone again > in a next release or an other app.
From what docs and info I could find on Phonegap, it seems that if you
don't use certain features they are not included in the compiled
code. I'm not certain though, maybe a phonegap developer can answer
the question better.
-Jimmy
On Sep 19, 10:38 am, jan <jan.tuit...@gmail.com> wrote:
> now for the bad news: until the very last moment (uploading the
> distribution version) it was a PhoneGap application, but in the last
> few days I removed PhoneGap.
> The reason was, I got a code signing error that did not appear in the
> development signing. But when I try to sign a distribution version, it
> did not work. I asked for help in this forum ( see posthttp://groups.google.com/group/phonegap/browse_thread/thread/e13fd465...
> ) but the tips I've got did not help to solve the problem.
> I must be doing something wrong... because obviously other people DO
> successfully upload Iphone apps made with phonegap. But I could not
> find out what was wrong.
> At the moment this all happened, I was pretty desperate, because I had
> really worked hard on it, and I wanted to finish the project. I also
> had a UIWebView tutorial downloaded, and felt a little bit more in
> control trying to compile my own browser wrapper than hunting down
> really really odd signing errors. So I went that way.... and it turned
> out to be suprisingly easy. Two days later, I had a working "my-own-
> private-PhoneGap-built-from-scratch".
> One might wonder what the value of PhoneGap is, if you can build a
> private "phonegap like" app in just 2 days (although it is a very
> minimalized version and does not do a lot of things PhoneGap can do).
> I have mixed feelings about it. I really love wat PhoneGap tries to
> do: bringing the Iphone/Android/Blackberry platforms to web
> developers. Being a web developer myself, with little (objective) C
> experience before, I appreciate it's value, and I do not want to write
> private phonegaps, and I hope I will switch back to PhoneGap for
> future versions and apps.
> But, I do think that PhoneGap is focussing a little bit on the wrong
> priorities. I think a library like this deserves excellent
> documentation and a great build process. When making my own phonegap
> app I had to git clone a repository, remove Phonegap developer's names
> on many places in xcode before it started to work with my developer
> provisioning profile in the first place. Also I noticed that there was
> a lot of objective C code for all device specific features (camera,
> contacts, etc.. ....) which my application did not use at all, but
> there was no way to remove them from the project. (except by digging
> into the objective C code yourself)
> I do not like such an unclean "start project".
> Also, when making my own "phonegap", I discovered that javascript/
> objective C communication is really not very hard. (Although my app
> did not require any specific objective C functions, so I did not
> really build any of this bridge code - but from the UIWebView tutorial
> I learned how you can do it, and it does not require rocket science).
> The bridge between objective C and javascript is very generic. To me
> as a developer, this really calls for a great plugin structure, in
> which all phonegap users can contribute objective-C stuff, add it to a
> very small base version of phonegap. I imagine an empty project with
> a kind of perl/python/ruby based startup wizzard, and you just check
> which functions you need (Contacts, camera, GPS, ...) and then the
> right plugins are installed.
> So, summarized, my impression of PhoneGap is that it's developers are
> in a "make as much features as fast as you can" culture. I think a
> great library like this deserves an other culture: "be easygoing on
> the device features, and really go for quality, documentation,
> plugins, clean build process". More a "wikipedia" mindset than a "do
> everything yourself ASAP" mindset.
> If everyone can contribute plugins, the device features will still be
> there in no time ;-) and PhoneGap will head for a great future!
> I still hope to use it for android, and perhaps, for the iPhone again
> in a next release or an other app.
Love this post and it really hits home with how we want to start
restructuring PhoneGap. At Nitobi we've been working hard on client
projects and rolling the innovations driven by that work into the
framework.
Very soon, we will be spending some time cleaning up the project,
making starting out simpler and want you to know we hear your feedback
loud and clear.
> now for the bad news: until the very last moment (uploading the
> distribution version) it was a PhoneGap application, but in the last
> few days I removed PhoneGap.
> The reason was, I got a code signing error that did not appear in the
> development signing. But when I try to sign a distribution version, it
> did not work. I asked for help in this forum ( see post
> http://groups.google.com/group/phonegap/browse_thread/thread/e13fd465... > ) but the tips I've got did not help to solve the problem.
> I must be doing something wrong... because obviously other people DO
> successfully upload Iphone apps made with phonegap. But I could not
> find out what was wrong.
> At the moment this all happened, I was pretty desperate, because I had
> really worked hard on it, and I wanted to finish the project. I also
> had a UIWebView tutorial downloaded, and felt a little bit more in
> control trying to compile my own browser wrapper than hunting down
> really really odd signing errors. So I went that way.... and it turned
> out to be suprisingly easy. Two days later, I had a working "my-own-
> private-PhoneGap-built-from-scratch".
> One might wonder what the value of PhoneGap is, if you can build a
> private "phonegap like" app in just 2 days (although it is a very
> minimalized version and does not do a lot of things PhoneGap can do).
> I have mixed feelings about it. I really love wat PhoneGap tries to
> do: bringing the Iphone/Android/Blackberry platforms to web
> developers. Being a web developer myself, with little (objective) C
> experience before, I appreciate it's value, and I do not want to write
> private phonegaps, and I hope I will switch back to PhoneGap for
> future versions and apps.
> But, I do think that PhoneGap is focussing a little bit on the wrong
> priorities. I think a library like this deserves excellent
> documentation and a great build process. When making my own phonegap
> app I had to git clone a repository, remove Phonegap developer's names
> on many places in xcode before it started to work with my developer
> provisioning profile in the first place. Also I noticed that there was
> a lot of objective C code for all device specific features (camera,
> contacts, etc.. ....) which my application did not use at all, but
> there was no way to remove them from the project. (except by digging
> into the objective C code yourself)
> I do not like such an unclean "start project".
> Also, when making my own "phonegap", I discovered that javascript/
> objective C communication is really not very hard. (Although my app
> did not require any specific objective C functions, so I did not
> really build any of this bridge code - but from the UIWebView tutorial
> I learned how you can do it, and it does not require rocket science).
> The bridge between objective C and javascript is very generic. To me
> as a developer, this really calls for a great plugin structure, in
> which all phonegap users can contribute objective-C stuff, add it to a
> very small base version of phonegap. I imagine an empty project with
> a kind of perl/python/ruby based startup wizzard, and you just check
> which functions you need (Contacts, camera, GPS, ...) and then the
> right plugins are installed.
> So, summarized, my impression of PhoneGap is that it's developers are
> in a "make as much features as fast as you can" culture. I think a
> great library like this deserves an other culture: "be easygoing on
> the device features, and really go for quality, documentation,
> plugins, clean build process". More a "wikipedia" mindset than a "do
> everything yourself ASAP" mindset.
> If everyone can contribute plugins, the device features will still be
> there in no time ;-) and PhoneGap will head for a great future!
> I still hope to use it for android, and perhaps, for the iPhone again
> in a next release or an other app.
On Wed, Sep 23, 2009 at 7:49 AM, jfountain <jimmy.fount...@gmail.com> wrote:
> From what docs and info I could find on Phonegap, it seems that if you > don't use certain features they are not included in the compiled > code. I'm not certain though, maybe a phonegap developer can answer > the question better.
> -Jimmy
I think that the code will ship with your app unless you delete it, but it is dynamically loaded so it should not slow down your app's load time.
Jan, thanks for the informative post. Would you mind posting your
"phonegap like" code somewhere? Not the main code for your app, but
the framework/glue code you came up with. I'm trying to decide between
phonegap and rolling my own, would be helpful to see a sample hand-
rolled version.
Best,
Parand
On Sep 19, 7:38 am, jan <jan.tuit...@gmail.com> wrote:
> now for the bad news: until the very last moment (uploading the
> distribution version) it was a PhoneGap application, but in the last
> few days I removed PhoneGap.
> The reason was, I got a code signing error that did not appear in the
> development signing. But when I try to sign a distribution version, it
> did not work. I asked for help in this forum ( see posthttp://groups.google.com/group/phonegap/browse_thread/thread/e13fd465...
> ) but the tips I've got did not help to solve the problem.
> I must be doing something wrong... because obviously other people DO
> successfully upload Iphone apps made with phonegap. But I could not
> find out what was wrong.
> At the moment this all happened, I was pretty desperate, because I had
> really worked hard on it, and I wanted to finish the project. I also
> had a UIWebView tutorial downloaded, and felt a little bit more in
> control trying to compile my own browser wrapper than hunting down
> really really odd signing errors. So I went that way.... and it turned
> out to be suprisingly easy. Two days later, I had a working "my-own-
> private-PhoneGap-built-from-scratch".
> One might wonder what the value of PhoneGap is, if you can build a
> private "phonegap like" app in just 2 days (although it is a very
> minimalized version and does not do a lot of things PhoneGap can do).
> I have mixed feelings about it. I really love wat PhoneGap tries to
> do: bringing the Iphone/Android/Blackberry platforms to web
> developers. Being a web developer myself, with little (objective) C
> experience before, I appreciate it's value, and I do not want to write
> private phonegaps, and I hope I will switch back to PhoneGap for
> future versions and apps.
> But, I do think that PhoneGap is focussing a little bit on the wrong
> priorities. I think a library like this deserves excellent
> documentation and a great build process. When making my own phonegap
> app I had to git clone a repository, remove Phonegap developer's names
> on many places in xcode before it started to work with my developer
> provisioning profile in the first place. Also I noticed that there was
> a lot of objective C code for all device specific features (camera,
> contacts, etc.. ....) which my application did not use at all, but
> there was no way to remove them from the project. (except by digging
> into the objective C code yourself)
> I do not like such an unclean "start project".
> Also, when making my own "phonegap", I discovered that javascript/
> objective C communication is really not very hard. (Although my app
> did not require any specific objective C functions, so I did not
> really build any of this bridge code - but from the UIWebView tutorial
> I learned how you can do it, and it does not require rocket science).
> The bridge between objective C and javascript is very generic. To me
> as a developer, this really calls for a great plugin structure, in
> which all phonegap users can contribute objective-C stuff, add it to a
> very small base version of phonegap. I imagine an empty project with
> a kind of perl/python/ruby based startup wizzard, and you just check
> which functions you need (Contacts, camera, GPS, ...) and then the
> right plugins are installed.
> So, summarized, my impression of PhoneGap is that it's developers are
> in a "make as much features as fast as you can" culture. I think a
> great library like this deserves an other culture: "be easygoing on
> the device features, and really go for quality, documentation,
> plugins, clean build process". More a "wikipedia" mindset than a "do
> everything yourself ASAP" mindset.
> If everyone can contribute plugins, the device features will still be
> there in no time ;-) and PhoneGap will head for a great future!
> I still hope to use it for android, and perhaps, for the iPhone again
> in a next release or an other app.
Thanks, Jan, for this well-stated and based-on-your-experience
summary.
I concur that the need for modularity and a clean build process far
outweighs all other opportunities at this point. To take the point
further, I'd say the community is looking for the simplest solution to
these issues (e.g., modularity based on a clean build process) rather
than a highly-architected solution that'll take months to complete and
more months to debug.
> now for the bad news: until the very last moment (uploading the
> distribution version) it was a PhoneGap application, but in the last
> few days I removed PhoneGap.
> The reason was, I got a code signing error that did not appear in the
> development signing. But when I try to sign a distribution version, it
> did not work. I asked for help in this forum ( see posthttp://groups.google.com/group/phonegap/browse_thread/thread/e13fd465...
> ) but the tips I've got did not help to solve the problem.
> I must be doing something wrong... because obviously other people DO
> successfully upload Iphone apps made with phonegap. But I could not
> find out what was wrong.
> At the moment this all happened, I was pretty desperate, because I had
> really worked hard on it, and I wanted to finish the project. I also
> had a UIWebView tutorial downloaded, and felt a little bit more in
> control trying to compile my own browser wrapper than hunting down
> really really odd signing errors. So I went that way.... and it turned
> out to be suprisingly easy. Two days later, I had a working "my-own-
> private-PhoneGap-built-from-scratch".
> One might wonder what the value of PhoneGap is, if you can build a
> private "phonegap like" app in just 2 days (although it is a very
> minimalized version and does not do a lot of things PhoneGap can do).
> I have mixed feelings about it. I really love wat PhoneGap tries to
> do: bringing the Iphone/Android/Blackberry platforms to web
> developers. Being a web developer myself, with little (objective) C
> experience before, I appreciate it's value, and I do not want to write
> private phonegaps, and I hope I will switch back to PhoneGap for
> future versions and apps.
> But, I do think that PhoneGap is focussing a little bit on the wrong
> priorities. I think a library like this deserves excellent
> documentation and a great build process. When making my own phonegap
> app I had to git clone a repository, remove Phonegap developer's names
> on many places in xcode before it started to work with my developer
> provisioning profile in the first place. Also I noticed that there was
> a lot of objective C code for all device specific features (camera,
> contacts, etc.. ....) which my application did not use at all, but
> there was no way to remove them from the project. (except by digging
> into the objective C code yourself)
> I do not like such an unclean "start project".
> Also, when making my own "phonegap", I discovered that javascript/
> objective C communication is really not very hard. (Although my app
> did not require any specific objective C functions, so I did not
> really build any of this bridge code - but from the UIWebView tutorial
> I learned how you can do it, and it does not require rocket science).
> The bridge between objective C and javascript is very generic. To me
> as a developer, this really calls for a great plugin structure, in
> which all phonegap users can contribute objective-C stuff, add it to a
> very small base version of phonegap. I imagine an empty project with
> a kind of perl/python/ruby based startup wizzard, and you just check
> which functions you need (Contacts, camera, GPS, ...) and then the
> right plugins are installed.
> So, summarized, my impression of PhoneGap is that it's developers are
> in a "make as much features as fast as you can" culture. I think a
> great library like this deserves an other culture: "be easygoing on
> the device features, and really go for quality, documentation,
> plugins, clean build process". More a "wikipedia" mindset than a "do
> everything yourself ASAP" mindset.
> If everyone can contribute plugins, the device features will still be
> there in no time ;-) and PhoneGap will head for a great future!
> I still hope to use it for android, and perhaps, for the iPhone again
> in a next release or an other app.
I'm also considering a "roll your own" approach as Jan did, for the same
reasons. At least for now.
I agree with Dave that we need something simple and soon. Just a script
that produces a template app would be great, we could provide the app name,
check a few boxes for what features we need, and it would produce a ready to
compile set of source files, clearly marked as to where we add our own
stuff. If we change our mind later and add or remove a feature, we can do
this step over and our app should still work without a lot of cut and
pasting. I'd think that would be pretty easy, just by marking up the source
with some tags and using a very simple existing script.
On Thu, Sep 24, 2009 at 6:11 AM, David Oliver <oliver.davi...@gmail.com>wrote:
> Thanks, Jan, for this well-stated and based-on-your-experience
> summary.
> I concur that the need for modularity and a clean build process far
> outweighs all other opportunities at this point. To take the point
> further, I'd say the community is looking for the simplest solution to
> these issues (e.g., modularity based on a clean build process) rather
> than a highly-architected solution that'll take months to complete and
> more months to debug.
> Dave
> David M. Oliver | da...@olivercoady.com | http://olivercoady.com |
> @davidmoliver | +1 914 316 1470
> On Sep 19, 10:38 am, jan <jan.tuit...@gmail.com> wrote:
> > Hello all,
> > now for the bad news: until the very last moment (uploading the
> > distribution version) it was a PhoneGap application, but in the last
> > few days I removed PhoneGap.
> > The reason was, I got a code signing error that did not appear in the
> > development signing. But when I try to sign a distribution version, it
> > did not work. I asked for help in this forum ( see posthttp://
> groups.google.com/group/phonegap/browse_thread/thread/e13fd465...
> > ) but the tips I've got did not help to solve the problem.
> > I must be doing something wrong... because obviously other people DO
> > successfully upload Iphone apps made with phonegap. But I could not
> > find out what was wrong.
> > At the moment this all happened, I was pretty desperate, because I had
> > really worked hard on it, and I wanted to finish the project. I also
> > had a UIWebView tutorial downloaded, and felt a little bit more in
> > control trying to compile my own browser wrapper than hunting down
> > really really odd signing errors. So I went that way.... and it turned
> > out to be suprisingly easy. Two days later, I had a working "my-own-
> > private-PhoneGap-built-from-scratch".
> > One might wonder what the value of PhoneGap is, if you can build a
> > private "phonegap like" app in just 2 days (although it is a very
> > minimalized version and does not do a lot of things PhoneGap can do).
> > I have mixed feelings about it. I really love wat PhoneGap tries to
> > do: bringing the Iphone/Android/Blackberry platforms to web
> > developers. Being a web developer myself, with little (objective) C
> > experience before, I appreciate it's value, and I do not want to write
> > private phonegaps, and I hope I will switch back to PhoneGap for
> > future versions and apps.
> > But, I do think that PhoneGap is focussing a little bit on the wrong
> > priorities. I think a library like this deserves excellent
> > documentation and a great build process. When making my own phonegap
> > app I had to git clone a repository, remove Phonegap developer's names
> > on many places in xcode before it started to work with my developer
> > provisioning profile in the first place. Also I noticed that there was
> > a lot of objective C code for all device specific features (camera,
> > contacts, etc.. ....) which my application did not use at all, but
> > there was no way to remove them from the project. (except by digging
> > into the objective C code yourself)
> > I do not like such an unclean "start project".
> > Also, when making my own "phonegap", I discovered that javascript/
> > objective C communication is really not very hard. (Although my app
> > did not require any specific objective C functions, so I did not
> > really build any of this bridge code - but from the UIWebView tutorial
> > I learned how you can do it, and it does not require rocket science).
> > The bridge between objective C and javascript is very generic. To me
> > as a developer, this really calls for a great plugin structure, in
> > which all phonegap users can contribute objective-C stuff, add it to a
> > very small base version of phonegap. I imagine an empty project with
> > a kind of perl/python/ruby based startup wizzard, and you just check
> > which functions you need (Contacts, camera, GPS, ...) and then the
> > right plugins are installed.
> > So, summarized, my impression of PhoneGap is that it's developers are
> > in a "make as much features as fast as you can" culture. I think a
> > great library like this deserves an other culture: "be easygoing on
> > the device features, and really go for quality, documentation,
> > plugins, clean build process". More a "wikipedia" mindset than a "do
> > everything yourself ASAP" mindset.
> > If everyone can contribute plugins, the device features will still be
> > there in no time ;-) and PhoneGap will head for a great future!
> > I still hope to use it for android, and perhaps, for the iPhone again
> > in a next release or an other app.
On Thu, Sep 24, 2009 at 10:56 AM, rob brown <rjbr...@gmail.com> wrote: > I'm also considering a "roll your own" approach as Jan did, for the same > reasons. At least for now.
> I agree with Dave that we need something simple and soon. Just a script > that produces a template app would be great, we could provide the app name, > check a few boxes for what features we need, and it would produce a ready to > compile set of source files, clearly marked as to where we add our own > stuff. If we change our mind later and add or remove a feature, we can do > this step over and our app should still work without a lot of cut and > pasting. I'd think that would be pretty easy, just by marking up the source > with some tags and using a very simple existing script.
A counter-proposal: focus on portability. I think that in the long run, that's PhoneGap's big advantage. Sure, it isn't too hard to build a Phonegap-ish like thing for simple IPhone apps, but once you start building it a second and a third time for Android and Palm Pre you start to really appreciate that someone has already done it for you...
Paul, I'm OK with "portability" within a scoped definition. I come
from the old Java mobile world and in that world "portability" was
supposed to mean "the code that I write will run anywhere". That was
a hopeless failure because the diversity of devices made it impossible
(assuming you wanted to maintain a world-class user experience on each
device). Instead, and echoing what Rob said, the portability (and
build-ability) of the phoneGap code, coupled with an ability to select
the feature sub-set one needs, would be an ideal level of
portability.
I'm willing to get less than Rob wants, too - I'm OK with just a
profile- or config-file (which perhaps contained a list of features to
bake in).
Dave
On Sep 24, 2:11 pm, Paul Prescod <pres...@gmail.com> wrote:
> On Thu, Sep 24, 2009 at 10:56 AM, rob brown <rjbr...@gmail.com> wrote:
> > I'm also considering a "roll your own" approach as Jan did, for the same
> > reasons. At least for now.
> > I agree with Dave that we need something simple and soon. Just a script
> > that produces a template app would be great, we could provide the app name,
> > check a few boxes for what features we need, and it would produce a ready to
> > compile set of source files, clearly marked as to where we add our own
> > stuff. If we change our mind later and add or remove a feature, we can do
> > this step over and our app should still work without a lot of cut and
> > pasting. I'd think that would be pretty easy, just by marking up the source
> > with some tags and using a very simple existing script.
> A counter-proposal: focus on portability. I think that in the long
> run, that's PhoneGap's big advantage. Sure, it isn't too hard to build
> a Phonegap-ish like thing for simple IPhone apps, but once you start
> building it a second and a third time for Android and Palm Pre you
> start to really appreciate that someone has already done it for
> you...
On Fri, Sep 25, 2009 at 4:46 AM, David Oliver <oliver.davi...@gmail.com> wrote:
> Paul, I'm OK with "portability" within a scoped definition. I come > from the old Java mobile world and in that world "portability" was > supposed to mean "the code that I write will run anywhere". That was > a hopeless failure because the diversity of devices made it impossible > (assuming you wanted to maintain a world-class user experience on each > device). Instead, and echoing what Rob said, the portability (and > build-ability) of the phoneGap code, coupled with an ability to select > the feature sub-set one needs, would be an ideal level of > portability.
I don't understand what you are suggesting. The PhoneGap code is by definition not portable. It's the PhoneGap API that is portable.
> I'm willing to get less than Rob wants, too - I'm OK with just a > profile- or config-file (which perhaps contained a list of features to > bake in).
I'm surprised that people are very concerned about the "extra" features that come along with their binary. I don't have time this morning to do the forensics, but I don't think that the optional PhoneGap components are very big. They are thin wrappers around platform APIs. Do users complain about binaries being large and if so, has anyone poked around in the actual files to see if it is PhoneGap causing the bloat?
On Fri, Sep 25, 2009 at 1:51 PM, Paul Prescod <pres...@gmail.com> wrote: > I don't understand what you are suggesting. The PhoneGap code is by > definition not portable. It's the PhoneGap API that is portable.
This is exactly right. What developers should be concerned about is the PhoneGap API being portable *not* the actual PhoneGap "wrapper code" for each specific platform being portable. As Paul says, the PhoneGap "wrapper code" can not be portable it is device/platform specific.
> I'm surprised that people are very concerned about the "extra" > features that come along with their binary. I don't have time this > morning to do the forensics, but I don't think that the optional > PhoneGap components are very big. They are thin wrappers around > platform APIs. Do users complain about binaries being large and if so, > has anyone poked around in the actual files to see if it is PhoneGap > causing the bloat?
If you don't use the geoloc for example, you will never invoke the code that does this. Aside from taking a couple of hundred K of bundled app binary space, it does not hurt anything.
It would be nice to see a "plugin" based model where folks can contribute a module for some specific native function on a specific native platform, however, I do not think it is necessary to be able to just include the plugins you want/need. Just include all the plugins - as long as they don't step on each other (which they shouldn't) - they won't be used if the functionality is not used. Just my $0.02.
On Fri, Sep 25, 2009 at 3:01 PM, Pratik Patel <pratik.r.pa...@gmail.com>wrote:
> If you don't use the geoloc for example, you will never invoke the code > that does this. Aside from taking a couple of hundred K of bundled app > binary space, it does not hurt anything.
Although, I'd guess that if you want the app store approval process to go quickly and smoothly, having that extra unused code in there wouldn't exactly help.
Paul and Pratik - thanks for your "corrective" posts. My points were
simply that (a) I prefer phoneGap to be an enabling framework that
gives me uniform access to certain features across platforms and (b)
I'd prefer a simple solution to modularity that allows me to use the
parts of the API I need for my application.
Part B can be further clarified by saying that, as phoneGap matures
there is the temptation to add new features as people dream up more
apps and inevitably some new features will not be available on all
platforms (let's say "compass access" as an example). While it's fine
to make phoneGap as useful as possible, it also demands a way to allow
incompatible features or unused features to be left out. We still
have memory problems in mobile and the many-features ("kitchen sink")
style of framework grows less useful than one where a simple build-
time process supports sensible subsetting.
I'd just like to add THANKS to the phoneGap community for producing
such a useful piece of software.
Dave
On Sep 25, 6:01 pm, Pratik Patel <pratik.r.pa...@gmail.com> wrote:
> On Fri, Sep 25, 2009 at 1:51 PM, Paul Prescod <pres...@gmail.com> wrote:
> > I don't understand what you are suggesting. The PhoneGap code is by
> > definition not portable. It's the PhoneGap API that is portable.
> This is exactly right. What developers should be concerned about is the
> PhoneGap API being portable *not* the actual PhoneGap "wrapper code" for
> each specific platform being portable. As Paul says, the PhoneGap "wrapper
> code" can not be portable it is device/platform specific.
> > I'm surprised that people are very concerned about the "extra"
> > features that come along with their binary. I don't have time this
> > morning to do the forensics, but I don't think that the optional
> > PhoneGap components are very big. They are thin wrappers around
> > platform APIs. Do users complain about binaries being large and if so,
> > has anyone poked around in the actual files to see if it is PhoneGap
> > causing the bloat?
> If you don't use the geoloc for example, you will never invoke the code that
> does this. Aside from taking a couple of hundred K of bundled app binary
> space, it does not hurt anything.
> It would be nice to see a "plugin" based model where folks can contribute a
> module for some specific native function on a specific native platform,
> however, I do not think it is necessary to be able to just include the
> plugins you want/need. Just include all the plugins - as long as they don't
> step on each other (which they shouldn't) - they won't be used if the
> functionality is not used. Just my $0.02.
