On 30/12/13 09:33, Zhu, Yongsheng wrote:
Hi, Max and Kenneth
Thanks for the comment. Answer your two questions in one mail:
There is a not-insignificant group of app developers who *prefer* to
work from the command line, but (iirc) to do so required installing
the IDE which was a large download and install, and mostly useless for
the cli developer. Furthermore, it was a significant effort to develop
the tools such that we could avoid using java (etc), and instead used
node.js and grunt. NB, thanks go to Elliot Smith for that effort.
Avoid using java doesn't make sense. In my opinion, the tool from
Elliot Smith tries to use nodejs/grunt to replace python, not
java/javac related tools. That's because all web apps are needed to be
built as native applications so JDK/Android SDK are always needed.
Of course, you can ask him yourself and I don't want to put words into
his mouth, but IMO that's not quite right.
Elliot has developed tools *both* to avoid using python and to avoid the
need to download and install a huge IDE.
Of course, in the latter, it was for Tizen and so, no, Java was not seen
as 'needed' in that case (ie it was introduced unnecessarily because of
the use of Eclipse). The situation is different with Android, of course,
though having to know Java is not a requirement for the HTML5 app developer.
IINM, some Android tools use Java are all nicely self-contained, so I
don't see any particular problem with developing tools in Java if are
only for Crosswalk/Android if they are also easily deployed into the app
developer's environment (eg into grunt/etc). However, I see that as a
'bad idea' because I suspect that will just result in them seeping into
the other Crosswalk targets that don't need Java at all.
I suggest keeping the use of Java firmly inside Eclipse and developing
all other tools in whatever is used for all targets.
Remember that my comments from from frustrations during the first
several months of developing on Tizen. During this period, some of us
app developers were repeatedly switching in-and-out of Eclipse because
we wanted to use our preferred tools (eg editors and other unix tools)
but had to use Eclipse to package and 'run on device'.
Eventually, using the command line became much more friendly so we could
rid ourselves of Eclipse in day-to-day work and just use it for
'reference' (usually to find out what the latest format is for
config.xml). Quite a painful process, all-in-all.
Anyway, my main points are :
1) avoid adding languages/etc *unnecessarily* into the app developer's
environment (no real need for python, imo),
2) try to choose tools the app developer is likely to already
have/understand rather than inventing/using new ones,
3) make tools that are easy for the app developer to integrate into
their existing environment - eg encapsulated, stand-alone,
single-purpose, command-line tools
4) use those same command-line tools from within the IDE, so the two
environments don't become fragmented (ie avoid the situation where "this
works in the IDE, but when I use the cli tool, it doesn't").
IMO, Elliot has a good handle on the needs of the non-GUI developer and
so my recommendation would be to consult with him in order to cover both
groups of people. IIRC, he once pointed out how well Google have done it
and so we could probably do likewise.
WRT the use of Python, yes, I don't see why that has to be introduced to
my development environment. As far as I can see, the only reason to use
it is because it is the preferred tool of people developing the sdk (ie
quite a random choice - I wonder why not C++?) - little consideration
for the app developer who likely has to use/integrate/understand it.
However, I think it's somewhat tangential to my point above, so I'll
leave that for another day.
Max.
Let's start by providing excellent CLI tools and then we can build on
top of that. It is not like Eclipse is the preferred tool for web
developers and we want to allow integration with as many IDE/editors
as possible, not just Eclipse (which even Android is moving away from
- hence Android Studio).
We have two kinds of tools: python and nodejs. We're keeping improving
and I don't see a big gap there especially for python based. We could
do them at the same time. If you think there are lots of gaps for
packaging tool, please let me know. For IDE, we should integrate with
upstream. Right now Android studio is not mature enough, but we need
to investigate it and eclipse based solution.
Yongsheng
*From:*Crosswalk-dev
[mailto:crosswalk-dev-boun...@lists.crosswalk-project.org] *On Behalf
Of *Max Waterman
*Sent:* Wednesday, December 25, 2013 9:32 PM
*To:* crosswalk-dev@lists.crosswalk-project.org
*Subject:* Re: [Crosswalk-dev] Intent to Implement - Build WebApps
with Eclipse for Crosswalk on Android
My only thought on this - as an html5 app developer - is to try and
avoid the situation we found ourselves in with the Tizen IDE (also
based on Eclipse).
There is a not-insignificant group of app developers who *prefer* to
work from the command line, but (iirc) to do so required installing
the IDE which was a large download and install, and mostly useless for
the cli developer. Furthermore, it was a significant effort to develop
the tools such that we could avoid using java (etc), and instead used
node.js and grunt. NB, thanks go to Elliot Smith for that effort.
I hope that the Crosswalk IDE can build *on top of* command line tools
so that there is no fragmentation between the cli tools and the
implementation available in Eclipse. Unfortunately, the tools are
already in python which (imo) is not a good choice for integration
with web developers' environments, but at least they are command line
tools.
IINM, the Android SDK/IDE is built up in this same way - ie the IDE
uses command line tools in the SDK to do the work, so that the IDE can
be avoided completely, if the developer so desires. I suggest we do
likewise.
Thanks for your consideration on this matter.
Max.
On 25/12/13 14:10, Wu, Donna wrote:
*Description:*
Currently, web developers can only use command-line tools to
package their Crosswalk WebApps, e.g. make_apk.py for Android. Our
goal is to enable building crosswalk WebApps in Eclipse. With this
feature, developers create an Crosswalk project and edit the Web
stuff in Eclipse then be exported as a required package, for
example "*.apk" for Android. This feature can be extended to all
platforms in the feature, but we want to enable it for Android for
the first step.
*Affected component:*
It will be a sub-project under crosswalk-project, so no
component in current Crosswalk repo will be affected.
*Related feature: (Jira ID)*
https://crosswalk-project.org/jira/browse/XWALK-636
*Target Release: (Crosswalk N)*
Crosswalk 5
*Implementation details:*
The general idea is that, we provide an Eclipse plugin to add a
new project type. Developer need to download the plugin and then
can create the new type of project(crosswalk project), the project
can be edited and then packaged to signed APK. As we need to use
libs and tools from Android SDK, so our Eclipse plugin need
Android SDK as its precondition. So ADT bundle version or Eclipse
and ADT plugin version will be required by the plugin.
1.stand-alone project type -- (required)
Just a expose the web stuff to the developer, use Crosswalk
manifest.json for project configuration. The directory tree of the
new project just like XPK package. Developer will not see
generated Activity, cannot edit Java code, they can only edit the
web stuff in Eclipse. Web stuff will be wrapped with Java code
when packaging and exporting the project.
2.embedded or shared mode supporting -- (required)
developers can select which mode they want to package the project
in an exporting dialog. For embedded mode, developer need to
specify needed resources and libs from local disk or maybe an
on-line version.
3.supporting Crosswalk permissions -- (required)
Crossealk manifest.json will be used to configure the project,
Crosswalk permissions will be used to authorize special access
ability to WebApp, and these used permissions will be recorded in
manifest.json and will be mapped to Android permission after
wrapping and packaging the project. Currently the map haven't be
determined yet, but we will catch up the newest map.
4.different arch supporting -- (x86 required, arm Low priority)
this just make sense to embedded mode. All possible options will
be listed for selection in the exporting dialog. Error will be
through if the required crosswalk library cannot be found in the
specified resource and libs directory described in item 2.
5.various application source supporting
option1: new project created from Eclipse -- (required)
option2: import from a local directory with manifest.json --(required)
option3: import from XPK package -- (low priority)
6.external crosswalk extension supporting -- (Low priority)
developers need to specify external crosswalk extensions when
creating the project. First step, we will just support compiled
extension(directory with *.js, *.jar, *.json), in the future raw
Java files may be supported.
_______________________________________________
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
<mailto:Crosswalk-dev@lists.crosswalk-project.org>
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
_______________________________________________
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
